Working Start something skill
Validate a product idea
Turn a product idea into explicit assumptions, small evidence-gathering tests, and a written build, change, or stop decision before major investment.
Test the riskiest belief behind an idea before building the full solution. Seek evidence about a specific person's current problem and behavior, not compliments for a pitch.
Inputs
- Name the intended user, situation, problem, proposed outcome, and idea owner.
- Record what is known from direct observation and what is still an assumption.
- Set a small time, money, outreach, and privacy budget for validation.
Procedure
- Write the idea as: for this specific person in this situation, the product helps them reach this outcome better than their current alternative.
- List assumptions about problem frequency, severity, current workaround, access to users, willingness to switch, ability to deliver, channel, and sustainable cost.
- Rank assumptions by uncertainty multiplied by consequence. Select the one whose failure most strongly invalidates the idea.
- Choose the smallest ethical test that produces behavioral evidence: observe the current workflow, conduct neutral interviews, offer a manual service, test a clear landing-page action, or request a reversible commitment.
- Define the signal, threshold, sample, time window, and decision rule before running the test.
- Recruit people who match the user definition without pretending a prototype exists or concealing how their information will be used.
- Record exact observations separately from interpretation. Capture refusals, workarounds, and drop-off, not only positive statements.
- Compare results with the decision rule. Check whether the test measured the risky assumption or merely measured curiosity about the concept.
- Decide to continue, change user/problem/channel, run one new test, or stop. Name the evidence and the remaining riskiest assumption.
- If continuing, define the smallest useful version that delivers the outcome manually or with minimal software and can be tested with real users.
Boundaries
Do not fabricate demand, testimonials, waitlist numbers, or commitments. Do not collect contact or behavioral data without clear consent and a retention purpose. Avoid deceptive scarcity, fake checkout, or experiments that can cause financial, health, educational, or employment harm.
--- name: validate-a-product-idea category: start description: Turn a product idea into explicit assumptions, small evidence-gathering tests, and a written build, change, or stop decision before major investment. Use when someone has an app or business idea, asks whether an idea is good, or is about to build without evidence of a real problem. --- # validate-a-product-idea Test the riskiest belief behind an idea before building the full solution. Seek evidence about a specific person's current problem and behavior, not compliments for a pitch. ## Inputs - Name the intended user, situation, problem, proposed outcome, and idea owner. - Record what is known from direct observation and what is still an assumption. - Set a small time, money, outreach, and privacy budget for validation. ## Procedure 1. Write the idea as: for this specific person in this situation, the product helps them reach this outcome better than their current alternative. 2. List assumptions about problem frequency, severity, current workaround, access to users, willingness to switch, ability to deliver, channel, and sustainable cost. 3. Rank assumptions by uncertainty multiplied by consequence. Select the one whose failure most strongly invalidates the idea. 4. Choose the smallest ethical test that produces behavioral evidence: observe the current workflow, conduct neutral interviews, offer a manual service, test a clear landing-page action, or request a reversible commitment. 5. Define the signal, threshold, sample, time window, and decision rule before running the test. 6. Recruit people who match the user definition without pretending a prototype exists or concealing how their information will be used. 7. Record exact observations separately from interpretation. Capture refusals, workarounds, and drop-off, not only positive statements. 8. Compare results with the decision rule. Check whether the test measured the risky assumption or merely measured curiosity about the concept. 9. Decide to continue, change user/problem/channel, run one new test, or stop. Name the evidence and the remaining riskiest assumption. 10. If continuing, define the smallest useful version that delivers the outcome manually or with minimal software and can be tested with real users. ## Boundaries Do not fabricate demand, testimonials, waitlist numbers, or commitments. Do not collect contact or behavioral data without clear consent and a retention purpose. Avoid deceptive scarcity, fake checkout, or experiments that can cause financial, health, educational, or employment harm. ## Done - An assumption map ranks uncertainty and consequence instead of treating the idea as one claim - A completed test records participants, method, observations, threshold, and limitations - The decision memo states continue, change, test again, or stop with evidence and an owner - Any proposed first version targets the validated problem and has its own measurable next test Then use conduct-user-interviews for deeper discovery or start-an-app for the smallest validated build.