中级Agent Skill

产品机会验证

Product Discovery 用于产品需求验证,把顾客证据、业务目标和候选方案连起来。提供一个可衡量的目标、访谈或行为资料后,它会整理机会解决方案树并排序待验证假设,适合在改造结账流程、推出订阅服务或开发新功能前判断先测试什么。

浏览量
0
复制次数
0
收藏
0
编辑评分
78/100
01

这个 Skill 是做什么的

机会解决方案树把想要达到的结果、顾客需求、候选方案和验证实验连在一起。Skill 会帮助团队整理这些关系,让一个功能需求能够追溯到真实问题,而不是一开始就默认必须开发它。

随包工具可以按提供的假设资料安排验证顺序。最终得到的是需求探索计划、证据缺口和决策条件;访谈及实验仍需要实际开展,才能知道方案是否值得继续投入。

02

它有什么特色

01

方法与优势

同一个顾客问题下面可以放多个解决方案。团队能够比较补充说明、调整流程和新增功能等选项,不必把所有反馈都转成开发任务。

02

适用任务

用假设排序决定接下来要弄清什么。例如,顾客是否愿意订阅尚不明确时,可能值得先验证这个关键前提,再花时间完善界面;已有充分证据的需求则可以进入更具体的方案测试。

03

安装前的特殊要求

需要准备的输入

一个可衡量目标、访谈或行为证据、候选方案和假设 CSV。

Agent 与运行环境

使用支持 Skill 且能访问文件的 Agent。随包 Python 辅助工具需要 Python 3;提供数据前先查看样例结构。

需确认的适用边界

它规划发现过程并评估已提供的假设,不能自行访谈客户或证明需求成立。

04

安装与开始使用

将指令复制给 Codex 或 Claude Code,让助手从原始仓库下载固定提交,安装完整文件并检查所需依赖。

  1. 打开能访问本机文件和终端的 Codex 或 Claude Code。
  2. 复制下方指令发给正在使用的应用,由助手选择该应用的安装目录。
  3. 查看返回的安装路径和文件检查结果;需要时新建会话,再要求助手使用已安装的 Skill。
请在我当前使用的应用中安装 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。文件复制与应用发现分别检查,需要时新建会话。不要执行生产任务,也不要把安装完成说成已确认业务效果。
05

原始 Skill.md

以下为已核对版本未经改写的 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.
06

开始使用

以下是主要功能的用例提示词,可以直接复制使用。

01

将结账阻力对应到机会与证据

将结账阻力对应到机会与证据 适用于:将结账阻力对应到机会与证据。请准备:一个可衡量目标、访谈或行为证据、候选方案和假设 CSV。

查看 Prompt 和变量收起 Prompt 和变量
请使用已安装的 product-discovery Skill。任务:将结账阻力对应到机会与证据。输入:[INPUT]。限制:[CONSTRAINTS]。先检查缺失信息,再输出可审查的结果、依据、假设和下一步。它规划发现过程并评估已提供的假设,不能自行访谈客户或证明需求成立。

需要替换的变量

[INPUT]
一个可衡量目标、访谈或行为证据、候选方案和假设 CSV。
[CONSTRAINTS]
任务范围、允许的操作、输出格式和审核要求。
02

排列订阅方案的高风险假设

排列订阅方案的高风险假设 适用于:排列订阅方案的高风险假设。请准备:一个可衡量目标、访谈或行为证据、候选方案和假设 CSV。

查看 Prompt 和变量收起 Prompt 和变量
请使用已安装的 product-discovery Skill。任务:排列订阅方案的高风险假设。输入:[INPUT]。限制:[CONSTRAINTS]。先检查缺失信息,再输出可审查的结果、依据、假设和下一步。它规划发现过程并评估已提供的假设,不能自行访谈客户或证明需求成立。

需要替换的变量

[INPUT]
一个可衡量目标、访谈或行为证据、候选方案和假设 CSV。
[CONSTRAINTS]
任务范围、允许的操作、输出格式和审核要求。
03

制定带推进、调整或停止条件的发现冲刺

制定带推进、调整或停止条件的发现冲刺 适用于:制定带推进、调整或停止条件的发现冲刺。请准备:一个可衡量目标、访谈或行为证据、候选方案和假设 CSV。

查看 Prompt 和变量收起 Prompt 和变量
请使用已安装的 product-discovery Skill。任务:制定带推进、调整或停止条件的发现冲刺。输入:[INPUT]。限制:[CONSTRAINTS]。先检查缺失信息,再输出可审查的结果、依据、假设和下一步。它规划发现过程并评估已提供的假设,不能自行访谈客户或证明需求成立。

需要替换的变量

[INPUT]
一个可衡量目标、访谈或行为证据、候选方案和假设 CSV。
[CONSTRAINTS]
任务范围、允许的操作、输出格式和审核要求。
07

实际使用案例:判断是否值得开发自助退货入口

模拟店铺希望减少退货资格咨询,输入访谈、行为记录和概念测试结果。需要先确认真实任务与提交意愿,再决定是否投入开发。

使用步骤与 Prompt

  1. 准备下方案例输入资料,保留商品、政策和经营记录中的金额、单位及时间口径。
  2. 把访谈串成机会树,比较需求、商业、易用性和技术风险,用已有观察判断继续、调整还是停止。
  3. 提交下方完整 Prompt,查看右侧主要产物;需要交接给同事时,下载包含全部交付文件的压缩包。

案例输入资料: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 产生的主要文件,保留实际输出语言。

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

案例中的商家经营资料为模拟数据;涉及网站检查时,报告中的页面观察来自所列公开网址。

08

风险与使用注意事项

已知限制

它规划发现过程并评估已提供的假设,不能自行访谈客户或证明需求成立。

证据与复核

核对源码及随包文件:GitHub 6d2f02ea077e。本次为静态审查,不代表已完成安装运行或业务效果测试。

采用结果前

使用获授权输入,不把密钥贴入提示词。采用前检查面向客户的声明、计算、代码改动及任何拟议的外部操作。

常见问题

它能做什么,有什么优势?

在投入开发前梳理产品机会与假设。机会解决方案树把目标、需求和实验连起来,Python 工具可排列假设测试优先级。

如何安装和开始使用?

按实际 Agent 选择方式,安装完整包,不要只复制页面中的 SKILL.md。 一个可衡量目标、访谈或行为证据、候选方案和假设 CSV。 开启新 Agent 会话,明确要求使用 product-discovery。先用小型样本尝试下方一个场景,并检查输出。

适合哪些使用场景?

将结账阻力对应到机会与证据;排列订阅方案的高风险假设;制定带推进、调整或停止条件的发现冲刺

使用前需要了解哪些限制?

它规划发现过程并评估已提供的假设,不能自行访谈客户或证明需求成立。

本页核对了什么?

核对源码及随包文件:GitHub 6d2f02ea077e。本次为静态审查,不代表已完成安装运行或业务效果测试。

暂无评论。

发表评论

请先为每一项打分,再分享你的真实使用体验。

任务有效性
安装与使用难度
稳定性与边界
文档清晰度
首次获得有效结果
作者 / 维护者

Alireza Rezvani

核对源码及随包文件:GitHub 6d2f02ea077e。本次为静态审查,不代表已完成安装运行或业务效果测试。