Define one customer problem with evidence
Preparation for founder MVP development starts with a user problem rather than a technology request. An illustrative problem such as “dealers message the team every day to ask for order status” can be investigated; “we need a mobile app” is a proposed solution. State who experiences the problem, when it occurs and how they manage today. Keep founder assumptions separate from observations made in user interviews.
Use interview notes, existing workflows and support records as evidence. Positive feedback from friends does not represent demand across a market. Select one main problem that the first release will address, while recording other problems for later research. When evidence is weak, plan an interview or prototype trial before committing to software. Explain which uncertainty that activity will resolve, and who will decide whether there is enough evidence to proceed.
Separate the primary user from the first useful outcome
In a technical partner discussion, distinguish the buyer from the daily user. A manager may pay for a B2B product while field staff complete tasks and operations staff correct records. Explicitly choose the first release's primary role. “Everyone will use it” mixes different needs into one flow and leaves permission boundaries unclear.
Describe the first useful outcome in observable terms: for example, a dealer signs in and sees the current status and next step for their own order. Successful sign-in alone does not provide that outcome. List the data, permission and explanation needed to reach it. If invitations or account verification are necessary, include them in the flow. Make supporting manual work visible alongside the outcome promised to the user.
Primary user
The role completing one defined task in the first release. Test devices, working conditions, existing habits and access permissions around that role.
First useful outcome
An observable result that advances the user's work. Registration and button clicks are intermediate actions, not substitutes for the result.
FROM READING TO A NEXT STEP
Review the scope of your MVP
Share the problem, primary user and first useful outcome.
Map the essential flow and later releases explicitly
When scoping a web application, show the starting point, normal result, empty state and recovery from failure in one journey. A happy path is incomplete when missing data traps the user. In an illustrative order screen, no records, insufficient permission and an unavailable service each need a different explanation and next action.
Explain how every feature serves the first useful outcome. Advanced reports, extensive personalization, many integrations and loyalty features can be deferred if they are unnecessary for that outcome. Access control, critical error information and essential administration cannot simply disappear into a later release. Record which acceptance criterion a scope change affects. Adding work requires removing another task or reassessing delivery effort, timing and cost; a silently growing feature list is not a controlled scope.
Include data sources and administration
For API and data scope, record where each field originates, who updates it and how current it must be. Demonstration data is different from information that supports a real user decision. If external access is unavailable, keep that dependency visible. Define how an authorized person corrects a wrong record, cancels an action or supports a user.
A full administration interface may be unnecessary when a controlled operational method is sufficient. But that method still needs access limits, change ownership and a way to detect errors. Avoid collecting user data without a real requirement. Use synthetic or authorized data in trials, and record access and deletion responsibilities. If an integration is delayed, test an alternative that still supplies the first useful outcome. Do not describe a manually updated process as automatic.
| Scope area | Evidence | Decision and owner |
|---|---|---|
| Order status | Source field and update example | Operations; acceptable data delay |
| Permission | Tests with two distinct roles | Product owner; visible-record boundary |
| Correction | Recovery from an incorrect record | Support; procedure and audit record |
Write criteria around outcomes and failure behavior
For MVP acceptance, replace “screen finished” with a starting condition, action and observable result. For example, an authorized dealer opens the list and sees only their orders; if the service is unavailable, retry information appears. This lets design, development and review teams test the same behavior. Technical acceptance should not be confused with an unverified revenue target.
The GOV.UK discovery guidance recommends understanding the problem and constraints before building. In your project, specify evidence for each criterion: an example record, screen result or task observation. Record the test date and application version. The product owner decides whether open findings require correction, acceptance or further research. “It works for now” cannot replace a defined retest condition.
Plan user trials and maintenance ownership
In founder and technical-team collaboration, the first trial needs a more precise purpose than asking whether people like the product. Can a user complete the task without assistance, is the data sufficient, and does the result help their work? Define the tasks and observation method before the trial. State sampling limits rather than assuming participants represent every intended user.
After the trial, assess evidence for continuing, narrowing, changing direction or stopping. Registered-user totals alone do not demonstrate recurring value. Before live use begins, assign responsibility for incident reports, access removal, dependency updates and data corrections. Every unresolved risk needs an owner and another review date. This checklist organizes scope decisions. It does not guarantee product-market fit, investment or completion within a particular period.
Get the checklist and discuss your scope
Your email and phone are used for this request. This does not subscribe you to a newsletter.
BEFORE YOU DECIDE
Frequently asked questions
Must an MVP be software?
No. A prototype, interview or controlled manual process may be enough to investigate a risky assumption. Explain which parts are real and which are experimental to participants. Commit to software when building it is actually necessary to obtain the evidence you need.
How do we define minimum scope?
Map the essential path to the first useful outcome. If removing work prevents that outcome, exposes incorrect data or leaves the team unable to provide basic support, it belongs in the minimum scope. Reducing screen count alone does not define a useful boundary.
Do we need an admin dashboard initially?
It depends on activity volume and access requirements. A controlled internal process may work temporarily. Define record corrections, permission changes and audit records. Requiring a developer to make every change manually is not a complete long-term operating plan.
How many people should join a trial?
There is no single correct number for every product. Cover critical roles and circumstances, then track repeated findings and unresolved questions. Do not present a small usability trial as statistical proof of market demand. Record what further investigation the evidence requires.
How should we handle a new feature request?
Relate it to the problem and first useful outcome. If it does not alter initial acceptance, it may belong in a later release. If it changes scope, reassess effort, dependencies and testing. Record the decision before expanding the build list.
LET’S DEFINE THE SCOPE
Review the scope of your MVP
Share the problem, primary user and first useful outcome.
Discuss MVP scope