An MVP should answer one uncomfortable question: will people change how they work, spend, or buy if this exists? If the answer is fuzzy, the build becomes expensive guesswork. Before you design the product, make the decision you are trying to unlock explicit.
1. Can you name the painful job?
Describe what the person is trying to get done today, without mentioning your proposed solution. Strong problems usually leave evidence behind: spreadsheets, screenshots, support messages, voice notes, or a workaround someone invented because the current system is not good enough.
- The same task happens repeatedly.
- Someone has created a workaround without being asked.
- The current process costs time, money, or missed revenue.
- The problem appears at a moment that matters to the business.
2. Is the pain urgent enough to change behaviour?
Interest is not demand. Ask what the person does now, how often the problem occurs, and what happens when they leave it unsolved. If they cannot describe the cost of doing nothing, the idea may be interesting without being important.
3. What result would prove the idea is working?
- Continue if users repeat the problem without prompting.
- Pause if the problem exists but the audience is too narrow to support the plan.
- Stop if the solution is admired but the pain is not urgent.
4. Can a small experiment answer the question?
A clickable prototype, landing page, concierge workflow, or short pilot can be enough. Choose the experiment that tests behaviour rather than admiration, and decide in advance what result would make you continue, change direction, or stop.
- 01
Write the assumption
State who has the problem, when it occurs, and what they would do differently.
- 02
Choose the smallest test
Remove everything that does not help you observe that behaviour.
- 03
Set a decision date
A test without a decision date becomes research that never ends.
"Good validation is not about proving yourself right. It is about making the next decision obvious."