A useful MVP is not simply the smallest version of a product. It is the smallest coherent release capable of reducing the uncertainty that matters most.
Start with the decision, not the feature list
Before prioritising screens or capabilities, define the decision the first release should help the team make. Are you testing whether users care enough to adopt the workflow, whether an operational model is feasible, whether a paid proposition is viable, or whether a technical dependency can work reliably at the required scale?
Separate desirability, feasibility and viability
List the assumptions behind the product and group them into three areas: whether users want the outcome, whether the team can deliver it reliably, and whether the model can create sustainable value. The most dangerous assumption is not always the most visible one.
Build evidence into the release
The product should capture the behaviour or operational signal that answers the key question. That may mean measuring completion, repeat use, conversion, turnaround time, operational effort or another outcome that reflects the hypothesis.
Avoid fake completeness
A first release does not need every future workflow, role, integration or automation. It does need enough coherence that real users can experience the value proposition without being distracted by temporary shortcuts.
Practical checklist
- Define the learning objective before the backlog.
- Keep the first release coherent for a real user.
- Build only the architecture that must be real now.
- Decide in advance what evidence would justify the next investment.