Guide / Product & Entrepreneurship
Validation Is Not Asking People If They Like Your Idea
Compliments cannot carry a product decision. Connect assumptions to recent behavior, existing alternatives and experiments that can genuinely change the plan.
A person can like your idea and have no reason to use it.
They may like you. They may understand the pitch. They may agree that the proposed improvement sounds sensible. None of those reactions tells you what they will stop doing, what they will trust you with or what they will pay to change.
I do not think positive reactions are worthless. They can tell us whether an explanation makes sense or whether a topic resonates. The problem is assigning them more weight than they can carry. A pleasant conversation should not quietly become evidence that a business model works.
In product work, I want validation to mean that an important assumption has encountered evidence strong enough to affect a decision. Sometimes that evidence supports the idea. Sometimes it narrows the audience, changes the intervention or gives us a reason to stop.
Identify the assumption hiding inside the pitch
Consider a hypothetical tool that helps independent workers prepare a weekly view of their business. The pitch might combine visibility, automation and peace of mind. Underneath it sit several different assumptions.
Perhaps the current process takes too long. Perhaps people cannot find the information they need. Perhaps the information is available but difficult to interpret. Perhaps the problem happens rarely, or matters only at a particular stage of independent work.
Those possibilities call for different evidence. Asking whether someone likes the tool compresses all of them into a reaction to the proposed answer.
Choose one consequential assumption and write it as a claim that could be wrong. For example: a specific segment performs this task repeatedly and experiences a consequence serious enough to justify changing its current workflow. The segment and task need real definitions before the claim can guide recruitment or an experiment.
This is the continuation of the distinction in problem-solution fit before features. A product concept organizes possibilities. Validation should interrogate the important ones.
Ask for an occurrence, not a forecast
An interview becomes more useful when it moves toward a recent, concrete situation. I would ask someone to describe the last time the task happened, what started it, what information they used and where the process became difficult.
If appropriate and freely offered, an artifact can help: an anonymized spreadsheet, a sequence of steps or a blank example of a document. The purpose is to understand the work, not to collect private data that the research does not need.
The GOV.UK guidance on in-depth interviews recommends open, neutral questions and attention to real stories and examples. That is a useful corrective to a conversation dominated by the founder’s explanation. I would use a discussion guide while leaving room for a participant to reveal a problem I did not anticipate.
A question such as “would automated reminders help?” supplies both the diagnosis and the solution. Asking how the person currently remembers a task may reveal that remembering is easy and obtaining the required information is the actual obstacle.
The account is still an account. Reported behavior, directly observed behavior and interpretation should remain distinguishable. An interview can uncover a mechanism without measuring how common it is across a market.
Existing alternatives deserve serious attention
The alternative to a new product is often a working arrangement, even when that arrangement looks untidy from outside. It might involve a spreadsheet, messages, a professional adviser, a marketplace tool or simply tolerating the inconvenience.
Ask what that arrangement does well. Perhaps it is flexible, familiar, cheap or already trusted. A new product has to fit around those advantages or provide a reason to give them up. Describing the current approach as broken can make us miss why it persists.
Switching also involves work that may never appear in a feature comparison: learning a process, importing information, checking accuracy, coordinating with someone else or accepting a new dependency. A proposed improvement needs to be considered alongside that effort.
This does not prove that people will never switch. It changes the experiment. Instead of measuring whether a prototype is attractive, I might investigate whether someone can complete a meaningful task using it and whether the transition cost overwhelms the benefit.
A competitor’s existence is relevant evidence too, but it does not establish demand for my particular product. It gives me something to examine: whom it serves, which situations it addresses and what alternatives customers appear to consider. Any numerical market claim would require its own current source and a clear definition.
Match the signal to the decision
Different experiments produce different kinds of evidence. Treating them as a universal ladder, in which one activity always proves more than another, obscures their purpose. The right choice depends on the assumption.
| Activity | What it can help investigate | What it does not establish alone |
|---|---|---|
| Interview about a recent task | Context, workarounds and consequences | Market prevalence |
| Observed prototype task | Comprehension and interaction problems | Long-term adoption |
| Preregistration | Interest in a stated proposition | Actual use or payment |
| Bounded pilot | Behavior in a defined real workflow | Scalable acquisition |
| Paid trial | A specific willingness to commit money | Durable retention |
These are reasoning boundaries, not promises about the quality of any particular study. Poor recruitment or an unclear proposition can weaken every row.
For a preregistration experiment, be explicit about what exists and what does not. Interest obtained by implying a finished service is difficult to interpret and unfair to participants. A pilot should similarly describe its scope, responsibilities and limits.
The strongest signal is the one that bears directly on the next decision.
If uncertainty concerns whether a task matters, polishing a prototype’s button labels will not resolve it, however carefully the usability session is run.
Decide how contrary evidence will be handled
Before an experiment, record what would cause a change in direction. This need not be a rigid statistical threshold for every early conversation. It should be specific enough that the team cannot reinterpret every outcome as encouragement.
Suppose an exploratory round repeatedly reveals that the proposed problem is infrequent and comfortably handled by an existing process. A reasonable next step might be to investigate another segment or a different problem. Calling the result “promising because participants understood the concept” would avoid the central finding.
The Lean Startup approach connects experiments with learning that can influence product direction. I find it useful to attach the experiment to a decision before collecting the result. Otherwise, measurement easily becomes a decoration added to a roadmap that was already fixed.
Keep an evidence record that includes disagreements and surprises. A summary consisting only of supportive quotes is too easy to manufacture unintentionally. The same applies to AI-assisted synthesis: the output should retain contradictory observations and distinguish source material from generated interpretation.
Segment differences are information
Two people can describe the same task and experience very different consequences. Someone doing it occasionally may tolerate a manual process. Someone coordinating several dependent activities may face a more costly interruption. Those are hypotheses to investigate, not automatic reasons to label one person a better customer.
Recruitment should reflect the circumstances the product is meant to serve. If every participant comes from the founder’s immediate network, I would describe that limitation rather than generalize the result to an entire profession.
Frequency and severity also deserve separate attention. A rare problem can matter greatly; a daily nuisance can be too minor to justify switching. I would ask how the difficulty affects an actual decision or outcome, rather than rely on an abstract rating of frustration.
Payment adds another distinction. The person doing the work may not be the person deciding on a purchase. A useful tool can still face an awkward buying process. Before treating willingness to pay as a single question, identify who has authority, whose budget is involved and what approval would require.
Make the next step smaller than the claim
I find it more useful to say “this experiment reduced uncertainty about this workflow” than “the idea is validated.” The narrower sentence preserves what remains unknown and gives the next activity a purpose.
A good result does not obligate us to build the full vision immediately. It may justify another observation, a sharper pilot or a limited implementation. A disappointing result does not necessarily invalidate every related problem. It tells us which claim failed to earn support under the conditions we examined.
The practical test I would apply to a validation activity is simple: if the evidence went against the idea, would we actually do something differently? If the answer is no, the next meeting may still be useful for communication or relationship-building. It just should not be asked to carry the weight of a product decision.