Name the uncertainty
Before listing features, state what is still unknown. Can a target user understand the idea? Can they complete the core task? Can the proposed workflow fit into the way they already work? Different uncertainties need different kinds of evidence.
Choose the smallest credible format
A prototype can help evaluate a journey before engineering the whole product. A demonstration can make an unfamiliar capability tangible. A focused MVP can support real use of an essential workflow. None is automatically the right first step; each earns its place by answering a defined question.
Set a boundary before the build
Agree what belongs in the first version and what can wait. Include the conditions that make the experience credible: realistic content, clear error states and a usable path through the main task. A smaller scope should still let someone reach a meaningful outcome.
Decide what happens after feedback
Define in advance what would lead to refinement, further investment or a change of direction. Then observe people using the result and record where their behaviour differs from your assumptions. A useful first build leaves the team with a clearer decision, not just a longer feature list.
Give the first build a decision to serve.
Complete this sentence: “We need to see whether [type of user] can [important task], so we can decide [next investment or change].”
- What behaviour would help answer that question?
- Which format makes that behaviour possible to observe?
- What content, data and error states make the task credible?
- What would lead you to refine, continue or change direction?
Keep an additional feature out of the first scope unless it helps answer the question or makes the core task usable.