IntermediateAgent Skill

Product Discovery

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.

Views
0
Copies
0
Favorites
0
Editorial Score
78/100
01

What this Skill does

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.

02

What makes it different

01

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.

02

What you can use it for

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.

03

Before you install

Inputs to prepare

One measurable outcome, interview or behavior evidence, candidate solutions, and assumption CSV data.

Agent and runtime

Use a Skill-capable agent with file access. Python 3 is required for the bundled Python helpers; inspect their sample schemas before supplying data.

Scope to confirm

It plans discovery and scores supplied assumptions; it does not interview customers or establish demand by itself.

04

Install and get started

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.

  1. Open Codex or Claude Code with local file and terminal access.
  2. Copy the request below into the app you are using. The assistant will select that app’s installation directory.
  3. Check the returned path and file checks. Start a new session if needed, then ask the assistant to use the installed Skill.
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.
05

Original Skill.md

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.
06

Get started

Starter prompts for the main use cases—copy and use them directly.

01

Map checkout-friction opportunities to evidence

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.

Show prompt and variablesHide prompt and variables
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.

Replace these variables

[INPUT]
One measurable outcome, interview or behavior evidence, candidate solutions, and assumption CSV data.
[CONSTRAINTS]
Scope, allowed actions, output format, and review requirements.
02

Prioritize risky assumptions for a new subscription offer

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.

Show prompt and variablesHide prompt and variables
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.

Replace these variables

[INPUT]
One measurable outcome, interview or behavior evidence, candidate solutions, and assumption CSV data.
[CONSTRAINTS]
Scope, allowed actions, output format, and review requirements.
03

Plan a discovery sprint with proceed, pivot, or stop criteria

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.

Show prompt and variablesHide prompt and variables
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.

Replace these variables

[INPUT]
One measurable outcome, interview or behavior evidence, candidate solutions, and assumption CSV data.
[CONSTRAINTS]
Scope, allowed actions, output format, and review requirements.
07

Worked example: Decide whether to build self-service returns

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.

Steps and prompt

  1. Prepare the attached business materials, preserving amounts, units, dates and metric definitions.
  2. 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.
  3. Submit the exact prompt below. Read the primary deliverable on the right and download all deliverables for the team handoff.

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.

What the run produced

The primary file produced by this prompt is shown below in its original language.

HarborMug return discovery decision

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.

Outcome and decision boundary

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.

Evidence and problem validation

SourceWhat the supplied record showsInterpretation and limit
I1Checked policy twice; contacted Mia; 6 minutesEligibility uncertainty produces repeated checking and support work.
I2Kept unused mug boxed while waiting; 8 minutesWaiting prevents progress; keeping the item boxed is an observable workaround in the record.
I5Short eligibility answer helps, but refund confirmation still needed; 5 minutesEligibility information alone may not satisfy the need for closure.
I3Dispatch confused with delivery; emailed support; 4 minutesSeparate arrival-information opportunity.
I4Added a second mug and still paid shipping; cart arithmetic; 3 minutesSeparate landed-cost opportunity.
B112/20 contacted support; 8/20 revisited60% 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.”

Opportunity solution tree

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 needEvidenceCandidate solutionsExperiments
O1. Know whether I can request a return and obtain a clear next stepI1, I2, I5; B1 corroborates general frictionS1: 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 arriveI3Separate dispatch and delivery wording; explain the two stages in order helpE3: 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 shippingI4Cart subtotal and amount remaining to the thresholdE4: 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.

Experiment observations versus thresholds

GateRequiredSupplied observationDecision
Approval comprehensionAt least 4/5 distinguish eligibility from refund approval4/5 (80%); one misunderstoodPass exactly; retain an explicit approval boundary and investigate the error
Task speedAt least 4/5 finish within two minutes4/5 (80%) under 120 secondsPass exactly
Concierge demandAt least 3/5 submit a request2/5 (40%) versus 60% requiredFail 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.

Prioritized assumptions and risks

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.

RankAssumption / categoryRiskCertaintyPriorityNext validation and decision criterion
1Users submit eligible requests after reading a preview — desirability0.900.200.72Revised 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.
2Saved handling time justifies operations cost — viability0.800.300.56Time all handling and rework in baseline and concierge cases, calculate full cost; require positive conservative net benefit before delivery commitment.
3Customers distinguish eligibility from refund approval — usability0.900.400.54Teach-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.
4Mia can route requests without automatic refunds — feasibility0.700.600.28Operations 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.

Completed prototype draft

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.

Proposed ten-day discovery sprint

This is a future test plan; no new participants have been recruited and no operational changes have been made.

DaysOwner roleWork and output
1–2Discovery lead + MiaVerify problem-source independence and contact reasons; establish eligibility-contact baseline and staff-time measurement. Review interview behavior, not only preferences.
3–4Designer + operationsBuild 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–7Researcher + Mia roleRecruit 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–9Discovery lead + operationsReview 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.
10Operations decision ownerReview 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.

Supporting deliverables

Merchant business data is synthetic. Website observations, when present, come from the public URLs listed in the report.

08

Risks and operating notes

Known limits

It plans discovery and scores supplied assumptions; it does not interview customers or establish demand by itself.

Evidence and review

Source and package files reviewed: GitHub 6d2f02ea077e. This is a static review, not an installation or business-outcome test.

Before acting on the result

Use authorized inputs and keep secrets out of prompts. Review customer-facing claims, calculations, code changes, and any proposed external action before applying them.

Frequently asked questions

What does it do, and what is the advantage?

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.

How do I install it and start?

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.

Which situations is it useful for?

Map checkout-friction opportunities to evidence; Prioritize risky assumptions for a new subscription offer; Plan a discovery sprint with proceed, pivot, or stop criteria

What limitations should I know?

It plans discovery and scores supplied assumptions; it does not interview customers or establish demand by itself.

What was checked for this page?

Source and package files reviewed: GitHub 6d2f02ea077e. This is a static review, not an installation or business-outcome test.

No reviews yet.

Leave a review

Rate every dimension, then share your real experience.

Task effectiveness
Setup and ease of use
Reliability and guardrails
Documentation clarity
Time to first useful result
Author / maintainer

Alireza Rezvani

Source and package files reviewed: GitHub 6d2f02ea077e. This is a static review, not an installation or business-outcome test.