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

Don’t Let MVP Get In the Way

The conversation around scope is crucial to not only defining what the scope is, but also what the scope isn’t. Is it the final version of the product? Is it a wireframe mockup for usability testing? Is it the ugly, first working prototype of your product? We had to ask ourselves all of these questions as we went through our own Lean Inception process.

For us, we became bogged down with how extensive the functionality of our MVP should be. Toward the end of the process, we ended up shifting our conversation away from our MVP—because it wasn’t as important for the scope of our Lean Inception process—toward the things that were crucial to our scope, which were the first two product iterations and a target audience that we could engage at that stage of the product development. Recognizing what wasn’t needed and making ‘MVP’ an out-of-bounds term helped us to re-envision the first iteration of the product and allowed us to focus on solving the specific problems in front of us.

Manage Scope Constantly

Throughout the process, team members are going to ask, “What’s the scope of this exercise? Green field? MVP? Alpha testing?”. At the outset of Lean Inception, everyone wants to shoot for the stars. While that is a great place to start, over time you need to narrow that aspiration down to a tiny scope for your first iteration. What is the single-use case or feature that embodies your product and can be tested for success? That’s a big change in a very short time.

We spent much of our first two days working in the green field space, which made it all that much harder when we had to trim down our scope to just the essentials. We had come up with some really interesting features, but they were in no way core to the product.

We were able to gradually reduce the scope from one exercise to the next by scaling back from the green field product vision to the 1.0, then the MVP until we arrived at the core outcome we wanted, which gave us the first test to validate value in our core product.

Use Outcomes, Not Goals

During Lean Inception, a number of goals are often set for the product—these goals are generally things the product does. It’s easy to create a mammoth list of goals covering every aspect from UI clarity to security hardening, which is why it is important to make sure the goals you’re discussing are valuable to the goal of the exercise.

At Foci, we preferred the term ‘outcomes’ to ‘goals’. Outcomes are more synonymous with a tangible result while goals can often tend towards the vague. You can also set up a corner of your Parking Lot for the Definition of Done. You ‘park’ features in your ‘Parking Lot’ that are essential concerns, but not part of your core outcome. Security, user privacy, reliability, and documentation are all examples of essential parts of a project that you likely want as part of your first iteration, but, at the outset, they may get in the way of a clear understanding of the specific value your product will offer.

Prioritize

During Lean Inception, we used the priority exercise from the ‘Discover the Features’ section on ‘Discover the Features’ section on Martin Fowler.com. This exercise was essential for exposing our bias for what we thought were essential features that actually didn’t matter to users. If outcomes cannot be tied to priority user journeys then it becomes easy to see what needs to be set aside in order to complete the Lean Inception.

Whatever the exercise, there are a few ways to help maintain productive focus throughout Lean Inception. We found the exercises were most successful when people were split into small breakout groups, strict  time limits were applied, and clear examples were given. Smaller groups allowed everyone to contribute and debate perspectives more efficiently; the larger the group, the more precious time required to examine each input. Limiting time also helped keep things on track since participants are less likely to pursue tangents when they are aware that there isn’t time for off-topic discussions. 

Have Multiple Samples Ready

With strict time limits to run exercises, it is important that groups understand their objectives—clear examples are essential. This point also ties back to narrowing the scope. For example, if you are trying to change the focus from a fully-featured version 1.0 to a less refined but functional beta, having sample outputs for the activities aligned to the language and scope will help. Try to have multiple sample outputs for each exercise as well. These samples will be key tools in keeping groups moving fluidly through each exercise.