Why use Lean Inception?
When we go into our workshops, we’re often faced with very little information and several stakeholders with different priorities and ideas about what needs to be done. It’s not possible to immediately make everyone happy, so our process helps us create a constructive dialogue between members of the same team who come into the workshop with different needs. Through compromise and facilitated discussions, it gives us all a common goal to work towards and levels out everyone's expectations. This board is our interpretation of the Lean Inception approach and represents our learned experiences so far. We use it as a base and continue to modify it based on each workshop's needs. It helps us define the problem in the best possible way and get to a clearly defined MVP.
How is Lean Inception different from a Design Sprint?
We were interested in the problem-solving approach in the Design Sprint and the Lean Inception. The methodology was based on so much real experience from their creators that we wanted to give it a shot. The Design Sprint method solves a different kind of issue than the Lean Inception one. The questions are different, as is the end result. As we went through them, we realized that the demands coming from our clients wouldn’t really fit either method - but a combination of both worked like a charm. Sometimes we also need to adapt the length of the workshop. We don't always have the 5 days both methodologies ask for - so we make it work in 3 days by cutting some of the activities. It's a bit more intense but works well both for our clients and us. For example, we normally don't need to calculate the effort, time and cost - we try to go into the workshop with a ballpark figure regarding these estimates. However, this is an individual approach that works well for us, as we are in charge of both facilitating and developing the MVP in question.
The Lean Inception method gives you a great place to start from - defining and developing an MVP. This was most of what we needed to do. But in the end, it leaves you without a visual idea of what needs to be done. We feel that the visual representation of the problem being solved is like the cherry on top of a well-defined MVP. That is where you can see that everyone is on the same page and you all understand the MVP properly. So we borrow the sketching part of the Design Sprint and incorporate it into our approach.
