What is an MVP, and what question should it answer?
When planning MVP development, write the learning question explicitly. Does the customer experience the problem, understand the solution, use it again or show willingness to pay? These are different assumptions. One first release should not be treated as definitive proof of all of them.
Minimum does not mean a fixed number of screens or features. It means excluding scope that is unnecessary for the selected test. Viability means that the participant can obtain the promised core benefit. In a booking product, selecting an available time and receiving confirmation matters; a half-built calendar cannot produce equivalent learning.
An MVP supports a decision. Unexpected behaviour can be useful evidence, but it does not automatically establish that the whole idea is wrong. A broken journey, unsuitable participants or an unclear offer can provide alternative explanations. Knowing what the experiment actually tests helps avoid premature conclusions.
Keep the original uncertainty visible throughout delivery. Otherwise the team can finish a polished release while losing track of the question that justified building it.
How do prototypes, technical trials and MVPs differ?
Researching the product and customer need does not always require a complete application. Interviews help explain past behaviour and current alternatives. A clickable prototype can test whether a journey is understandable. A technical trial can assess whether a necessary integration or device capability is feasible.
A manually delivered service experiment can explore whether the benefit is valuable before automation exists. Describe the product's actual state and manual steps honestly. Presenting unavailable capabilities as already working can undermine expectations and the usefulness of the resulting evidence.
These activities cannot all validate the same things. Liking a prototype does not prove willingness to pay for the working product. A successful technical connection does not establish customer demand. Choosing the appropriate method for the question is the scope decision that can reduce unnecessary development.
For the working software release discussed here, the participant must be able to complete the intended core task. That requirement is distinct from whether a visual prototype can be used earlier in the learning process.
| Method | Question investigated | Not established by itself |
|---|---|---|
| Interview | What is the problem and current behaviour? | Real use of the new product |
| Prototype | Is the journey understandable and usable? | Payment or repeated use |
| Technical trial | Can the necessary capability work? | Customer demand |
| MVP or pilot | Is the core benefit used in a real context? | Success across the entire market |
FROM READING TO A NEXT STEP
Identify the assumption your first release should test
Share the intended customer, existing alternative and proposed benefit. We can define the core workflow, exclusions and learning criteria.
How do you select the first complete workflow?
When working with a technical partner, describe the journey from entry to outcome. How does the user arrive, what information is needed, what action is completed and how do they know it succeeded? Features beyond that journey can be recorded in a later-release list.
In a booking example, the user finds a suitable time, supplies necessary details and sees the reservation status. An operator manages availability and handles the booking. Complex loyalty programmes, personalisation and additional reporting might wait; making the reservation invisible to the operator would break the core benefit.
This example illustrates scoping rather than reporting a measured Prix customer project. For every proposed feature, ask whether the selected question can be tested credibly without it. Do not decide only by team voting or by choosing the easiest items.
When a risky capability is essential, reduce uncertainty with a focused technical trial. A collection of easy components that cannot complete the user's task is not a useful minimum release.
How do you reduce scope without abandoning quality?
A testing and release process helps verify changes in the first version as well as later ones. Correct records, appropriate access, understandable failures and completion of the critical journey are necessary. “We will fix it later” is not an adequate plan for losing user data or failing the promised task.
Some operations can initially be manual. Record which steps they are, who owns them and what participant volume the team can support. A limited operation that actually delivers the benefit is different from a promise the team cannot fulfil. Explain excluded features and limitations to participants.
Technical debt can be a deliberate choice. Document the deferred improvement, reason and condition for revisiting it. Assign maintenance ownership to temporary decisions rather than letting them become permanent by accident.
Rewriting every piece of initial code is not inevitable. Treating every experiment as the permanent foundation is also unwise. The right choice depends on what has been learned and what the next release needs to support.
How do you define success, change and stopping criteria?
The measurement plan should follow the assumption being tested. Completion of the first task, repeated use, an actual payment and delivery of a service are different evidence. Registration can indicate interest without showing that the user obtained the benefit.
Specify the participant group, observation period and evidence that would justify continuing. There is no threshold suitable for every product. A tool used for a single event and a weekly work product should not share an arbitrary repeat-use requirement. Separate test and team accounts from actual customer behaviour.
Consider the change or stopping condition in advance. If the expected behaviour does not appear, examine faults, audience selection and experiment conditions before interpreting the result. Continuing to add features simply because money has already been spent can delay useful learning.
Collect necessary behavioural information without putting personal details into ordinary analytics events. The objective is to understand the task, not to accumulate every available piece of user data.
How do early-user findings shape the next release?
Technical leadership support can connect observations with delivery decisions. Read application events alongside support conversations. Stated preferences, actual behaviour and unfinished tasks are different forms of evidence; avoid substituting one for another.
Do not implement every request immediately. Ask whether it is specific to one user, blocks several intended users or suggests that the target audience was defined incorrectly. Derive the next scope from that distinction. Keep observation, interpretation and decision separate in the learning notes.
The next action might be to deepen the workflow, revise the experiment or stop. If the initial result is encouraging, investigate operational capacity and repeatability too. Completing an MVP does not guarantee product-market fit or investment.
The useful output is evidence that supports a better next decision. Record what remains uncertain so a successful small pilot does not quietly become an unsupported claim that the whole market has been validated.
Select the question and workflow
Record the critical assumption, intended participant and main job to be completed.
Gather evidence
Review real task events, failures and user conversations together.
Make the next decision
Connect continuation, revision or stopping to findings, then define the next scope and owner.
BEFORE YOU DECIDE
Frequently asked questions
Does MVP mean disposable code?
No. Some experiment components may change, but ignoring maintenance, permissions and record correctness is not the objective. Document temporary choices and the condition for revisiting them.
How many features should an MVP contain?
There is no fixed count. The relevant scope supports the assumption and complete main task. Features unrelated to that task can be deferred.
Is an MVP the same as a prototype?
The terms are used differently in some contexts. Here, a prototype tests interaction and understanding, while a working MVP tests the core benefit in real use.
Should the first release be free?
That depends on the business model and learning question. Free use does not validate paid demand. When pricing is tested, describe the offer and actual product state clearly.
How long does an MVP take to build?
The workflow, integrations, necessary capabilities and acceptance requirements determine the effort. A universal timeline or budget is unreliable before scope is defined.
Does a positive MVP result establish product-market fit?
Not by itself. Use in a narrow group does not prove sustainable demand or operations across a wider market. Further assumptions still need testing.
LET’S DEFINE THE SCOPE
Identify the assumption your first release should test
Share the intended customer, existing alternative and proposed benefit. We can define the core workflow, exclusions and learning criteria.
Review my MVP scope