MVP workshop: how to define the smallest first delivery

What is an MVP?

Minimum viable product is a way to learn about a critical assumption with as little effort as practical. It need not be a complete software product: a manual service, a simple trial or a working first release can be appropriate. What matters is the evidence needed for the next decision.

We use the workshop below to define a small, useful first delivery for a business system. A prototype can test usability or a workflow before that delivery. A polished interface is not evidence that the architecture, access controls or operations are ready.

When you build with AI

Bring your AI-built prototype to the workshop as a discussion aid. Start with the problem and the value, not the list of features already built. Test it with fictional or approved data and identify which assumptions the prototype actually answers.

Keep requirements for security, access controls, data handling, integrations and operation on a separate must-do list. You can defer an optional feature; you cannot defer a safeguard needed for the intended use. Involve technical expertise early when these constraints affect scope.

After the workshop: decide what can be reused, what needs investigation and who assesses the architecture before development continues.

When is an MVP workshop the right choice?

• The initiative is about to start and you need to agree on the first delivery.
• The scope keeps growing and nobody dares to say no.
• Stakeholders have different pictures of what the first delivery should contain.
• Time and budget are fixed, so the content must adapt.
• It is a new product or a new market where much is uncertain.

It is a poor fit when the problem and users are not yet understood at all. Then you first need user interviews or a pre-study. Nor does it work if the decision makers cannot attend, because the workshop must end in a decision.

Workshop agenda: three hours

Our suggested format for an initiative with a clear problem. Each step is timeboxed and ends in a concrete result.

If you are fewer or short on time, merge the hypothesis with the problem step. If you have more time, add a step with user interviews or a demo of similar solutions before exercise 2.

Preparation and materials

• The right people, five to nine: product owner, sponsor or decision maker, one or two from the development team including an architect, and at least one who represents the users or the business.
• A facilitator who does not own the content. The facilitator keeps time and process; the product owner owns what is decided.
• Pre-question: ask participants to write down which problem they think the initiative should solve, and for whom, before they arrive.
• Materials: a large wall or whiteboard, sticky notes in three to four colors, markers, dots for voting, a timer and the MVP canvas printed in A3 or projected.
• A parking lot: a space for questions and technical discussions that do not belong right now.

The exercises step by step

Six exercises that together fill the MVP canvas. Use them as they are or pick the ones that suit you.

Exercise 1: Goal and success measure

15 minAgree on what the initiative should achieve and how you will know you succeeded.

How to do it

1. Let everyone silently write a goal on a sticky note (2 minutes).
2. Read them out and group them. Pick or merge into a single goal.
3. Make the goal measurable: add a measure and a date.
4. Define wild success: a level you do not count on, but that would exceed expectations.

Questions to ask

• How will we know we have succeeded?
• Which date applies?
• What would be beyond expectations?

Result: a measurable goal with a deadline and a wild success level.

Exercise 2: Problem and users

30 minUnderstand who has the problem and what it looks like today.

How to do it

1. List every conceivable user group, one per sticky note.
2. Vote for the primary user (for example three dots per person).
3. For the primary user, describe how the problem is solved today and what is painful about it.
4. Write the problem in one sentence: [User] needs [need] because [reason], but today [obstacle].

Questions to ask

• Who has the problem most?
• How do they solve it today, and what does it cost them?
• Why is it important to solve right now?

Result: one primary user and a problem statement everyone can stand behind.

Exercise 3: Value hypothesis

20 minTurn the expected value of the initiative into something testable.

How to do it

1. Write the hypothesis using the template: If we deliver [solution] to [users], [behavior] will change, which we will see in [measure] by [date].
2. Set a threshold: how big a change is enough for us to say the hypothesis held?
3. Read it aloud. Does everyone understand what is to be proven?

Questions to ask

• Which behavior should change?
• How do we measure it, and what is the baseline today?
• How big a change is enough?

Result: a hypothesis with a measure, a threshold and a date.

Exercise 4: The ideas and the cut

60 minCut down to the smallest thing that gives value. First collect everything, then cut.

How to do it

1. Collect (20 min): everyone silently writes features and ideas, one per sticky note. Group duplicates.
2. Cut (40 min): sort each idea into one of three columns: Must, Later or Never (not in this phase).
3. Ask the test question for every idea in Must: Can the user get value without it? If so, it moves to Later.
4. Keep the Must list short, five to seven things at most. Then cut harder: if we could only do three, which ones?
5. If you disagree about the order, run a quick prioritization matrix on the ideas that remain.

Questions to ask

• Can the user get value without it?
• Can we do it manually first, for example with a person instead of a system?
• Do we need to build it, or can we buy or reuse it?
• What happens if it is not in the first delivery?

Result: three lists (Must, Later, Never) where Must is your MVP.

Exercise 5: Assumptions and risks

25 minFind what must be true for the MVP to work, and test the most uncertain first.

How to do it

1. Write down all assumptions: we assume users will…, that we can…, that the customer wants…
2. Place them on a two-axis chart: how sure are we (sure–unsure) and how big is the consequence if we are wrong (small–large).
3. Mark the assumptions that are uncertain and have a large consequence. These are tested first.
4. For each marked assumption: how can we test it cheapest and fastest?

Questions to ask

• What must be true for this to work?
• What do we know, and what do we merely believe?
• How can we get an answer within a week?

Result: the three most important assumptions and how they will be tested.

Exercise 6: Measure, first experiment and decision

20 minFinish with a decision, an owner and a date.

How to do it

1. Decide how the outcome is measured and what level means success.
2. Define stop criteria: which results lead you to continue, change direction or end?
3. Decide the first delivery or experiment, with an owner and a date.
4. Set a follow-up date when you make the decision.

Questions to ask

• Which result makes us continue, and which makes us change direction?
• Who owns the next step?
• When do we make the decision?

Result: a short action plan with owners and dates, and a decision date.

Questions that cut scope

When the group wants everything included, the right question is often worth more than an argument. Keep them visible in the room:

• Can the user get value without it?
• What is the smallest thing we can deliver to learn whether the hypothesis holds?
• Can we do it manually first?
• What happens if we do not do it in the first delivery?
• Which user needs it on day one?
• If we could only deliver three things, which would they be?
• Do we need to build it, or can we buy or reuse something?
• How quickly do we get feedback on it?
• What is the worst that happens if we are wrong?

Common pitfalls

• The decision maker is missing. The result then becomes a recommendation that changes afterwards.
• The Must column becomes everything. Set a cap on the number of items and use the test question.
• The MVP becomes “version 1 with everything”. An MVP answers a question; it is not the first stage of a finished product.
• Only features, no hypothesis or measure. Then there is no way to know whether the MVP succeeded.
• Opinions instead of evidence. Gather user insight before the workshop or plan to test the assumptions afterwards.
• Technical discussions take over. Park implementation details, but address security, data and integration constraints immediately when they affect feasibility.
• No owner or date. A workshop without a decision, an owner and a date gives insight but no change.

As a facilitator it helps to let everyone write silently first, timebox firmly, vote with dots instead of discussing to consensus, and stay neutral on the content.