Idea validation guide
How to validate a software idea before building it
Validation is not asking friends whether an idea sounds good. It is collecting enough evidence to decide whether a specific customer has a problem worth solving—and whether your proposed product is a credible way to solve it.
The short answer
Start by naming one customer and one repeated problem. Study how that customer handles the problem today, speak with people who experience it, and ask for a meaningful commitment before building the full product. The goal is not to prove the idea right. It is to find the weakest assumption early.
A practical process
Move from an assumption to a decision.
- 01
Write the idea as a customer problem
Replace a broad product description with one sentence: who struggles, what they are trying to do, and what makes the current approach frustrating or costly.
Do this: Write: “For [specific customer], [task] is difficult because [current limitation].” - 02
Map the current alternatives
Competitors are not only similar apps. Spreadsheets, agencies, internal tools, manual work, and doing nothing may be the real alternatives you must beat.
Do this: List three named products and two non-product workarounds customers use today. - 03
Interview for past behaviour
People are generous with opinions about the future. Their recent actions are more useful: when the problem happened, what they tried, how often it occurs, and what the consequence was.
Do this: Run five conversations without pitching, then compare the repeated pains and workarounds. - 04
Test a commitment
A signup is a light signal. A booked call, shared data, pilot agreement, pre-order, or introduction to a decision-maker requires more effort and therefore says more.
Do this: Offer one concrete next step that costs the prospect time, access, reputation, or money. - 05
Build the smallest useful proof
The first version should prove the riskiest part of the value proposition. It may be a manual service, clickable prototype, or one narrow working workflow—not a smaller copy of the final vision.
Do this: Choose one input, one valuable outcome, and one customer segment for the first test.
Evidence checklist
What stronger evidence looks like.
- The same problem appears in several recent customer stories.
- Customers already spend time, money, or effort on a workaround.
- You can name the person who feels the pain and the person who pays.
- A meaningful group agrees to a next step beyond saying the idea is interesting.
- The first acquisition channel can reach the customer without a large audience or budget.
- The smallest version can deliver a useful outcome without building the entire platform.
Common mistakes
Avoid evidence that feels useful but changes no decision.
Counting compliments as demand
Positive feedback is easy to give. Give more weight to behaviour, repeated pain, and commitments.
Interviewing everyone
A mixed audience produces mixed evidence. Begin with one customer group that shares the same workflow.
Building before testing distribution
A useful product can still fail if the intended customer is expensive or difficult to reach.
Decision rule
Know what would make you continue—or reconsider.
Proceed when the problem repeats, current alternatives are meaningfully inadequate, and several target customers accept a concrete next step. Narrow or pause when the evidence depends mainly on opinions, broad market claims, or your own enthusiasm.