关于 pm-discovery
面向产品团队的生成式产品探索技能，用于规划研究与学习。它按决策风险匹配证据，强调持续且问题优先的探索，并将探索规划与实验设计区分开来。
主要功能
- 01识别价值、可用性、可行性和商业风险
- 02规划持续且关注结果的探索
- 03区分问题与拟议解决方案
- 04按决策风险匹配研究证据
- 05依据过往行为开展包容且合乎伦理的研究
适用场景
- 01为不确定的产品问题规划研究
- 02选择定性与定量方法
- 03确定高成本产品决策所需证据
- 04将已验证的问题转化为解决方案方向
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/pm-discovery确认已加载。
详细介绍
产品发现技能
此技能的运作方式（请先阅读）
这是一项生成式技能，而“做一些发现工作”隐藏着几个常见陷阱。人们本能的做法是：把发现当作构建前的一次性研究阶段（之后再也不回顾），直接跳到解决方案和功能，套用通用的“访谈几位用户 + 发送一份调查问卷”计划，而不根据实际风险调整严谨程度，用发布了什么而不是带来了什么改变来衡量成功，以及询问用户“你会用这个吗？”（大家都会说会）。结果就是一个忙碌却没有从中学习的功能工厂。好的发现工作应当是持续的、问题优先的、以成果为导向的，并且证据与风险相匹配。因此，此技能会把关以下事项：
- 确定要降低哪种风险，以及决策需要多大把握——价值、可用性、可行性或商业可行性风险；成本低且可逆的决策所需的证据，远少于成本高且不可逆的押注。
- 贯彻始终不变的核心原则——保持持续节奏，以成果而非产出为重，先关注问题再考虑解决方案，重视过去的行为而非假设，证据与风险相匹配，从已验证的问题出发制定解决方案，并开展合乎伦理的研究。
- 明确依赖情境的决策（问题研究还是解决方案研究、定性还是定量、轻量还是深入、自行开展还是寻求专家协助、承诺之前需要多大把握），并权衡利弊。
随后，它会将验证工作交给 pm-assumption-rigor-audit、pm-okr-metric-validity-audit 和 pm-prioritization-rigor-audit。针对特定假设的实际测试／实验设计属于生成式技能 pm-assumption-testing 的范畴——发现工作决定要了解什么，以及这有多重要；假设测试则设计测试。
步骤 0 — 规划发现工作前先明确背景
如果信息未知，请提问；如果在没有答案的情况下继续，请说明所采用的假设：
- 四种风险中，哪一种最不确定？ 价值（有人会想要它吗？）、可用性（他们能用它吗？）、可行性（我们能构建它吗？）、商业可行性（它符合业务需求吗？）。发现工作的目的是消除最高的那项风险——选择活动前先明确说出是哪一项。
- 你处于问题空间还是解决方案空间？“有人在意这个问题吗？”与“这个解决方案有效吗？”是两个不同的问题，需要采用不同的方法。问题尚未验证前，不要跳到解决方案发现。
- **这项决策的可逆性如何，成本有多高？**这决定了需要投入多少精力来获得把握。对一个可逆的小改动进行过度研究，会浪费一个季度；对成本高且不可逆的押注研究不足，则会导致团队交付错误的东西。
- **哪些人会参与，参与节奏如何？**产品三人组（PM + 设计师 + 工程师）及跨职能合作伙伴；这是持续进行的习惯，还是一次性研究？默认采用持续进行的方式。
始终适用的核心原则（适用于任何探索工作）
- 让探索持续进行，而不是把它当作一个阶段。 一次性开展的前期研究几个月内就会过时。将轻量级客户联系融入每周节奏——简短访谈、查看支持工单、旁听销售电话——并将其视为与冲刺规划同样不可妥协的事项。自动化招募（固定预约链接、产品内拦截调研），避免忙碌的一周让探索工作停摆。间歇性探索得出的洞见会过期；持续探索则能不断积累。
- 以成果为导向，而非产出。 明确你希望改变的用户行为（产品成果，即你能影响的领先指标），并让它与业务成果（收入／留存，即滞后指标）相联系。“上线帮助中心”是产出；“减少 15% 的支持工单”是成果。虚荣指标测试：“满意且成功的用户是否可能永远不会执行这个操作？” 如果答案是肯定的，那就是虚荣指标。这是防止陷入构建陷阱的办法。
- 从问题领域着手；区分问题与症状。 功能请求或抱怨（“用户会放弃购物车”）是症状；根本问题（结账流程令人困惑？配送费用太晚才显示？用户不信任支付方式？）才是设计要解决的对象。在着手解决之前，先验证问题真实存在且影响重大。
- 询问过去的行为，而非假设的意图（妈妈测试法）。 问“你会用这个吗？”得到的往往是礼貌性的肯定——一个假阳性。问“请跟我说说你上次遇到这个问题时的情况”，才能得到可验证的信息。询问他们的生活，而不是你的想法；询问过去的具体经历，而不是对未来的假设；留意问题，而不是他们提出的解决方案。他们说完后保持安静——沉默能让真正的洞见浮现。
- 让证据与决策风险相匹配，并辨别信号与噪声。 “真相曲线”：轻量级方法（问卷、访谈、纸面原型）成本低，但会受到你的判断影响；真实环境中的行为最能反映真相。选择能够为这项决策提供足够把握的方法。根据模式，而非紧迫程度筛选请求（在支持、销售和访谈中反复出现的主题，比最吵闹的单个客户更有说服力），并区分阻碍性需求与锦上添花的需求。交叉核对定量信息（发生了什么）与定性信息（为什么）——两者一致是绿灯；若有冲突，则在承诺之前再做一次测试。
- 基于已验证的问题生成解决方案——先提出多个，再进行比较。 问题通过验证后，探索几种截然不同的解决方向，并从可取性 × 可行性 × 商业可持续性几个方面进行比较。每种方向都应能追溯到用户洞见，并作为待测试的假设来提出，而非视为板上钉钉的结论。从请求直接跳到单一功能，是照单全收，而非解决问题，还会导致功能蔓延。
- 以合乎道德且包容的方式开展研究。 获取真正知情的同意（使用通俗易懂的语言、便于撤回、提供细致的录制选择，并留意权力关系）。招募对象不要局限于方便接触的同温层（现有核心用户可能会让你对问题的理解产生偏差）。留意问题界定中的偏见（“用户需要更快的结账流程”已经预设了用户是谁）。注意文化敏感性，为弱势群体提供额外保障；竞争分析只使用真实可信的公开来源。
- 持续与利益相关方保持一致——不让他们措手不及。 将利益相关方交接视为协作检查点，而非揭晓结果：尽早让他们参与研究环节，在解决方案之前先就问题达成一致，公开呈现权衡（影响与投入），并让他们亲眼看到真实用户的困难，而不是只看幻灯片。亲眼见过证据的利益相关方会成为支持者，而非阻碍者。
依赖具体情境的决策（呈现出来，不要自动应用）
逐项说明权衡，并给出与步骤 0 相关的建议；由用户选择。每个问题都对每种方法进行全面调查是错误做法——只获取决策所需的确定性，不要过度投入。
| 决策 | 适用情形 | 避免／调整的情形 | 默认建议 |
|---|---|---|---|
| 问题研究与解决方案测试 | 如果“有人在意吗？”仍未明确，采用问题空间研究方法（访谈、观察、支持日志） | 在验证根本问题之前测试解决方案的可用性 | 先验证问题；确认问题真实存在后，再转向解决方案测试 |
| 定性与定量 | 定性研究（访谈、开放式回答）用于了解原因和早期信号；定量研究（分析、大样本、行为数据）用于了解情况和规模 | 只依赖其中一种——纯定量研究无法揭示原因；纯定性研究则容易追逐声音最大的人 | 两者交叉验证；如果结果相互矛盾，先再做一轮测试，再作决定 |
| 持续轻量研究与定期深入研究 | 每周接触以持续获取信号；针对重大或陌生的决策进行专门深入研究 | 让一次性研究取代持续沟通；或对小型、可逆的决策过度研究 | 保持持续的基线节奏，并针对高风险决策进行深入研究 |
| 自行开展（由 PM／小组主导）与聘请专职研究员 | 由 PM 主导轻量研究，以加快进度并贴近用户 | 复杂、高风险、受监管或涉及弱势群体的研究，这类研究需要专家的严谨性 | 自己培养研究习惯；在严谨性对决策至关重要时引入专家 |
| 承诺前需要多大的确定性 | 根据决策的风险和可逆性（真相曲线）调整证据要求 | 对可逆的微调过度研究；对不可逆且代价高昂的决策研究不足 | 只获取决策所需的确定性；将具体假设测试交给 pm-assumption-testing |
| 应重视谁的声音 | 关注多个来源中的模式；招募有代表性且具包容性的参与者；优先关注阻碍因素，而非锦上添花的需求 | 按反馈数量／紧迫程度或某个声音最大客户的意见分配权重；使用方便但容易形成回音室的样本 | 按模式和代表性分配权重，而非按噪音大小 |
验证结果（编排）
交接时使用各审查视角对应的可安装技能
name。仅在该技能已安装时才调用；如果未安装，本技能的核心内容已包含这些规则，可继续执行，无需因此停下。
完成或修订后，应将内容交给审计视角审查，而不是直接宣布完成。以下是候选视角——请遵循 docs/orchestration-policy.md 中的姿态，或将整个产物交由 pm-product-review 审查。这里，assumption-rigor 是始终相关的视角（自动运行）；其他视角则是可选项，根据产物实际包含的内容决定是否采用。如果用户调用此技能是为了处理某一特定事项，请遵守其范围。
pm-assumption-rigor-audit（自动运行）——是否明确指出并命名了风险最高的假设，而非仅列出容易接受的假设？探索的职责是揭示那些充满信心却未经验证的信念；此项审查会检查这些信念是否被诚实地针对。关于如何设计能消除每项假设的测试，请使用pm-assumption-testing技能。pm-okr-metric-validity-audit（可选——当内容列出结果或成功指标时）——探索所聚焦的产品／业务结果和成功指标，是否是真正的结果（而非虚荣指标或产出数量）、可证伪，且处于团队的影响范围内？pm-prioritization-rigor-audit（可选——当内容对问题／机会进行排序时）——探索在对值得解决的问题／机会排序时，是否以证据为依据并与战略相关，而非形成特性工厂式待办列表或由 HiPPO 拍板？pm-decision-quality-audit（可选——当最终要做出影响重大且难以撤销的构建／不构建决策时）——审查流程而非结果、与可逆性相匹配的审议，以及事前验尸。
组合方式（依据 docs/orchestration-policy.md §9）：本技能负责产出探索的计划及其洞察。测试／实验设计（pm-assumption-testing）由负责该子部分的同级技能处理（请交由它负责）。问题陈述撰写（pm-problem-statement）、人物角色／JTBD（pm-personas-jtbd）、竞争／市场分析（pm-competitive-analysis）、详细优先级框架（pm-prioritization）、路线图制定（pm-roadmap）以及指标／OKR 定义（pm-okrs-kpis）属于后续工作（可建议接下来生成，不要自动生成）。如果审计发现冲突（例如，低成本方法无法真正消除高风险因素），应以当前要做的决策为准：**探索服务于决策——只学习足以做好决策的内容，然后做出决策。**如需从想法完整构建到计划，pm-idea-to-plan 是组合式入口，会在规格说明之前执行这一阶段——它补上了那些急于编写 PRD 的默认做法会跳过的证据步骤。
常见的正确与错误做法
| ❌ 错误做法 | ✅ 正确做法 |
|---|---|
| 只在一开始做一次探索，然后就着手构建 | 将其培养为每周持续进行的习惯；自动化招募流程，让它在忙碌的冲刺周期中也能持续 |
| 以交付的功能衡量成功 | 明确产品成果（行为变化），并将其与业务成果关联起来 |
| 收到功能请求后就立即着手构建 | 找出请求背后的根本问题；先验证问题是否真实存在 |
| “你会用这个吗？”／“你愿意花 20 美元买吗？” | “请讲讲你上一次遇到这种情况的经历”——关注过去的行为，而不是假设 |
| 把声音最大的客户意见当作产品路线图 | 区分反复出现的模式与个别案例，并区分阻碍因素与锦上添花的需求 |
| 只选择定性或定量方法，并单独相信其结果 | 交叉核对两者；如果结果冲突，就在做决定前再进行一次测试 |
| 采用最先想到的解决方案 | 提出多个方案，按照期望度 × 可行性 × 商业价值进行比较，并将它们表述为假设 |
| 只招募现有的重度用户 | 以包容、具有代表性的方式招募；留意问题表述中存在的偏见 |
| 最后才向利益相关者公布发现 | 全程让他们参与；就问题达成一致；展示真实用户遇到的困难 |
| 对可逆的决策研究过多／对不可逆的决策研究不足 | 根据决策风险匹配确定程度；将具体测试交由 assumption-testing 处理 |
| 将计划作为最终方案交付 | 将其交由 assumption-rigor + okr-metric-validity + prioritization-rigor 处理 |