Product validation
How to validate a business idea before building
Find the riskiest belief behind the idea, then decide what evidence would make you continue, change direction, or stop before you build.
To validate a business idea before building, separate it into the beliefs that can fail independently. The customer may not have the problem. The problem may exist without changing behavior. The proposed product may work but still fail to earn trust. Testing the idea as one large claim hides those differences.
Business idea validation starts with one plain sentence. Name the person, the problem, and the change you expect the product to create. Clear language makes the hidden assumptions easier to see and test.
Separate the idea into six assumptions
- Person: the intended user is specific and reachable.
- Problem: the user experiences the problem often enough to care.
- Behavior: the user will change an existing habit or workflow.
- Value: the promised improvement is large enough to matter.
- Product: the proposed workflow can deliver that improvement reliably.
- Trust: the user will believe the product is safe and credible enough to try.
Write one concrete belief for each category. Avoid statements such as “people will like it.” A useful assumption says who does what, under which condition, and why the result matters.
Score uncertainty and consequence separately
Give every assumption an uncertainty score from 1 to 5. Then score the consequence of being wrong from 1 to 5. Multiply the two numbers. A high score means the belief is both weakly known and capable of damaging the idea.
The highest score is the first candidate to test. It is not automatically the only important assumption. The score creates an order for learning so the team does not spend weeks polishing the easiest questions.
Rewrite the candidate as a testable belief
The completed Assumption Map demo tests whether solo builders can finish a talking-head and screen-recording edit at least 30 percent faster in a focused workflow without a critical export or quality failure. That statement names the user, task, threshold, and failure condition.
A testable belief should answer four questions:
- Who must show the behavior?
- What must they complete or choose?
- What result counts as enough evidence?
- What failure would make the result unusable?
Run the smallest credible test
Small does not mean casual. The test must still expose the risky part of the idea. An interview can test whether a problem exists, but it cannot prove that someone can complete a new workflow. A landing page can measure interest, but it cannot prove that the product delivers the promised result.
Match the test to the belief. Observe a real task when the claim concerns behavior. Use a working prototype when the claim concerns completion or reliability. Ask for a meaningful commitment when the claim concerns willingness to adopt.
Choose the decision thresholds before results arrive
Write three outcomes before running the test: Continue, Change, and Stop. Each outcome needs a measurable condition. Pre-committing prevents one encouraging comment from outweighing a failed task or an unreliable result.
If every possible result leads to building the same product, the exercise is collecting reassurance rather than reducing risk.
After the test, record what happened against the thresholds. Continue only when the evidence clears the condition you set. Change the belief or workflow when the result is mixed. Stop the approach when the risky assumption fails and the evidence is strong enough to trust.