# Idea Validation

Validation answers whether **[TARGET USERS]** experience **[MAIN PROBLEM]** strongly enough to change behavior. It is not a request for compliments about an idea. For mobile app starter kit, evidence should cover desirability, usability, feasibility, safety, and sustainability.

[Kit README](README.md) · [Project Overview](Project%20Overview.md) · [PRD](Full%20PRD%20Template.md) · [Master Build Prompt](Master%20Build%20Prompt.md) · [Completion Checklist](Project%20Completion%20Checklist.md)

## Validation Claims

| Claim | Current Evidence | Confidence | Cheapest Next Test | Pass Signal |
| --- | --- | --- | --- | --- |
| The problem is frequent or costly | [QUOTE, OBSERVATION, OR DATA] | [Low/Med/High] | [INTERVIEW OR LOG REVIEW] | [MEASURABLE SIGNAL] |
| The proposed outcome matters | [EVIDENCE] | [LEVEL] | [PROTOTYPE OR OFFER TEST] | [TARGET] |
| Users understand the core flow | [EVIDENCE] | [LEVEL] | [5-TASK USABILITY TEST] | [TARGET SUCCESS RATE] |
| The project can be delivered safely | [EVIDENCE] | [LEVEL] | [TECHNICAL SPIKE] | [PASS CONDITION] |
| The operating cost is supportable | [EVIDENCE] | [LEVEL] | [COST MODEL] | [MAX COST PER USE] |

## Five-Step Validation Sprint

1. **Recruit the right people.** Speak to 5–8 people matching one of these real contexts: first-time user granting only necessary permissions; daily mobile user working with one hand; returning user reconnecting after offline activity. Do not substitute friends who would never use the result.
2. **Study current behavior.** Ask for the last time the problem occurred, what they tried, how long it took, what failed, and what consequence followed.
3. **Test the promise.** Show a one-page concept or clickable prototype. Ask the person to explain what they think it does before you explain it.
4. **Test the riskiest mechanism.** Prototype the part most likely to fail. For this project, inspect risks such as asking for permissions too early, data conflicts after offline use, platform-specific layout bugs.
5. **Make a decision.** Choose **Proceed**, **Revise**, **Narrow**, or **Stop**. Record why, what evidence would change the decision, and the next review date.

## Interview Script

~~~text
I am researching how people currently [TASK]. I am not selling anything.
1. Tell me about the last time you tried to [TASK].
2. What triggered it? What did you do first?
3. Where did it become slow, confusing, risky, or expensive?
4. What workaround do you use today?
5. What would a noticeably better outcome look like?
6. May I show a rough concept and ask you to think aloud?
~~~

Avoid “Would you use this?” Prefer observed behavior, a realistic task, a commitment such as joining a pilot, or a measurable prototype result.

## Domain Test Ideas

1. Test whether a participant can **finish onboarding without confusion** using a low-fidelity version. Record completion, time, wrong turns, questions, and confidence.
2. Test whether a participant can **complete the core action in under one minute** using a low-fidelity version. Record completion, time, wrong turns, questions, and confidence.
3. Test whether a participant can **keep changes safe during weak or absent connectivity** using a low-fidelity version. Record completion, time, wrong turns, questions, and confidence.

## Decision Rule

Proceed only if the core problem has repeated behavioral evidence, at least 4 of 5 representative users can understand the intended value without coaching, the highest technical risk passes a bounded spike, and no unresolved safety or privacy issue blocks the first release. Otherwise narrow the user, problem, or feature set.

## Common Mistakes

- Counting praise as evidence.
- Asking leading questions or describing the solution before learning current behavior.
- Testing many features while leaving the riskiest assumption untouched.
- Treating sample or AI-generated data as real research.
- Continuing because work has already been invested.