App validation does not prove that an idea will succeed. It reduces uncertainty in a useful order: whether the problem exists, who experiences it, what they do now, why current alternatives fail, whether you can reach them, and whether a small solution can change their behavior.
Decision snapshot
| Decision | Practical approach | Watch for |
|---|---|---|
| Study behavior, not compliments | Ask about recent real events, costs, workarounds, and decisions. | People are generous with hypothetical praise and cautious with actual commitment. |
| Test the riskiest assumption | Choose the uncertainty most capable of invalidating the product. | Building easy features first creates output without reducing risk. |
| Seek commitment | Use a pilot, scheduled follow-up, data contribution, preorder where appropriate, or another meaningful next step. | Email signups alone can overstate intent. |
Write a falsifiable problem statement
Name the user, triggering situation, current workaround, measurable cost, and evidence that would show the problem is too weak to pursue.
Recruit from the actual audience
Find participants through the channels you would later use to acquire customers. Avoid relying only on friends, coworkers, or people attracted by an incentive.
Run evidence-centered interviews
Ask for the last occurrence, sequence of actions, tools used, frequency, money or time spent, failed attempts, decision authority, and consequences. Do not pitch during discovery.
Test demand with the smallest honest artifact
Use a concierge workflow, clickable prototype, landing page, waitlist with clear terms, or paid pilot. Represent the product truthfully and measure a defined action.
Score the decision and next risk
Compare evidence with prewritten thresholds for problem frequency, access, willingness, retention signal, feasibility, and economics. Continue, narrow, pause, or stop explicitly.
Action checklist
- Target user and triggering situation are specific
- Interview notes describe recent behavior rather than opinions
- Current alternatives and switching barriers are understood
- Demand test makes no misleading availability claims
- Success and stop thresholds were written before results
- Privacy, legal, technical, and distribution constraints are recorded
Working worksheet
Record these fields in the same working document so the decision can be reviewed and handed off:
- User, situation, problem, and current workaround
- Riskiest assumption and disconfirming evidence
- Recruitment channel and interview sample
- Test artifact, requested commitment, metric, and threshold
- Decision, supporting evidence, unresolved risk, and next experiment
Common failure patterns
- Counting broad survey interest as product demand
- Interviewing only users who cannot authorize or influence adoption
- Changing the success threshold after weak results arrive
Connect this work
Evidence should determine what earns a place in the first release. Read turn validated needs into a narrow MVP.
A requirements document should preserve what validation actually learned. Read capture the problem and boundaries.
Tool selection is a downstream decision. Read evaluate implementation only after the problem is credible.