01
An MVP is a learning system
The smallest product is not automatically a useful MVP. It needs to deliver a complete enough outcome for a specific user and produce evidence about the next investment decision.
Begin with the user, the painful current state, the promised change, and the behavior that would show the product is working. Features follow from that chain.
02
Map assumptions before scope
List what must be true about desirability, workflow, data, integrations, technology, operations, and commercial adoption. Rank assumptions by impact and uncertainty. The riskiest one should influence the first prototype or technical spike.
03
Design one complete journey
A strong first release usually serves one audience and one core journey well. Include the states around it—onboarding, empty data, permission failure, exceptions, support, and recovery—because those states reveal whether the product can actually operate.
04
Choose architecture for the next credible stage
Avoid both throwaway shortcuts and infrastructure for imaginary scale. Select standard technology, clear data boundaries, secure identity, observable deployment, and a structure the current team can understand. Preserve options where change is likely; keep the rest simple.
05
Use release evidence to shape the roadmap
After launch, combine user observation, product usage, support questions, operational cost, performance, and commercial learning. A roadmap should be a sequence of decisions informed by evidence, not a permanent feature promise.