The key points
- Name the single assumption the business depends on.
- Talk to people you can actually reach, not an imagined market.
- Watch what they do with a prototype; do not rely on what they say.
- Decide in advance what result would make you stop.
What are you actually trying to find out?
Not whether the idea is good, but whether one specific belief is true. Most ideas contain a dozen assumptions, and one of them carries the business: that a certain group has this problem, that they already try to solve it, or that they will change what they do to use your product. Name that one and test it first.
Validation is cheap compared with building even a minimal product. A week of prototyping and a handful of conversations can show what months of development would otherwise cost to learn.
Who should you test with?
People who have the problem today and whom you can reach. Friends and family are polite, which is the opposite of useful. Ten real prospects who try your prototype and either complete the task or stumble are worth more than a hundred survey answers. If you cannot name ten reachable users, that is itself a finding about your distribution.
What counts as validation?
Behavior. Someone completing the task, asking when they can have it, offering to pay or introducing a colleague counts. Saying the idea is interesting does not. Decide before you test what you will treat as a yes, so you do not stretch a mixed result into a green light afterwards.
Our MVP development process starts with about three days of scoping and a week of prototyping before the build begins, and includes a user testing plan, for exactly this reason.
How to validate an idea before building
State the riskiest assumption
Write the one sentence that, if false, ends the idea, such as who has the problem and why they will pay to fix it.
Find the first ten users
List ten real people or businesses who have the problem and whom you can reach this month.
Test with a prototype
Build a clickable prototype of the core flow, about a week of work, and watch them try to complete the task.
Set a stop rule
Decide before the test what result means go, change or stop, so the outcome cannot be argued around afterwards.
Build only the core
If the test holds, build the smallest product that serves that flow, and leave admin tooling and extras for later.
Before you commission an MVP
- What is the one assumption that would end this idea if wrong?
- Who are the first ten real users, and can you reach them now?
- What will you treat as a yes, and what as a no?
- What are you prepared to leave out of version one?
- How will you know within weeks whether it held?
Sources
Rules and guidance this answer relies on. Policies change, so check the current version before acting on it.