Product discovery
Skill Amey-Thakur/AI-SKILLS/skills/product-management/product-discovery
Validate problems before building solutions using evidence standards and opportunity mapping. Use when deciding what to build next or challenging a solution that arrived before its problem.From its SKILL.md
npx -y skills add Amey-Thakur/AI-SKILLS --skill product-discoveryAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 25 days oldThe repository was created 25 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
2.9 KB, 615 tokens by cl100k_base, as published. Nobody here has run it
Product discovery
Discovery de-risks building. The question is never "is this idea good" but "what evidence shows this problem is real, frequent, and painful enough that someone changes behavior to solve it".
Method
- Start from the problem space, held open. Write the target outcome (business and user), then map opportunities beneath it (an opportunity solution tree: outcome, opportunities, candidate solutions, experiments). Solutions arriving first get parked as candidates under whichever opportunity they claim to serve; if none fits, that is the finding.
- Grade evidence by what it cost the user. Weakest to strongest: opinions in a meeting, survey answers, interview stories about the past (see customer-interviews), observed current behavior and workarounds, and paid/effortful commitment (signed up, prepaid, switched tools). Fund decisions on the top half; a deck of survey percentages is not discovery.
- Hunt the workaround. Users solving the problem today with spreadsheets, interns, or duct tape prove frequency and pain at once: the workaround is the demand signal and the competing product. No workaround usually means no felt problem, whatever the interviews politely said.
- Size before you commit. How many users hit this, how often, at what cost each time (see estimation-techniques for honest Fermi work); a real problem afflicting few people rarely is a segment decision, not a roadmap item. Check the result against the outcome it claims to move (see product-metrics).
- Run the cheapest killing experiment. For the riskiest assumption, choose the test that could disprove it fastest: landing-page demand tests, concierge/manual service, fake door (ethically: tell users after; see mvp-scoping), prototype walkthroughs. Write the pass/fail bar before running (see hypothesis-driven-work); experiments without kill criteria are theater.
- Close the loop visibly. Each discovery cycle ends in a decision (pursue, park, kill) recorded with its evidence (see decision-journals, architecture-decision-records' sibling for product); killed ideas with reasons prevent their monthly resurrection.
Boundaries
- Discovery is continuous, not a phase gate; a quarter of pure research with no shipped learning is its own failure mode (see mvp-scoping's ship-to-learn).
- Some bets are vision-driven and evidence-light by nature; label them as such deliberately rather than laundering them through fake validation.
- B2B discovery must separate buyer, user, and blocker personas; one enthusiastic champion is not a validated market (see customer-interviews' recruiting).
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.