The fastest way to waste six months is to validate a solution instead of validating the problem.
Founders often ask people whether an idea sounds useful, collect encouraging replies, and call that evidence. It is not. People are generous with opinions because opinions cost nothing.
Useful validation asks for progressively stronger behaviour: describe a recent problem, show the current workaround, give access to the workflow, try a manual version, introduce a colleague, share data, reserve time, or make a financial commitment.
The purpose is not to prove that the idea is good. It is to discover what must be true for the idea to work—and which assumption is most likely to break it.
The Five-Part Idea Validation Framework
Validate these five layers in order.
1. User: who experiences the problem?
“Small businesses” is not a useful user definition. Neither is “people who want to be productive.”
Define the user by context and behaviour:
Operations managers at regional logistics companies who reconcile delivery exceptions across calls, spreadsheets, and driver messages.
A specific user definition tells you where to find people, what language they use, which constraints matter, and who makes the decision.
Test it by asking:
- Can I name the role or situation precisely?
- Do these users share a recognisable workflow?
- Is the person with the pain also the buyer or influencer?
- Are there meaningful subgroups with different needs?
If every interview produces a different problem, the segment is still too broad.
2. Problem: does it happen repeatedly and matter?
Ask about the last time the problem occurred.
Useful prompts:
- “Walk me through the most recent example.”
- “What triggered it?”
- “What did you do next?”
- “Who else became involved?”
- “What was delayed, lost, or put at risk?”
- “How often does this happen?”
Avoid “Would you use…?” and “Do you think this is a good idea?” Those questions invite speculation.
A strong problem has observable consequences. It costs time, creates errors, blocks revenue, increases risk, frustrates a valuable user, or prevents a desired outcome.
3. Workaround: what do users do today?
No product competes with “nothing.” It competes with spreadsheets, messages, junior staff, memory, an incumbent product, a consultant, or simply accepting the pain.
The workaround reveals:
- How important the problem really is
- What users already understand
- Which steps must remain familiar
- Where switching friction will appear
- Whether the current solution is good enough
Ask to see the artefact: the spreadsheet, report, chat thread, checklist, folder, or screen. The details are more reliable than a summary.
If people complain but invest no effort in a workaround, the problem may be irritating rather than valuable.
4. Access: can you repeatedly reach the user?
A valid problem is not automatically a viable business.
You need a practical route to users through:
- Existing relationships
- Communities
- Partnerships
- Search demand
- Industry associations
- Outbound lists
- Product integrations
- Physical or operational distribution
Test access early. Try to recruit interviews without relying only on friends. Track where qualified conversations come from and how much effort each channel requires.
If the user is expensive or difficult to reach, that is part of the product strategy—not a marketing problem to solve later.
5. Commitment: will users give up something meaningful?
Commitment is stronger than enthusiasm.
The right commitment depends on the stage:
- Attention: complete a detailed interview
- Time: join a workflow test or pilot
- Access: share data or allow observation
- Reputation: introduce a colleague or stakeholder
- Behaviour: use a manual or concierge version repeatedly
- Money: pay, pre-order, or sign a credible commercial commitment
Do not force payment as the only valid signal. Some products need security review, procurement, integration, or team approval before purchase. Ask for the strongest realistic commitment available now.
Build an Evidence Ladder
Treat validation as a sequence, not a single test.
| Evidence | What it proves | What it does not prove |
|---|---|---|
| Interview | The problem exists in the user’s story | They will change behaviour |
| Workaround artefact | The problem creates real work | Your solution is better |
| Landing-page action | The message creates interest | The product delivers value |
| Manual test | The outcome is useful | Software can deliver it reliably |
| Repeated use | The workflow has ongoing value | The economics work |
| Commitment | The user will give up something meaningful | The market is large |
Move up the ladder as cheaply as possible. Do not jump from interviews to a full build when a manual test can expose the next risk.
Run Better Customer Interviews
Ask for behaviour, not approval
Weak:
“Would an AI assistant for this be useful?”
Better:
“Show me how this decision was made last week. Where did the information come from, and what happened after?”
Do not pitch too early
Once you describe the solution, the conversation changes. The user starts reacting to your framing instead of explaining their reality.
Spend most of the interview on the current workflow. Share the concept only after you understand the problem.
Capture exact language
The phrases users repeat can improve positioning, onboarding, and product labels. Record notes immediately and separate what the user said from your interpretation.
Look for contradictions
Someone may call a problem “critical” and then reveal it happens twice a year. Another may sound calm while spending hours every week on a workaround.
Behaviour outranks adjectives.
Choose the Smallest Test for the Riskiest Assumption
Different risks need different tests.
If the risk is problem importance
Use interviews, workflow observation, and workaround analysis.
If the risk is message comprehension
Use a landing page or short prototype. The MVP landing-page guide shows how to test a promise without fake proof.
If the risk is user behaviour
Use a clickable prototype, manual workflow, fake door with transparent follow-up, or concierge test.
If the risk is technical feasibility
Build a narrow proof of concept around the uncertain component—not the whole user interface.
If the risk is willingness to commit
Ask for a pilot, data access, a scheduled implementation window, a letter of intent, or payment when appropriate.
The test should be capable of proving you wrong. If every result can be interpreted as success, the experiment is theatre.
Use an Idea Validation Scorecard
Score the evidence from 0 to 2.
| Dimension | 0 | 1 | 2 |
|---|---|---|---|
| User | Broad or hypothetical | Segment identified | Repeated access to a specific segment |
| Problem | Opinion only | Recent examples | Repeated, consequential behaviour |
| Workaround | None visible | Informal workaround | Time, money, or process already invested |
| Access | Friends only | One workable channel | Repeatable qualified conversations |
| Commitment | Compliments | Small action | Meaningful time, access, reputation, or money |
The total is not a scientific truth. Use it to expose the weakest layer.
- 0–3: The problem or user is still mostly assumed.
- 4–6: Continue testing the weak dimensions before building broadly.
- 7–8: A narrow prototype or manual pilot is reasonable.
- 9–10: You have stronger evidence, but still need to prove delivery and retention.
Write the evidence beside every score. Numbers without notes create false confidence.
Common Validation False Positives
Friends like the idea
They may be supporting you rather than describing market behaviour.
People join a free waitlist
The message created curiosity. Follow up and ask for a stronger action.
A large market report exists
Market size does not prove that your segment has this problem or that you can reach it.
Competitors raised money
That proves investors funded those companies. It does not prove your position, channel, or execution.
A prototype receives praise
Ask users to complete the task, return later, or integrate it into real work.
One customer will pay for custom work
That can be valuable, but it may validate a service rather than a repeatable product. Identify which parts are standard and which are unique.
Decide: Build, Narrow, Pivot, or Stop
After each validation cycle, make one explicit decision.
Build
The user, problem, access, and commitment are strong enough to test the delivery mechanism.
Narrow
The problem is real for a smaller segment or use case than expected.
Pivot
The conversations reveal a different valuable problem, buyer, or workflow.
Stop
The pain is weak, workarounds are sufficient, access is impractical, or nobody will commit.
Stopping is not failure. It is the cheapest useful result validation can produce.
Validation Continues After Launch
Pre-build validation reduces obvious risk. It does not guarantee product-market fit.
After launch, replace stated intent with product behaviour:
- Do users reach first value?
- Do they return when the problem repeats?
- Do they invite others or expand usage?
- Do they rely on the output?
- Will they continue committing time, data, reputation, or money?
The five-sign feature test helps determine whether the idea can become a recurring product rather than a one-off convenience. When the evidence is strong enough to build, use the MVP cost-planning guide to turn assumptions into scope and risk buffers.