Lean Inception

When a new project is taken on by a team at Confirmit, it is often based on initial discussions among a very limited group of people.  The rest of the team has no insight into the initial ideas and thinking. We have discussed and tried various ways of kicking off new projects, in this post I want to share our experiences with one of them: Lean Inception

I have facilitated Lean Inception based on the framework of Paulo Caroli (https://martinfowler.com/articles/lean-inception) a few times.  The framework enables you both to create a plan for the first deliveries, as well as getting a united team.  The framework efficiently flushes out differences in opinion and potential misunderstandings, which results in an unified understanding of what to build and what not to build.


The process

The workshop consists of a number of exercises, targeting the project from different angles, constantly moving towards first deliveries.  Most exercises start with group discussions, followed by presenting, comparing and conforming output from the groups.  This makes the framework surprisingly flexible in terms of participants.  Neither a high number of participants (first workshop had 15), nor participants only participating in some of the exercises caused any problems. Brief outline of content is as follows (slightly adjusted naming):

  1. Specify product vision
  2. Specify scope and business objectives
  3. Describe the personas
  4. Discover features
  5. Determine effort and value of features
  6. Discover user journeys
  7. Map features to user journeys
  8. Determine delivery order of features
  9. Determine MVPs
  10. Build the MVP canvas

Experiences so far:

Based on my limited experience facilitating this workshop I have made some initial observations.

  • It is important that everybody agree and are aware of the scope of the project.  In the last workshop we agreed to make the scope what we hope to build within a year.  Functionality not likely to be implemented the first year was not talked about, allowing us to cut too visionary ideas.
  • Features should correspond to the needs of the Personas.  When some Personas only need part of what is described in a feature you might want to consider splitting the feature into smaller features.
  • Identifying multiple Personas is important even though the first deliveries will probably only target a few of them.  It is useful to know which Personas we are NOT targeting initially.  On the other hand,  I like to limit the amount of “invented” attributes we give the Personas and search for educated guesses or attributes we actually know.  Typical examples would be general computer skills, and whether the persona is more interested in efficiency or intuitiveness.
  • Estimation of effort needed to build a feature can be difficult.  Example: feature A, B and C all require same pattern to be established, thus whatever feature is built first is in reality going to require most effort.
  • I have so far not spent time attempting to come up with detailed estimates in terms of development effort.  Part of the reason is that we have had limited time available.  I do see that further detailing could bring out more value, but I also fear that building exact estimates before discussing architecture, UX and other important design aspects could create false expectations.  On the other hand, high-level MVP estimates were made to compare relative size of various MVPs.
  • There is a risk that spread in Effort and Value becomes too low.  Possibly lining them up by Effort or Value (instead of using the regular table) can help flush differences out.
  • The “Sequence Rows” in the “Sequence Feqtures” excercise should provide a steady flow of value without clogging the pipeline with too many heavy features.  Still, many find that concept difficult to grasp, primarily because one row in the diagram does not necessarily correspond to a sprint or any other known artifact.  Ordering features and identifying deliveries, on the other hand, are easily understood.
  • We never ended up running the showcase in the end.  Instead, we got pictures of all canvases produced onto a web-page and distributed the link to everyone interested in the project.  This approach is practical and robust in a geographically distributed reality.
  • In future workshops I plan to more actively use the product vision outcome and scope outcome during later steps in the workshop
  • It would be interesting to test whether running a “Design Sprint” after “Lean Inception” would make sense or whether the two frameworks are simply too similar.


Leaving out elements like architecture, layout etc. makes the framework lean.  Prescribed workshop duration is five days.  However, I claim that also shorter workshops could provide great value.  My last workshop lasted one and a half day, and we did execute most of the steps in the framework.  The workshop was intense, and it was a full-time job to facilitate and orchestrate time-boxing, but feedback was very good.  I am not convinced that three times the time would have provided three times the value for this particular project.

Author: Hans Olav Damskog

Process Improvement Director at confirmit.com. Former developer and product Team Lead