SHORT ANSWER
A Lean Inception is a structured workshop, described by Paulo Caroli, that gets business and technical people to agree on a Minimum Viable Product in about five days, often shortened to three. The team works through a fixed sequence: product vision, is/is not/does/does not, goals, personas, features, reviews, user journeys, a feature sequencer and an MVP canvas. You leave with an agreed MVP scope and an incremental release plan.
A Lean Inception is a workshop that gets business, design and engineering to agree on a Minimum Viable Product (MVP) and an incremental plan to build it. Paulo Caroli described the method, and it usually runs over five days, often compressed to three. It works through a fixed set of activities, from product vision to an MVP canvas, so everyone leaves with the same scope, priorities and first estimate. This guide gives you an agenda, a template for each activity and advice on when to use it.
When should you run a Lean Inception?
A new product or platform where stakeholders picture different things.
A major new release of an existing product that needs a clear first increment.
Before a fixed budget or tender, to turn a vague brief into a scope you can estimate.
After an Event Storming session, when the domain is clear and the question becomes what to build first. See our Event Storming guide.
When a project has stalled because priorities keep changing.
It’s less useful for a single, narrow problem, where a Design Sprint fits better, or for pure platform or infrastructure work with no product decisions to make.
What we see when teams run a Lean Inception before building
We’ve opened several client projects with a three-day Lean Inception. For a global chemical and consumer goods company planning a custom supply chain platform, a remote three-day session gave every team member room to put ideas forward and ended with a requirements list and a four-month window for a proof of concept. We delivered it in three months. See how that played out in our guide to moving a proof of concept to production.
On another project, an enterprise data and analytics portal, the same format kept the discussion on end-user needs and people’s daily work with data instead of on tools. The pattern in both: a fixed agenda forces the scope decisions that long email threads leave open.
Lean Inception agenda: day by day
The agenda below is a typical five-day format with half-day sessions, which leaves afternoons for regular work or preparation. The order matters, because each activity builds on the one before.
Day | Activities | Purpose |
|---|---|---|
Day 1 | Kickoff, product vision, is / is not / does / does not, product goals | Agree on why the product exists and where its boundaries are |
Day 2 | Personas, feature brainstorming | Describe who the users are and what they need to do |
Day 3 | Technical, business and UX review, user journeys | Rate each feature for confidence and effort, map journeys through the product |
Day 4 | Sequencer | Arrange features into waves under agreed rules |
Day 5 | Cost and schedule, MVP canvas, showcase | Define the MVP, its metrics and the first estimate, then present to sponsors |
The activities explained
Product vision
The team fills in a short template: For [target customer], who [need], the [product name] is a [category] that [key benefit]. Unlike [alternative], our product [differentiator]. Small groups write versions and merge them into one agreed statement.
Is / is not / does / does not
A four-quadrant board sets out what the product is, what it isn’t, what it does and what it doesn’t do. The two negative quadrants are often the most useful, because they remove scope early.
Product goals
Participants write business goals, cluster them and agree on three to five, each with a way to measure success.
Personas
The group creates two to four personas with a name, profile, behaviour and needs. Personas keep later discussions about real users rather than opinions.
Features
Everyone brainstorms features linked to personas and goals. A feature is something a user can do, such as track delivery status, not a technical task.
Technical, business and UX review
Each feature gets a quick rating for business value, UX value, effort and how well the team understands it. Low-confidence features get flagged for clarification before they can enter the MVP.
User journeys
The team maps how each persona moves through the product step by step and attaches features to each step. Journeys expose missing features and show which ones must ship together.
Sequencer
Features go into waves under simple rules: for example, no more than three features per wave, no more than one low-confidence feature per wave, and total effort per wave below a limit. The first waves become the MVP candidates.
MVP canvas
The canvas summarises the MVP proposal, personas, journeys, features, expected result, validation metrics, and cost and schedule. It’s the single page sponsors sign off.
Who does what in a Lean Inception?
Role | Responsibility |
|---|---|
Facilitator | Runs the agenda, keeps time, enforces rules, keeps discussion balanced |
Sponsor or product owner | Owns the vision and makes final scope decisions |
Business stakeholders | Bring goals, constraints and knowledge of users |
UX designer | Leads personas and journeys, rates UX value |
Tech lead or architect | Rates effort and technical confidence, flags dependencies |
Development team members | Contribute to features and effort, build shared context |
What do you get at the end?
An agreed product vision and a written list of what’s out of scope.
Three to five measurable product goals.
Personas and user journeys.
A rated and sequenced feature list, grouped into waves.
An MVP canvas with validation metrics.
A first estimate of cost and timeline for the MVP, usually as a range.
As a typical range, a small cross-functional team can build an MVP defined this way in roughly 2 to 4 months. Scope and connections to other systems move that number a lot.
A simple Lean Inception template
If you prepare a digital board in Miro or Mural, create one frame per activity in this order: vision template, four-quadrant is/is not board, goals clustering area, persona cards, feature list, review grid with four rating columns, journey swimlanes per persona, sequencer with six to eight waves and rule labels, and a one-page MVP canvas. Put the agenda and timeboxes at the top so the group always knows where it is.
Tips for a good Lean Inception
Get the sponsor to commit to the vision session and the MVP canvas session in person.
Timebox each activity and move on. Perfect wording isn’t the goal.
Keep the feature list at user level, not technical tasks.
Write down open questions and assign owners before the showcase.
Revisit the canvas after the first release and update the sequence.
How RUBICON helps with Lean Inception
We run Lean Inception, Event Storming and Design Sprint workshops as the starting point for new products. The team that runs the workshop can also design and build the MVP, so the scope agreed in the room carries straight into delivery. Since 2013 we’ve launched 60+ products, and 70% of our new clients come through referrals.
Read about our Lean Inception workshop and end-to-end product development. If you’re about to scope a new product, we can plan the session with you.
Frequently asked questions
What is a Lean Inception?
A Lean Inception is a short, tightly structured workshop that helps a team agree on what to build first. Paulo Caroli described it in his book Lean Inception. It combines design thinking and lean startup ideas into a sequence of activities that ends with a defined Minimum Viable Product, a set of validation metrics and an incremental plan for the releases that follow.
How long does a Lean Inception take?
The classic format is five days of half-day or full-day sessions, one week in total. Many teams compress it into three days for a well-understood product, or spread it over two weeks of shorter remote sessions. Going shorter than two days usually means skipping the review and sequencing steps, which is where most of the value comes from.
Who should attend a Lean Inception?
Typically 6 to 12 people: the product owner or sponsor, business stakeholders who own the problem, a UX designer, a tech lead or architect, and members of the development team. A facilitator runs the agenda. Decision makers need to attend at least the vision and MVP canvas sessions, otherwise the agreed scope may not hold.
What is the difference between Lean Inception and a Design Sprint?
A Design Sprint takes one specific problem, prototypes a solution and tests it with real users in about five days. A Lean Inception defines the scope of a whole product or release and produces an MVP and a sequenced feature plan. Teams often use a Lean Inception to agree on scope, then a Design Sprint to test the riskiest idea within it.
More resources
