MVP guide: test product value with a complete first journey

Minimum is not the same as unfinished

The right minimum depends on the question. If you want to know whether a manager uses a report to make a decision, manually producing that report may be sufficient. If you want to test self-service onboarding, that same manual intervention hides the behaviour you need to observe.

Write the hypothesis before the backlog. “Users will create a report” describes activity. “Users will use the report in their weekly planning meeting” is closer to value. Specify the context and how you will distinguish curiosity from adoption.

Choose an end-to-end journey

Describe the trigger, necessary data, main action and useful outcome. Include failure paths that can prevent completion. Password recovery or a clear invalid-import message may be more important than sophisticated visualisation.

The team also needs to operate the MVP. Provide a way to assist users, correct data and understand incidents. A simple product does not eliminate these responsibilities; it narrows them to a manageable context. Decide who handles them before bringing in pilot users.

Judge features by their contribution

This is a discussion framework, not an automatic scoring model. One integration may be essential because a pilot customer’s data lives there. A frequently requested feature may still contribute little to the main task. Tie each inclusion to the hypothesis or to a concrete operating requirement.

Plan the learning loop

Before release, decide what to observe: task completion, assistance required, repeat use and obstacles. Pair behavioural evidence with qualitative conversations. Low usage could reflect weak value, poor understanding or a technical failure. These causes require different responses.

Record manual interventions. If the service appears autonomous while the team repairs every import, you may overestimate readiness. Make the pilot arrangement clear and use it to identify which operations would need automation. Manual work can be a deliberate experiment; hidden manual work can distort the conclusion.

A worked scope example

For a fictional partnership-management tool, the first journey could cover adding a prospect, assigning the next action and reviewing conversation history. Automatic proposal generation is not necessary to test whether the team follows up more consistently. Finding a contact and knowing who owns the next step may be essential.

What happens next depends on evidence. If the team does not know whom to approach, a better CRM may not solve the original problem. The useful outcome of the MVP could be a changed scope, not a larger interface. Keep this possibility open when agreeing on success criteria.

Write an experiment card before filling a backlog

Record the hypothesis, participants, task, test setup, observable signal, limitation and possible decision on one page. For a fictional document-collection product, the hypothesis might be that a shared checklist prevents redundant follow-ups. Recruit both a coordinator and a contributor to assemble a representative pack. Observing only the coordinator misses half the experience.

Track duplicate requests, missing documents, interruptions and assistance. Compare with the existing workflow while acknowledging contextual differences. A small pilot does not establish a general statistical effect, but it can expose a clear obstacle worth fixing. Do not turn a positive anecdote into a quantified commercial promise. Keep the distinction between observation and inference visible in the review.

Record what can distort the evidence

A participant who never received an invitation has not rejected the value proposition. A task completed because the founder performed every difficult step does not demonstrate independent usability. Record support interventions, incidents and rule changes during the trial. Those notes explain what product events alone cannot.

Hold a decision review, not another demo

Bring positive and negative evidence together, then choose whether to continue, change or stop the hypothesis. Proposed features should address an observed problem or an explicit risk. If access to trustworthy data is the main obstacle, adding polished animations will not supply the missing evidence. Name an owner and a next observation for each decision.

Do not preserve the MVP indefinitely as a cheaper copy of an imagined future product. Some manual operations may remain useful; others become unacceptable as volume grows. Document where the manual boundary lies, why it was chosen and what would trigger automation. This lets the next team distinguish a deliberate experiment from an overlooked implementation gap.

Workshop: separate adoption from a heavily assisted pilot

A pilot may appear successful because its team personally helps every participant. Assistance can be useful for learning; the problem is attributing its effect entirely to the product. Make that distinction visible with a simple observation record for each session instead of inventing a single satisfaction score.

Consider a tool that turns meeting notes into proposed tasks. The tested journey ends when a manager has corrected the suggestions and assigned a useful task, not when someone clicks Generate. Observe starting the workflow, understanding suggestions, making corrections and carrying the output into ordinary work as separate stages.

Write down the interventions allowed before each session. You might explain the purpose of the exercise while avoiding an immediate demonstration of where to click. Record every subsequent intervention: clarifying terminology, correcting input data or completing a step on the participant’s behalf. These notes help distinguish an interface problem from a missing capability.

Keep abandoned attempts in the analysis. Someone who never starts may lack time, necessary data or the need you intended to serve. Follow up where the pilot arrangements allow it, but do not remove the case from your records to improve apparent results. For a small group, the reasons behind individual outcomes can be more useful than an isolated percentage. Report how participants were recruited and whether they already knew the team, since those conditions affect interpretation.

At the review, select one change addressing the main observed obstacle and describe what the next session should demonstrate. If people cannot access their meeting notes, improving generation quality does not remove that blocker. If suggested tasks are unusable, an additional reporting screen does not validate the promise either.

This practice turns a pilot into a traceable sequence of decisions. It also protects the budget: the next implementation addresses a recorded obstacle instead of accumulating every idea mentioned during demonstrations. Preserve a separate list of interesting requests so they can be reconsidered without silently expanding the current experiment.

Frequently asked questions

Can a prototype be an MVP?

A prototype can answer some questions about understanding or navigation. It does not necessarily establish repeat usage, willingness to pay or operational reliability. Choose the format around the hypothesis rather than a rigid label.

When should we build the fuller product?

When observations support the next investment: the problem is recognised, the journey creates identifiable value and the main barriers are understood. A long feature request list is not enough on its own.

Should we charge for it?

Charging may help test a commercial hypothesis, but it changes expectations. Define the service, limitations and pilot terms clearly. Do not present an experimental product as an established, fully supported service.

Examples are educational and do not describe client results. Content prepared with AI assistance; see our editorial policy. Our method ↗