Review

The author provides a great practical workshop format for aligning stakeholders around an MVP definition. However, use this method with caution. The framework relies heavily on stakeholder opinions and prioritisation exercises, and I’ve sat in enough of those to know they can lead to biased outcomes. For best results, ensure you incorporate plenty of user research, data, and customer insights into the workshop to guide decision-making.

You Might Also Like:

Book Review and Summary: Escaping the Build Trap by Melissa Perri

In Escaping the Build Trap, Melissa Perri explains how companies can stop building features nobody wants and start focusing on creating products that deliver real value. By shifting from a build-driven to a product-led mindset, teams can prioritize customer needs, measure impact, and develop a clear strategy. The book outlines how product managers play a critical role in guiding organizations through this transition, emphasizing outcomes over outputs. Learn how to restructure teams, align strategies, and leverage research to escape the build trap and ensure that every feature delivers meaningful results. Perfect for product leaders aiming to build with intent.

andrewclark.co.uk

Evidence Guided

Directionally I think the advice in this book is spot on - we need more evidence guided product management. The author lays down one of the cleanest arguments to why an evidence guided approach is needed, and why opinion driven product is hopeless. The author also does a good job of hooking this approach into more traditional product development ways of working.

andrewclark.co.uk

Lean UX

In Lean UX, Jeff Gothelf combines Lean Startup, Agile, Design Thinking, and User Experience Design to create a collaborative and user-centered approach to product development. Lean UX focuses on reducing waste, fostering team participation, and adopting an experimentation mindset to achieve better outcomes. Instead of prioritizing outputs like features or documentation, teams are encouraged to focus on outcomes—measurable changes in human behavior that create business value. This approach allows for continuous learning through small, iterative experiments, where the emphasis is on solving user problems rather than building predetermined features. Ideal for product teams seeking a more agile, customer-centric method to deliver meaningful results.

andrewclark.co.uk

Key Takeaways

The 20% that gave me 80% of the value.

Lean Inception is a ThoughtWorks process designed to help you define an MVP and drive alignment amongst stakeholders. It doesn't replace the need for other research activities.

An MVP is the simplest version of a product that can validate the key business assumptions. It helps us understand if it's worth building further versions of the product. An MVP helps us understand if we're directionally correct.

Taking an MVP approach will get you to market quickly and cheaply and give you the opportunity to incorporate user feedback into the product development process sooner. All of which should increase the speed at which you're creating real value.

Your initial MVP is just the beginning. The magic happens in the increments and iterations that follow. Think of MVPs asevolutionary creation. Short development cycles and cheap experimentation to validate key hypotheses. Each future incrementtests a small part of the general hypothesis each time. In turn, this makes sure each aspect of the product is validated.

An MVP should provide a full slice of end-to-end value. It should be valuable, usable and feasible. You should also include something that creates an impression, a 'Wow!' moment. An MVP doesn't mean low quality.

Lean Inception 1 Week Structure:

• Monday: Kickoff; Product Vision; 'Product Is/Isn't Does/Doesn't'
• Tuesday: Describe Personas; Features Brainstorm
• Wednesday: 'Technical, UX & Business Review'; User Journeys
• Thursday: Feature Sequencer; MVP Canvas
• Friday: Showcase

Lean Inception Workshop Activities

The Product Is / Is Not. The Product Does / Does not. Explain the product by spending equal time defining what it does and doesn't do, what it is and what it isn't. You can do this by placing post-its on a 2-by-2.

Clearing the Objective. Each team member states their understanding of the 3 most important objectives for the product. Group for similarity on a canvas. Rewrite the objectives as a group.

Understanding trade-offs. Create and document key aspects that may need to be traded off (simplicity, security etc). Get folks to rank them and display their preferences. Then work together to build an agreed trade-off rank. Details here.

Describe the personas. Split into groups to create persona templates (Name, Profile, Behavior, Needs). Then present them back. Change groups and repeat until personas emerge. Create an empathy map for each persona (Think, Hear, See, Say, Pain, Gain). Then update the persona descriptions.

Feature Brainstorming. Describe features as simply as possible (e.g. print invoice). Focus feature creation around persona goals. Ask the team to state and prioritize the user goals (as columns) and personas (as rows). Limit the number of goals and personas (if we could only cater to a couple of these, what would they be?). Then add features that are necessary for the users to reach the goals. You can prioritize further by getting folks to vote or place tokens on important functionality.

Technical, user experience and Business Review. Assess each feature in turn, in terms of effort to build it, business value and user experience. Rank them on a scale of 1 to 3. Then assess how much uncertainty you have for each, in two dimensions (confidence in what to do, confidence in how to do it). You can combine these into a single measure of uncertainty. You must tackle the cards with high uncertainty - by dropping them, redefining them or clarifying them.

Show the users' journeys. Select a persona, identify a goal of theirs. Decide the starting point and describe each of the steps on a post-it note until they achieve their goal. Overlay the features onto the journey. Expect to identify missing features, and have features that don't support any important journeys.

Sequence the features. Keep asking which one of these two is a priority. Then ask what is the minimum combination of features that can be available to validate a small set of hypotheses of the business. Plan a sequence of waves. Make sure each wave has only a small number of features, no more than one that's highly uncertain, limit total effort scores, make sure each wave is valuable and if one feature is dependent on another that must have come in the wave before. Number your MVPs (could be a combination of waves).

Calculating Time Effort and Cost. If you need to, break features into tasks so they can be T-shirt sized individually.

Deep Summary

Longer form notes, typically condensed, reworded and de-duplicated.

Foreward

There’s value in setting direction before building a product, but we must do so remembering that such up-front thinking must be our most tentative.

Inception is getting together those affected by the product, and have an intensive sessions to set an initial direction.

The goal isn’t to get to a spec - instead it’s to understand…

• The outcomes we want to achieve
• The features we think will drive those outcomes
• How we’ll assess the effectiveness of the product

The process is geared towards identifying an MVP.

Part 1: Building the Right Product

Agile emphasises early and continuous delivery of valuable software. The Lean Startup approach is complementary - it promotes the incremental release of an MVP (Minimum Viable Product). An MVP is a simple version of a product that when distributed to users will validate the key business assumptions. It helps us understand if it’s worth building further versions of the product.

Lean Inception

Lean Inception is a ThoughtWorks process that helps define an MVP and drive alignment and a shared understanding between stakeholders. Even the most agile of initiatives require some upfront work. The process is an adaptation of ‘Inception’ which was originally developed by Jeff Patton and Jonathon Rasmusson. Inception aimed to get teams an effective plan (a list of prioritised user stories with estimates and a release plan). Lean Inception is a shorter process, done in just one week, with the goal of getting to a shared understanding of an MVP.

Lean Inception focuses on choosing features - to do that you need to understand:

• Who your users are
• What activities they perform that are supported by the product
• How you’ll measure if they find the product useful

The Lean Inception workshop doesn’t replace traditional activities (ideation, customer research, competitor analysis) etc.

The One Week Lean Inception Agenda

• MON AM - Kickoff, Write product vision
• MON PM - Product is/isn’t does/doesn’t do
• TUE AM - Describe personas
• TUE PM - Features brainstorm
• WED AM - Technical, UX and Business Review
• WED PM - Show Users’ Journeys
• THU AM - Feature sequencer
• THU PM - MVP Canvas
• FRI AM - Showcase

Minimum Viable Product

Taking an MVP approach encourages your team to get to market faster, reduces development costs and gets you to a point where you can integrate user feedback into your development process.

An MVP is the simplest version of a product that can validate the key business assumptions. It helps us understand if it’s worth building further versions of the product.

The goal is to understand if the MVP is directionally correct.

MVP was coined by William Junk MVP’s in this article in the year 2000.

The term MVP shouldn’t be used in isolation. The magic happens in the increments and iterations that follow - as the feedback either confirms the direction or prompts course correction.

• You can think of follow on increments or functionality as MVPs also. Their job is also to validate hypothesis and confirm direction.
• MVPs therefore promote evolutionary creation. Fast cycles to validate hypothesis, short release periods and cheap experimentation.

Build your product incrementally, add recently created MVPs to your existing product. This enables you to deliver value over time (vs a big bang launch).

An increment only has to test a small part of the general hypothesis each time. Enabling validation of ideas earlier, and easier to understand experimentation and results.

We’re looking to validate each aspect of the product.

The most important and valuable feedback is often a negative answer. When we discover a fundamental and important assumption was wrong.

Think big, but start small so you can learn fast.

An MVP should sit at the intersection of what is valuable (to the business), usable (accepted by users) and feasible (what can be built). BUT successful MVPs often still need a ‘Wow’ factor.

• We’re searching for a slice of end to end product functionality that is: feasible + viable + usable + wow.
• E.g. from an ARRR perspective, you’ll need to balance efforts across Acquisition, Activation, Retention, Revenue and Referral.
• You want to avoid the false positive, where you’re great at acquisition but there’s no reason to hang around.

First impressions are important, so don’t forget the wow.

For every complex problem, there is a clear, simple and wrong answer. H. L. Mencken

Part 2: Preparing for the Workshop

The Lean Inception Workshop

The success of the workshop depends on the groups ability to collaborate. Lace short icebreakers throughout: you can use them to help folks get to know each other, raise energy or learn something new as appropriate.

Create a war room and get everyone to work from there so you can collaborate face to face and build a wall of artefacts around you. Work with post-its and sharpies to keep thoughts fluid and simple.

Make sure you have a facilitator to guide the room and move everyone along. A good facilitator creates a shared sense of responsibility among the participants. They should be vocal about the process and timings but neutral in discussions. They should also take responsibility for the facilities. Use a parking lot to capture important things that you can’t fully address quickly. You can use a burn-up agenda, where you add activities you’ve done to the plan for the week and replan as needed. This helps with group awareness and responsibility.

Keep your Lean Inception team small, and invite other key stakeholders to the Kick-off and Showcase.

Lean Inception Workshop Activities

The Product Is / Is Not. The Product Does / Does not. Explain the product by spending equal time defining what it does and doesn’t do, what it is and what it isn’t. You can do this by placing post-its on a 2-by-2.

Clearing the Objective. Each team members states their understanding of the 3 most important objectives for the product. Group for similarity on a canvas. Rewrite the objectives as a group.

Understanding trade-offs. Create and document key aspects that may need to be traded off (simplicity, security etc). Get folks to rank them and display their preferences. Then work together to build an agreed trade-off rank. Details here.

Describe the personas. Split into groups to create persona templates (Name, Profile, Behaviour, Needs). Then Present them back. Change groups and repeat until personas emerge. Create an empathy map for each persona (Think, Hear, See, Say, Pain, Gain). Then update the persona descriptions.

Feature Brainstorming. Describe features as simply as possible (e.g. print invoice). Focus feature creation around persona goals. Ask the team to state and prioritise the user goals (as columns) and personas (as rows). Limit the number of goals and personas (if we could only cater to a couple of these, what would they be?). Then add features that are necessary for the users to reach the goals. You can prioritise further by getting folks to vote or place tokens on important functionality.

Technical, user experience and Business Review. Asses each feature in turn, terms of effort to build it, business value and user experience. Rank them on a scale of 1 to 3. Then assess how much uncertainty you have for each, in two dimensions (confidence in what to do, confidence in how to do it). You can combine these into a single measure of uncertainty. You must tackle the cards with high uncertainty - by dropping them, redefining them or clarifying them.

Show the users’ journeys. Select a persona, identify a goal of theirs. Decide the starting point and describe each of the steps on a post-it note until they achieve their goal. Overlay the features onto the journey. Expect to identify missing features, and have features that don’t support any important journeys.

Sequence the features. Keep asking which one of these two is a priority. Then ask what is the minimum combination of features that can be available to validate a small set of hypothesis of the business. Plan a sequence of waves. Make sure each waves has only a small number of features, no more than one that’s highly uncertain, limit total effort scores, make sure each wave is valuable and if one feature is dependent on another that must have come in the wave before. Number your MVPs (could be a combination of waves).

Calculating Time Effort and Cost. If you need to, break features into tasks so they can be T-shirt sized individually.

Connecting the canvas back to Build, Measure, Learn… Features (build), Metrics (Measure), Expected Outcome (Learn).