Name the assumption
Begin with the uncertain belief that would make further investment unwise if it proved false. The product exists to test that belief. State the target user, painful situation, expected behavior change, and commercial or operational condition that must hold. A precise assumption creates a boundary for the first release and makes it possible to decide whether the evidence supports further investment.
- Who has the problem
- How urgent it is
- Whether the behavior changes
- Whether the model can operate
Protect one complete journey
Remove breadth before removing coherence. One user should be able to achieve one valuable outcome with sufficient trust and clarity. A narrow journey still needs understandable navigation, reliable data handling, useful feedback, and an operational response when something fails. Keep the complete path that tests the assumption, then defer secondary audiences, configuration options, and edge cases that do not affect the learning objective.
- Clear entry point
- Complete core task
- Honest feedback
- Operational support
Choose evidence in advance
Downloads and registrations are rarely enough. Decide what observed behavior or conversation would change the next decision. Successful task completion, repeat usage, conversion to payment, reduced handling time, or a manageable support burden may matter more than traffic. Define the observation period before launch, and pair quantitative data with conversations that explain why people continued, stopped, paid, or asked for help.
- Task completion
- Repeated use
- Willingness to pay
- Support burden