Approach and advantage
The tree makes competing solutions visible under the same customer opportunity. Teams can compare a content change, a process adjustment and a new feature without assuming that more development is the only response.
Use Product Discovery to connect customer evidence to the product changes worth testing. Starting with a measurable goal, this Skill builds an opportunity solution tree and ranks assumptions, helping ecommerce teams investigate checkout friction, a new subscription offer or another proposed feature before committing to development.
An opportunity solution tree links the outcome you want to customer needs, possible solutions and experiments. The Skill helps organize those links so a requested feature can be traced back to a real problem rather than treated as the starting assumption.
Its Python mapper ranks supplied assumptions for further testing. The deliverable is a discovery plan with evidence gaps and decision criteria; customer interviews and experiments must still be carried out to establish whether the idea is useful.
The tree makes competing solutions visible under the same customer opportunity. Teams can compare a content change, a process adjustment and a new feature without assuming that more development is the only response.
Use the assumption ranking to choose the next learning task. A risky belief about willingness to subscribe may deserve attention before polishing the interface, while a well-supported need can move toward a more concrete test.
One measurable outcome, interview or behavior evidence, candidate solutions, and assumption CSV data.
Use a Skill-capable agent with file access. Python 3 is required for the bundled Python helpers; inspect their sample schemas before supplying data.
It plans discovery and scores supplied assumptions; it does not interview customers or establish demand by itself.
Copy this request into Codex or Claude Code. The assistant downloads the original repository at the specified commit, installs the complete files and checks required dependencies.
Install product-discovery in the app I am using and carry out the file installation, not just explain it.
Original repository: https://github.com/alirezarezvani/claude-skills.git
Commit: 6d2f02ea077eead1bee5411a31bcc6db5a11a70c
Skill folder: product-team/skills/product-discovery
1. Download this exact source into a new directory. Read SKILL.md and its setup references before running any bundled scripts. Do not substitute another author’s package.
2. For Codex, use ~/.agents/skills/product-discovery; for Claude Code, use ~/.claude/skills/product-discovery. Install only for my current app. Install the complete Skill folder, including scripts, references, assets and bundled notices. Keep any root license with the installed folder. Check all destination folders first; if any already exist, report differences before replacing them.
3. Compare the source and installed file lists and hashes. Inspect documented runtimes, dependencies and required connections. Configure only the local dependencies needed for this Skill; use an isolated environment when appropriate. Ask me to complete any account login locally, without putting credentials in chat.
4. Report the source commit, actual installation path, file-check results and any remaining runtime setup. Explain how to invoke product-discovery in this app. Check discovery separately from file copying; start a new session if needed. Do not run production tasks or claim a successful business outcome from installation alone.This is the unchanged source SKILL.md for the reviewed version. Install the complete package to retain referenced scripts, assets, and instructions. Starter prompts below are EcomAgentTools examples.
---
name: product-discovery
description: Use when validating product opportunities, mapping assumptions, planning discovery sprints, or testing problem-solution fit before committing delivery resources.
---
# Product Discovery
Run structured discovery to identify high-value opportunities and de-risk product bets.
## When To Use
Use this skill for:
- Opportunity Solution Tree facilitation
- Assumption mapping and test planning
- Problem validation interviews and evidence synthesis
- Solution validation with prototypes/experiments
- Discovery sprint planning and outputs
## Core Discovery Workflow
1. Define desired outcome
- Set one measurable outcome to improve.
- Establish baseline and target horizon.
2. Build Opportunity Solution Tree (OST)
- Outcome -> opportunities -> solution ideas -> experiments
- Keep opportunities grounded in user evidence, not internal opinions.
3. Map assumptions
- Identify desirability, viability, feasibility, and usability assumptions.
- Score assumptions by risk and certainty.
Use:
```bash
python3 scripts/assumption_mapper.py assumptions.csv
```
4. Validate the problem
- Conduct interviews and behavior analysis.
- Confirm frequency, severity, and willingness to solve.
- Reject weak opportunities early.
5. Validate the solution
- Prototype before building.
- Run concept, usability, and value tests.
- Measure behavior, not only stated preference.
6. Plan discovery sprint
- 1-2 week cycle with explicit hypotheses
- Daily evidence reviews
- End with decision: proceed, pivot, or stop
## Opportunity Solution Tree (Teresa Torres)
Structure:
- Outcome: metric you want to move
- Opportunities: unmet customer needs/pains
- Solutions: candidate interventions
- Experiments: fastest learning actions
Quality checks:
- At least 3 distinct opportunities before converging.
- At least 2 experiments per top opportunity.
- Tie every branch to evidence source.
## Assumption Mapping
Assumption categories:
- Desirability: users want this
- Viability: business value exists
- Feasibility: team can build/operate it
- Usability: users can successfully use it
Prioritization rule:
- High risk + low certainty assumptions are tested first.
## Problem Validation Techniques
- Problem interviews focused on current behavior
- Journey friction mapping
- Support ticket and sales-call synthesis
- Behavioral analytics triangulation
Evidence threshold examples:
- Same pain repeated across multiple target users
- Observable workaround behavior
- Measurable cost of current pain
## Solution Validation Techniques
- Concept tests (value proposition comprehension)
- Prototype usability tests (task success/time-to-complete)
- Fake door or concierge tests (demand signal)
- Limited beta cohorts (retention/activation signals)
## Discovery Sprint Planning
Suggested 10-day structure:
- Day 1-2: Outcome + opportunity framing
- Day 3-4: Assumption mapping + test design
- Day 5-7: Problem and solution tests
- Day 8-9: Evidence synthesis + decision options
- Day 10: Stakeholder decision review
## Tooling
### `scripts/assumption_mapper.py`
CLI utility that:
- reads assumptions from CSV or inline input
- scores risk/certainty priority
- emits prioritized test plan with suggested test types
See `references/discovery-frameworks.md` for framework details.
Starter prompts for the main use cases—copy and use them directly.
Map checkout-friction opportunities to evidence Use for: Map checkout-friction opportunities to evidence. Prepare: One measurable outcome, interview or behavior evidence, candidate solutions, and assumption CSV data.
Use the installed product-discovery Skill. Task: Map checkout-friction opportunities to evidence. Inputs: [INPUT]. Constraints: [CONSTRAINTS]. Check missing information first. Produce a reviewable result with evidence, assumptions, and next steps. It plans discovery and scores supplied assumptions; it does not interview customers or establish demand by itself.[INPUT][CONSTRAINTS]Prioritize risky assumptions for a new subscription offer Use for: Prioritize risky assumptions for a new subscription offer. Prepare: One measurable outcome, interview or behavior evidence, candidate solutions, and assumption CSV data.
Use the installed product-discovery Skill. Task: Prioritize risky assumptions for a new subscription offer. Inputs: [INPUT]. Constraints: [CONSTRAINTS]. Check missing information first. Produce a reviewable result with evidence, assumptions, and next steps. It plans discovery and scores supplied assumptions; it does not interview customers or establish demand by itself.[INPUT][CONSTRAINTS]Plan a discovery sprint with proceed, pivot, or stop criteria Use for: Plan a discovery sprint with proceed, pivot, or stop criteria. Prepare: One measurable outcome, interview or behavior evidence, candidate solutions, and assumption CSV data.
Use the installed product-discovery Skill. Task: Plan a discovery sprint with proceed, pivot, or stop criteria. Inputs: [INPUT]. Constraints: [CONSTRAINTS]. Check missing information first. Produce a reviewable result with evidence, assumptions, and next steps. It plans discovery and scores supplied assumptions; it does not interview customers or establish demand by itself.[INPUT][CONSTRAINTS]A synthetic store wants fewer return-eligibility questions. Interviews, behavior records and concept-test results support a decision about demand and willingness to submit before development.
Case input files: business-inputs.zip
Use the product-discovery Skill.
Our team wants to improve the return experience. Connect the supplied interviews and discovery evidence to an opportunity tree, identify desirability, viability, usability and feasibility risks, and prioritize assumptions. Compare the supplied experiment observations with their decision thresholds, propose a prototype and recommend continue, pivot or stop.
The attached business materials are:
- inputs/brief.csv
- inputs/evidence.json
- inputs/merchant.json
Deliver a complete result.md report that the operations team can read, plus any finished files needed for this task. Keep supporting calculations and evidence with the deliverables. Write the report in English; use the requested target language for customer-facing copy. The business datasets are fictional examples unless the brief explicitly names a live public website.The primary file produced by this prompt is shown below in its original language.
Recommendation: pivot the eligibility-preview concept and retest before committing delivery resources. Return uncertainty warrants further discovery. The current solution fails the supplied demand gate, even though comprehension and task speed meet their thresholds. Preserve merchant approval, make the request and review stages explicit, and investigate why people decline to submit.
All supplied interviews, journey observations, merchant data and experiment records are synthetic examples; this report evaluates those records and does not claim real customer testing or business improvement.
Improve the return experience for US first-time mug shoppers and unused-return customers. Use one primary outcome: the share of return-policy visitors who need to contact support to understand eligibility. B1 records 12 contacts among 20 policy visitors (60%), but does not isolate eligibility-related contacts. Treat 60% as a broad support-contact baseline proxy, then classify contact reasons before claiming movement in the primary outcome.
Proposed target: reduce eligibility-clarification contacts by at least 20 percentage points from a verified baseline within four weeks of an approved limited pilot. This is a planning target, not a supplied or achieved result. Track request submission, approval misunderstanding, unresolved requests and total staff handling time as guardrails. Do not lower contacts by concealing support or obstructing returns. Routine merchant review after submission is separate from a clarification contact.
| Source | What the supplied record shows | Interpretation and limit |
|---|---|---|
| I1 | Checked policy twice; contacted Mia; 6 minutes | Eligibility uncertainty produces repeated checking and support work. |
| I2 | Kept unused mug boxed while waiting; 8 minutes | Waiting prevents progress; keeping the item boxed is an observable workaround in the record. |
| I5 | Short eligibility answer helps, but refund confirmation still needed; 5 minutes | Eligibility information alone may not satisfy the need for closure. |
| I3 | Dispatch confused with delivery; emailed support; 4 minutes | Separate arrival-information opportunity. |
| I4 | Added a second mug and still paid shipping; cart arithmetic; 3 minutes | Separate landed-cost opportunity. |
| B1 | 12/20 contacted support; 8/20 revisited | 60% contact rate and 40% repeat-visit rate support journey friction; the record does not link individual sessions to interviews or classify contact reasons. |
The supplied problem gate requires at least 3/5 independent reports of return uncertainty, at least two observed workarounds and B1 contact rate of at least 40%. I1, I2 and I5 provide 3/5 reports; their recorded workarounds are contacting support, waiting with the item boxed, and requesting approval. B1 is 60%, above 40%. The gate passes within the supplied records, treating the five interview entries as independent as the gate assumes. Recruitment independence and independent observation of each workaround are not documented; confirm them during the next discovery cycle.
Return uncertainty appears in three interviews, versus one each for arrival and shipping. The return interviews contain 19 reported minutes total (6 + 8 + 5); these are customer friction indicators, not measured staff handling time or expected savings. Frequency outside this small sample, financial severity and willingness to submit remain uncertain. The 2/5 submission result is the strongest supplied behavioral warning against assuming demand.
Job to be done: “When I have an unused mug I want to return, I want to know whether I can request a return and what happens next, so I can act without mistaking an eligibility answer for a refund promise.”
Root outcome: fewer eligibility-clarification contacts, subject to successful requests and safe merchant review. The adjacent branches preserve alternatives before convergence; they are lower priority because their evidence is thinner and their connection to the return outcome is indirect.
| Opportunity: unmet need | Evidence | Candidate solutions | Experiments |
|---|---|---|---|
| O1. Know whether I can request a return and obtain a clear next step | I1, I2, I5; B1 corroborates general friction | S1: eligibility preview followed by request and pending-review receipt. S2: concise policy plus a direct human-review request without a separate preview. | E1: moderated task and teach-back for S1, then observe submission; apply the original solution gate. E2: fresh concierge cohort comparing reasons for submitting or declining S1/S2; use 3/5 submission as a directional gate per concept, not a statistical superiority claim. |
| O2. Know when my order will arrive | I3 | Separate dispatch and delivery wording; explain the two stages in order help | E3: comprehension task asking shoppers to distinguish the two stages; proposed pass 4/5 correct. Defer delivery work until repeated pain is found in at least three independent relevant interviews. |
| O3. Know the total spend needed for free shipping | I4 | Cart subtotal and amount remaining to the threshold | E4: cart arithmetic task using two mugs; proposed pass 4/5 identify $48 subtotal, $2 shortfall and $5 shipping. First confirm repeated need in relevant interviews. |
O1 is the discovery priority. O2 and O3 remain documented alternatives, not approved build scope. Dispatch is within two business days and delivery is listed as 3–5 business days; the record does not specify the delivery interval's starting point, so clarify that before publishing a combined arrival promise. Two $24 mugs total $48, below the $50 free-shipping threshold; they do not qualify for free shipping.
| Gate | Required | Supplied observation | Decision |
|---|---|---|---|
| Approval comprehension | At least 4/5 distinguish eligibility from refund approval | 4/5 (80%); one misunderstood | Pass exactly; retain an explicit approval boundary and investigate the error |
| Task speed | At least 4/5 finish within two minutes | 4/5 (80%) under 120 seconds | Pass exactly |
| Concierge demand | At least 3/5 submit a request | 2/5 (40%) versus 60% required | Fail by one submission, or 20 percentage points |
All three solution requirements must pass; the combined gate fails. Task durations are 70, 95, 105, 115 and 180 seconds: mean 113 seconds, median 105 seconds, range 70–180 seconds. The aggregate record does not identify whether the slow participant also misunderstood approval or declined submission. Do not invent that connection. It also does not explain non-submission or demonstrate that submitted requests were eligible.
This supports a pivot, not a rollout and not abandoning the problem. The problem signal passes while the proposed behavior falls short. No retention, support reduction or financial lift has been established.
Scores use the skill's mapper: risk × (1 − certainty). Inputs below are supplied judgments, not probabilities measured by the experiment. Keep them unchanged for traceability; T1 should inform the next scoring review.
| Rank | Assumption / category | Risk | Certainty | Priority | Next validation and decision criterion |
|---|---|---|---|---|---|
| 1 | Users submit eligible requests after reading a preview — desirability | 0.90 | 0.20 | 0.72 | Revised concierge test: at least 3/5 submit without prompting. Independently review eligibility for each request; log all declines and reasons. T1 only proves 2 submissions, not eligibility. |
| 2 | Saved handling time justifies operations cost — viability | 0.80 | 0.30 | 0.56 | Time all handling and rework in baseline and concierge cases, calculate full cost; require positive conservative net benefit before delivery commitment. |
| 3 | Customers distinguish eligibility from refund approval — usability | 0.90 | 0.40 | 0.54 | Teach-back before submission: at least 4/5 distinguish the two without moderator help, alongside at least 4/5 under two minutes. Any design that grants or promises refunds from a preview is rejected. |
| 4 | Mia can route requests without automatic refunds — feasibility | 0.70 | 0.60 | 0.28 | Operations walkthrough: all scripted eligible, uncertain, outside-window, duplicate and routing-failure cases preserve pending review; zero automatic refunds, silent losses or duplicate requests. |
The feasibility score is lower, but its control boundary must pass before any pilot. Mia owns routine review; Alex handles exceptions and routing failures. Neither owner has been contacted or assigned live work by this exercise.
Viability cannot yet pass. Use:
weekly net benefit = N × (baseline minutes − new minutes) ÷ 60 × loaded hourly cost − weekly tool cost − incremental error cost
Count review, escalation, duplicate handling and rework in the new minutes. Break-even minutes saved per request are 60 × (tool cost + incremental error cost) ÷ (N × loaded hourly cost), for positive N and hourly cost. Request volume, measured staff time, loaded cost and ongoing costs are missing. Do not substitute customer-reported interview minutes for staff savings. The merchant's weekly refunds/gross are 5% in both periods ($120/$2,400 and $144/$2,880); these figures do not establish return-request frequency, margin impact or savings from this concept.
The complete screen and operations specification is in prototype.md. No customer-copy language is specified in the inputs, so this draft uses English. The proposed pivot moves from a short eligibility answer to an explicit request-and-review journey; the actual prior screen design is not supplied.
Screen 1 — Check a return
“Returns are available for unused items within 30 days. We can help you check whether you can request a return. HarborMug must review your request before any refund is approved.”
Fields: order reference; delivery date; item; “Is the item unused?” with Yes / No / Not sure. Button: Check return options. Provide Ask support throughout.
Screen 2 — Preview for the supplied example
“Your item appears to meet the return-request conditions. Your request is 14 days after delivery, within the 30-day window. You told us the item is unused. This is not refund approval. Send a request for HarborMug to review.”
Show editable answers and Send return request. Unopened packaging supports the example's screening result but must not replace confirmation that the item is unused. An uncertain or apparently ineligible result offers human review and does not promise acceptance.
Screen 3 — Request received
“Your return request has been sent for review. Your refund has not been approved. HarborMug will confirm the next steps after reviewing your request. Please wait for return instructions before sending the item.”
Show this receipt only after the request is durably recorded. Do not invent a response deadline, return address, label, postage policy, refund amount or payment action. If delivery fails: “We couldn't send your request. Please try again or ask support.”
Operations handoff: create one pending request for Mia, with order reference, item, delivery date, stated condition and submission status. Mia checks the order and policy and records the review outcome. Missing or disputed information, policy exceptions and routing failures go to Alex. No preview, submission or receipt triggers a refund. Send instructions only after the merchant has decided the next step.
This is a future test plan; no new participants have been recruited and no operational changes have been made.
| Days | Owner role | Work and output |
|---|---|---|
| 1–2 | Discovery lead + Mia | Verify problem-source independence and contact reasons; establish eligibility-contact baseline and staff-time measurement. Review interview behavior, not only preferences. |
| 3–4 | Designer + operations | Build the draft screens in prototype.md; rehearse eligibility, uncertainty, duplicate and routing-failure states with Mia/Alex roles. Lock task script and thresholds before testing. |
| 5–7 | Researcher + Mia role | Recruit five fresh relevant participants for E1 with a real return intent appropriate to the test. Observe unaided comprehension, duration and submission separately. Ask non-submitters what they chose to do and why. Run E2 in a separate fresh five-person cohort if feasible; otherwise defer the comparison and retain the same concept gates. Measure total handling time in a controlled concierge rehearsal. |
| 8–9 | Discovery lead + operations | Review evidence daily during testing; distinguish ineligible cases from demand failures. Reconcile missing, duplicate and failed requests; compute conservative cost scenarios. Do not change thresholds mid-test. |
| 10 | Operations decision owner | Review gates and costs; choose continue, pivot or stop and document the evidence. |
For each task, record anonymous participant code, relevant return intent, scenario eligibility, prototype version, unprompted comprehension answer, duration, submission event, refusal reason, review disposition and handling minutes. Retain separate denominators for each cohort. Keep recruitment data outside the evidence table.
Continue to a small supervised pilot only if all original solution gates pass in the revised cohort, the routing rehearsal has no control failures, and measured costs support positive conservative benefit. This would authorize further learning, not establish a population effect.
Pivot again if the return problem remains supported but a solution gate fails and a specific observed barrier suggests a testable change. Test the direct human-review request if previewing adds uncertainty or friction.
Stop this solution if a second revised cohort still has fewer than 3/5 submissions without a credible fix, or measured economics remain nonpositive after a realistic lower-cost alternative. Reassess the opportunity if independent interviews and behavior no longer support the problem gate. These stop rules are proposed for the next cycle, not retroactive thresholds.
The gaps that change the decision are the reason for three non-submissions, unverified request eligibility, unclassified contact reasons, unverified interview independence and missing operational cost measurements. Until resolved, approve discovery work only.
Merchant business data is synthetic. Website observations, when present, come from the public URLs listed in the report.
It plans discovery and scores supplied assumptions; it does not interview customers or establish demand by itself.
Source and package files reviewed: GitHub 6d2f02ea077e. This is a static review, not an installation or business-outcome test.
Use authorized inputs and keep secrets out of prompts. Review customer-facing claims, calculations, code changes, and any proposed external action before applying them.
Map product opportunities and assumptions before committing to development. Opportunity Solution Trees connect an outcome to needs and experiments; the Python mapper ranks assumption tests.
Choose the method for your agent and install the complete package, not just the displayed SKILL.md. One measurable outcome, interview or behavior evidence, candidate solutions, and assumption CSV data. Start a new agent session and explicitly ask to use product-discovery. Try one use case below with a small sample and review the output.
Map checkout-friction opportunities to evidence; Prioritize risky assumptions for a new subscription offer; Plan a discovery sprint with proceed, pivot, or stop criteria
It plans discovery and scores supplied assumptions; it does not interview customers or establish demand by itself.
Source and package files reviewed: GitHub 6d2f02ea077e. This is a static review, not an installation or business-outcome test.
Source and package files reviewed: GitHub 6d2f02ea077e. This is a static review, not an installation or business-outcome test.
Source and package files reviewed: GitHub 6d2f02ea077e. This is a static review, not an installation or business-outcome test.
No reviews yet.