方法与优势
同一个顾客问题下面可以放多个解决方案。团队能够比较补充说明、调整流程和新增功能等选项,不必把所有反馈都转成开发任务。
Product Discovery 用于产品需求验证,把顾客证据、业务目标和候选方案连起来。提供一个可衡量的目标、访谈或行为资料后,它会整理机会解决方案树并排序待验证假设,适合在改造结账流程、推出订阅服务或开发新功能前判断先测试什么。
机会解决方案树把想要达到的结果、顾客需求、候选方案和验证实验连在一起。Skill 会帮助团队整理这些关系,让一个功能需求能够追溯到真实问题,而不是一开始就默认必须开发它。
随包工具可以按提供的假设资料安排验证顺序。最终得到的是需求探索计划、证据缺口和决策条件;访谈及实验仍需要实际开展,才能知道方案是否值得继续投入。
同一个顾客问题下面可以放多个解决方案。团队能够比较补充说明、调整流程和新增功能等选项,不必把所有反馈都转成开发任务。
用假设排序决定接下来要弄清什么。例如,顾客是否愿意订阅尚不明确时,可能值得先验证这个关键前提,再花时间完善界面;已有充分证据的需求则可以进入更具体的方案测试。
一个可衡量目标、访谈或行为证据、候选方案和假设 CSV。
使用支持 Skill 且能访问文件的 Agent。随包 Python 辅助工具需要 Python 3;提供数据前先查看样例结构。
它规划发现过程并评估已提供的假设,不能自行访谈客户或证明需求成立。
将指令复制给 Codex 或 Claude Code,让助手从原始仓库下载固定提交,安装完整文件并检查所需依赖。
请在我当前使用的应用中安装 product-discovery,直接执行文件安装,不要只解释步骤。
原始仓库:https://github.com/alirezarezvani/claude-skills.git
固定提交:6d2f02ea077eead1bee5411a31bcc6db5a11a70c
Skill 路径:product-team/skills/product-discovery
1. 将这个版本下载到新目录。执行随包脚本前,先阅读 SKILL.md 和安装参考文件,不替换成其他作者的包。
2. Codex 安装到 ~/.agents/skills/product-discovery,Claude Code 安装到 ~/.claude/skills/product-discovery,只安装到我正在使用的应用。安装完整 Skill 文件夹,保留 scripts、references、assets 和随包声明;将仓库根目录许可证一并保留。先检查所有目标目录;已有安装时,说明差异后再决定是否替换。
3. 比较来源和安装目录的文件清单、文件哈希,检查文档要求的运行时、依赖及外部连接。只配置此 Skill 所需的本地依赖,适用时使用隔离环境;账号登录由我在本地完成,不把凭据贴进聊天。
4. 返回来源提交、实际安装路径、文件检查结果及尚未完成的运行环境配置,说明如何调用 product-discovery。文件复制与应用发现分别检查,需要时新建会话。不要执行生产任务,也不要把安装完成说成已确认业务效果。以下为已核对版本未经改写的 SKILL.md。安装完整包才能保留引用的脚本、素材和指引。下方启动提示词为 EcomAgentTools 编写的示例。
---
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.
以下是主要功能的用例提示词,可以直接复制使用。
将结账阻力对应到机会与证据 适用于:将结账阻力对应到机会与证据。请准备:一个可衡量目标、访谈或行为证据、候选方案和假设 CSV。
请使用已安装的 product-discovery Skill。任务:将结账阻力对应到机会与证据。输入:[INPUT]。限制:[CONSTRAINTS]。先检查缺失信息,再输出可审查的结果、依据、假设和下一步。它规划发现过程并评估已提供的假设,不能自行访谈客户或证明需求成立。[INPUT][CONSTRAINTS]排列订阅方案的高风险假设 适用于:排列订阅方案的高风险假设。请准备:一个可衡量目标、访谈或行为证据、候选方案和假设 CSV。
请使用已安装的 product-discovery Skill。任务:排列订阅方案的高风险假设。输入:[INPUT]。限制:[CONSTRAINTS]。先检查缺失信息,再输出可审查的结果、依据、假设和下一步。它规划发现过程并评估已提供的假设,不能自行访谈客户或证明需求成立。[INPUT][CONSTRAINTS]制定带推进、调整或停止条件的发现冲刺 适用于:制定带推进、调整或停止条件的发现冲刺。请准备:一个可衡量目标、访谈或行为证据、候选方案和假设 CSV。
请使用已安装的 product-discovery Skill。任务:制定带推进、调整或停止条件的发现冲刺。输入:[INPUT]。限制:[CONSTRAINTS]。先检查缺失信息,再输出可审查的结果、依据、假设和下一步。它规划发现过程并评估已提供的假设,不能自行访谈客户或证明需求成立。[INPUT][CONSTRAINTS]模拟店铺希望减少退货资格咨询,输入访谈、行为记录和概念测试结果。需要先确认真实任务与提交意愿,再决定是否投入开发。
案例输入资料: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.下方直接展示本次 Prompt 产生的主要文件,保留实际输出语言。
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.
案例中的商家经营资料为模拟数据;涉及网站检查时,报告中的页面观察来自所列公开网址。
它规划发现过程并评估已提供的假设,不能自行访谈客户或证明需求成立。
核对源码及随包文件:GitHub 6d2f02ea077e。本次为静态审查,不代表已完成安装运行或业务效果测试。
使用获授权输入,不把密钥贴入提示词。采用前检查面向客户的声明、计算、代码改动及任何拟议的外部操作。
在投入开发前梳理产品机会与假设。机会解决方案树把目标、需求和实验连起来,Python 工具可排列假设测试优先级。
按实际 Agent 选择方式,安装完整包,不要只复制页面中的 SKILL.md。 一个可衡量目标、访谈或行为证据、候选方案和假设 CSV。 开启新 Agent 会话,明确要求使用 product-discovery。先用小型样本尝试下方一个场景,并检查输出。
将结账阻力对应到机会与证据;排列订阅方案的高风险假设;制定带推进、调整或停止条件的发现冲刺
它规划发现过程并评估已提供的假设,不能自行访谈客户或证明需求成立。
核对源码及随包文件:GitHub 6d2f02ea077e。本次为静态审查,不代表已完成安装运行或业务效果测试。
核对源码及随包文件:GitHub 6d2f02ea077e。本次为静态审查,不代表已完成安装运行或业务效果测试。
暂无评论。