This article is the second in a series of articles about our experience with Lean Inception. Be sure to check out our other posts.

At Foci, when we completed our own Lean Inception process, we ended up with some solid artifacts and a good understanding of our Minimum Viable Product (MVP). We also learned a lot about the process of running exercises and came away with some valuable lessons for the future. Here are some of our key takeaways and recommendations for running your own Lean Inception.

Prepare to Deal With Discomfort and Unknowns

We Don’t Know What We Don’t Know

There are a lot of unknowns at the start of a project. At the outset, stakeholders and product owners don’t necessarily know what features are crucial or how things should be prioritized. Engineers don’t know what tech stack they’ll be using or how they’ll be solving the core problems of the product. Unknowns like these are often the cause of the greatest pain points for teams, but are necessary for successful Lean Inception.

For Lean Inception to work, there has to be an understanding that much of what will be decided at the outset is a ‘best guess’. At the outset, it is important to get every participant to accept that there will be some unknowns and some discomfort throughout the process. This discomfort is not to be ignored, but simply accepted in order to move forward. After Lean Inception is complete and development begins, additional features will be implemented and adaptation will be necessary to complete the project. 

Learn to Compromise

In addition to unknowns and best guesses, there will be a lot of compromises as things go forward. All parties need to come to the table ready to compromise—a large part of the facilitator role will be coming to compromises within the team and ensuring they are respected throughout the process.

When crafting a project vision and project goals, there can often be a desire to shoot for the stars—which can potentially push people out of their comfort zones. For Lean Inception to work, everyone needs to be ready to take their wildest dreams for the product and scale them back to much more modest expectations at the outset.

Certain features and goals that might seem essential for the final product may be cut at this early stage; it is important to keep in mind that the goal at this stage is to create just enough of a vertical slice to create a product to validate the base assumptions of the vision. Perhaps at this stage the product will not have all the features that stakeholders want, but it is essential that they understand that there is a need to deliver a feasible product first, and add more features later.

Focus on the ‘What’, Not the ‘How’

In our session at Foci, we became so blocked with the ‘how’ of implementing features that we had to run a side exercise to unpack a lot of the ideas; we could have spent days trying to figure out the ‘how’.

Engineers in particular must be prepared to reign in and ‘park’ discussions about implementation. Engineers are problem solvers—it’s their job to think of the ‘how’ of building each part of the product. Shifting our thinking in terms of ‘how’ (for example, “We can’t have that feature because I have no clue how to build it”) to ‘what’ (for example, “What we need a feature that notifies the user”) allowed us to shelve the ‘how’ talk and focus on a higher level with less detail.