Product Discovery skill for Codex

Discovery is done well when the team is working toward one measurable outcome, every candidate solution traces to a customer opportunity backed by research, the riskiest assumptions behind the chosen idea are tested with the cheapest credible experiment, and pass/fail thresholds were written down before the results arrived.

Opportunity solution tree

Outcome: raise 7-day team activation from 22% to 32%
├── Opportunity: new admins don't know who to invite first
│   ├── Solution: suggested teammates from email domain
│   └── Solution: invite step inside the first project template
├── Opportunity: invited people don't understand why they were invited
│   ├── Solution: personal note from inviter in the invite email
│   └── Solution: invitee landing page showing the shared project
└── Opportunity: teams start empty and see no value
    ├── Solution: import from spreadsheet
    └── Solution: starter templates by team type

Rules:

• Outcome at the root: a product metric the team can influence (from OKRs or $product-metrics), not a business lagging metric like revenue.
• Opportunities are customer needs, pains or desires in the customer’s language, discovered through interviews and data. Never solutions in disguise (“need a Slack integration”).
• Break large opportunities into smaller child opportunities until one can be addressed in a few weeks.
• Compare and contrast: pick one target opportunity, then generate at least three solutions for it before choosing. One idea is not a choice.
• Experiments hang below solutions and test assumptions, not whole solutions.

Assumption mapping

For the chosen solution, list assumptions across categories, then plot by importance (would the idea fail if wrong?) and evidence (do we already know?):

Category	Prompt	Example
Desirability / value	Will they want it and choose it?	Admins will add a personal note when prompted
Usability	Can they use it?	Admins notice the note field without guidance
Feasibility	Can we build it?	Email provider supports per-invite custom text
Viability	Does it work for the business?	No spam-compliance risk from user-written text in our emails
Ethical	Should we?	Notes cannot be used to phish invitees

Test only the high-importance, low-evidence quadrant. Everything else is either known or does not matter yet.

Pick the cheapest credible test

Test	Good for	Effort	Watch out
Data mining (existing analytics, logs, tickets)	Does the behaviour or pain already show up?	Hours	Absence of data is not absence of need
One-question in-product survey	Prevalence of a situation	1-2 days	Ask about past behaviour
Prototype test (5-8 users)	Usability, comprehension	Days	Not evidence of demand
Fake door / painted door	Demand: do people click when it is offered?	Days	Must explain honestly on click; low volume pages give no signal
Concierge / Wizard of Oz	Value of the outcome, delivered manually	1-3 weeks	Labour cost; small n
Technical spike	Feasibility	1-5 days	Time-box strictly
A/B test of a real build	Measured impact at scale	Weeks	Needs traffic; see $ab-testing

Pre-register every test:

Assumption: Admins will add a personal note when prompted
Test: show optional note field to 50% of new-workspace admins for 2 weeks (flag invite_note)
Metric: % of invites sent with a non-empty note
Pass: >= 25% | Fail: < 10% | In between: run 5 interviews to understand why
Sample needed: ~400 invites per arm at current volume (about 10 days)
Decision if pass: build full version with templates; if fail: drop and test landing page idea

Fake doors and in-product tests change what customers see: confirm with the user and any required owners (legal, brand) before they go live, and always tell users honestly what happened when they click a feature that does not exist yet.

Weekly discovery cadence

- [ ] Talk to at least one customer this week (see $customer-interviews)
- [ ] Add new opportunities to the tree; prune ones evidence has killed
- [ ] Re-check the target opportunity is still the best bet
- [ ] Run or analyze at least one assumption test
- [ ] Share a short update: what we learned, what changed, next test

Workflow for a specific idea

- [ ] 1. Name the outcome the idea is meant to move
- [ ] 2. Place the idea on the tree: which opportunity does it serve? Add evidence
- [ ] 3. Generate two or more alternative solutions for that opportunity
- [ ] 4. Map assumptions for the leading options; pick the riskiest 1-3
- [ ] 5. Design and pre-register the cheapest credible test for each
- [ ] 6. Run, then compare results to thresholds without moving them
- [ ] 7. Decide: build, iterate, switch solution, or switch opportunity

When the codebase is available, check feasibility cheaply by reading the relevant modules and data model before scheduling a spike; often the answer is in the code.

Output template

## Discovery update: <outcome>
Target opportunity: <...> (evidence: n interviews, data points)
Solutions considered: A, B, C - chosen: B because <...>
Assumptions tested this cycle:
| Assumption | Test | Threshold | Result | Decision |
Next tests:
Tree changes: <added / pruned opportunities>

Gotchas

• Starting from a solution and back-filling an opportunity makes the tree a justification document. Start from research.
• Fake-door tests on pages with little traffic produce noise; estimate sample size first.
• Moving thresholds after seeing results turns an experiment into a story.
• Prototype enthusiasm (“I’d use that!”) tests usability and appeal, not demand.
• Discovery is continuous; a one-off “discovery phase” before delivery leaves the team blind afterwards.

Verification

Check each solution on the tree links to an opportunity with cited evidence, the target opportunity has at least three candidate solutions, every running test has a written threshold and decision rule dated before launch, and results are reported against those original thresholds.