企业官网建设流程全解析

pm-product-discovery 实战指南：用 13 个 Agentic Skills 跑通端到端产品发现流程

【免费下载链接】pm-skillsPM Skills Marketplace: 100+ agentic skills, commands, and plugins — from discovery to strategy, execution, launch, and growth.项目地址: https://gitcode.com/GitHub_Trending/pm/pm-skills

产品发现（Product Discovery）是决定"做什么"的关键环节，也是多数产品团队最容易凭直觉行事、跳过验证的部分。pm-product-discovery是 pm-skills 仓库（PM Skills Marketplace，一个包含 100+ agentic skills、commands 与 plugins 的开源技能市场）中的核心模块之一，它把从创意发散、假设识别、实验设计到客户访谈归纳的完整发现流程，封装为一套可供 AI Agent 直接调用的结构化 Skills 与 Commands。阅读本文后，你将掌握如何用 13 个 Skill 与 5 条 Command 组合出可重复、可验证的产品发现工作流，并理解每条指令背后的方法论文档与源码实现位置。

模块概览：一次发现之旅的完整工具箱

pm-product-discovery模块的定位非常明确：为 PM 提供产品发现相关的技能集合——创意生成（ideation）、实验设计（experiments）、假设验证（assumption testing）、功能优先级排序（feature prioritization）与客户访谈归纳（customer interview synthesis）。

从仓库结构看，该模块采用统一的双层架构：

• Skills（13 个）：每个 Skill 以skills/<skill-name>/SKILL.md组织，是带 YAML front-matter 的标准 Agent 技能文件（含name与description字段，用于 Agent 检索与自动路由）；
• Commands（5 个）：以commands/<command-name>.md组织，是面向交互式会话的斜杠命令（如/discover），用于把多个 Skill 串联成端到端工作流。

技能全集覆盖了产品发现的两个核心场景：现有产品（existing product）的持续发现与全新产品（new product）的初始发现。几乎每个 Skill 都按这两个场景拆分为成对版本（如brainstorm-ideas-existing与brainstorm-ideas-new），这体现了发现方法论中"初始发现 vs 持续发现"的根本分野——前者验证"产品是否应该存在"，后者与交付并行、持续迭代学习。

一、创意生成：三视角发散（PM × Designer × Engineer）

现有产品：持续发现中的头脑风暴（brainstorm-ideas-existing）

该 Skill 面向**产品三人组（Product Trio）**的持续发现场景。其方法论文档引用了 Teresa Torres 的《Continuous Discovery Habits》：PM + Designer + Engineer 应共同参与发现，"最好的想法往往来自工程师"（Best ideas often come from engineers），且发现不是线性的——实验失败需要回环重试。

执行流程为：

1. 确认机会（product、objective、market segment、desired outcomes）；
2. 从三个视角各生成 5 个想法：
   • Product Manager：关注商业价值、战略对齐与客户影响；
   • Product Designer：关注用户体验、可用性与愉悦感；
   • Software Engineer：关注技术可能性、数据杠杆与可扩展方案；
3. 跨视角综合，按战略对齐度、对目标结果的影响、可行性与工作量、与现有方案的差异化，优选出 Top 5；
4. 为每个入选想法给出名称、一句话描述、入选理由与待验证的关键假设。

全新产品：初始发现中的功能发散（brainstorm-ideas-new）

针对尚未验证需求的新产品概念，该 Skill 会先明确初始发现（Initial Discovery）与持续发现（Continuous Discovery）的区别：初始发现聚焦愿景、商业模式与市场验证，回答"产品是否应该存在"；本 Skill 服务于前者。

三视角的侧重点随之调整：

• PM：市场契合、价值创造与竞争优势；
• Designer：用户体验、上手体验（onboarding）与参与度；
• Engineer：技术创新、API 集成与平台能力。

排序时对核心价值交付（是否解决首要问题）、验证速度（能否快速测试）、差异化潜力赋予更高权重。

二、假设识别：魔鬼代言人式压力测试

现有功能：四大风险区（identify-assumptions-existing）

该 Skill 从 PM / Designer / Engineer 三个视角出发，用"为什么这个功能可能失败"的逆向思考，在四个风险区中识别高风险假设：

每个假设需标注：具体可能出错的地方、信心水平（High/Medium/Low）、建议的验证方式。文档特别强调"Be thorough but constructive——目标是强化想法而非扼杀它"。

新产品：八类风险扩展（identify-assumptions-new）

对新产品，该 Skill 在 Teresa Torres 的四类核心产品风险之上，扩展出八类风险——新增 Ethics、Go-to-Market、Strategy & Objectives、Team 四个维度。其方法论依据是："优秀团队会假设至少四分之三的想法不会如预期般表现（Good teams assume at least three-quarters of their ideas won't perform as they hope）"。

八个类别的完整定义（节选自 SKILL.md）：

• Value：能否创造价值？用户是否会持续使用？
• Usability：人们能否搞懂怎么用？能否快速完成上手？是否会增加认知负担？
• Viability：能否售卖/变现/融资？成本是否值得？能否规模化？是否合规？
• Feasibility：现有技术能否做到？集成是否可行？是否高效、可扩展？
• Ethics：我们是否应该做这件事？有无伦理考量？是否会危及客户？
• Go-to-Market（对新产品尤为关键）：能否营销？渠道是否具备？能否说服客户尝试？信息传递与渠道是否匹配？时机是否正确？发布方式是否正确？
• Strategy & Objectives：我们的假设是什么？他人能否复制我们的战略？是否考虑了政治、经济、法律、技术、环境因素？这些是否是最值得解决的问题？
• Team：团队协作能力如何？人是否合适？工具是否齐备？团队能否长期稳定？

三、优先级排序：机会、假设与功能的三层过滤

机会优先，而非功能优先

analyze-feature-requests与prioritize-features两个 Skill 反复强调同一原则：永远不要允许客户设计解决方案；优先排序的是机会（问题），而不是功能（features）。核心评估工具是 Dan Olsen 在《The Lean Product Playbook》中提出的Opportunity Score：

Opportunity Score = Importance × (1 − Satisfaction)

Importance 与 Satisfaction 均归一化到 0–1，因此得分越接近 1，说明"问题越重要且现状越不满意"，越值得优先解决。

功能需求归类与 Top 3 输出（analyze-feature-requests）

面对客户或利益相关方提交的一批功能请求（支持直接读取 spreadsheet、CSV 或文档，结构化数据可生成汇总表），按五步执行：

1. 确认产品目标与期望结果；
2. 将请求按主题（theme）归类并命名；
3. 评估每个主题与目标的战略对齐度；
4. 基于Impact（客户价值与受影响用户数）、Effort（开发与设计资源）、Risk（技术与市场不确定性）、Strategic alignment（与产品愿景的契合）选出 Top 3；
5. 为每个 Top 功能输出：理由（客户需求、战略对齐）、值得考虑的替代方案、高风险假设、以及用最小成本验证假设的方法。

功能积压排序（prioritize-features）

针对功能积压清单，在 Impact / Effort / Risk / Strategic alignment 四维评估后，输出 Top 5 推荐，并附带清晰排序、入选理由、权衡考量以及被降级项及原因。该 Skill 明确推荐了两套打分框架：

• ICE：Impact（Opportunity Score × 客户数）× Confidence（1–10）× Ease（1–10），适合快速给举措打分；
• RICE：(Reach × Impact × Confidence) / Effort，把 Reach 拆分为独立因子，适合更大规模的团队。

框架选择的完整公式与模板见仓库中的 prioritization-frameworks Skill（位于pm-execution模块，发现阶段产出的假设清单可跨模块复用其模板）。

假设优先级：Impact × Risk 矩阵（prioritize-assumptions）

这是从"识别假设"到"设计实验"之间的关键桥梁。对每条假设评估两个维度：

• Impact：验证该假设创造的价值 × 受影响客户数（ICE 中即Opportunity Score × # Customers）；
• Risk：定义为(1 − Confidence) × Effort。

随后放入四象限矩阵，给出明确的处置策略：

需要测试的假设，建议的实验应满足：以最小成本最大化有效学习、测量真实行为而非观点、具备清晰的成功指标与阈值。

四、实验设计：低成本验证的两种剧本

现有产品：原型、A/B 测试与功能桩（brainstorm-experiments-existing）

针对现有产品上需要验证的假设，推荐的方法库包括：

• 原型上的**首次点击测试（first-click testing）**或任务完成测试；
• 功能桩 / 假门测试（feature stubs / fake door tests）；
• 技术探针（technical spikes）；
• 生产环境的A/B 测试（需附带风险缓解策略）；
• **Wizard of Oz（人工模拟）**方案；
• 基于行为的问卷验证（behavioral，而非 opinion-based）。

关键原则：测量真实行为而非用户观点；负责任地测试，不把用户或业务置于风险中；生产环境测试必须解释风险缓解策略；目标是以最小成本获得最大有效学习（maximum validated learning with minimal effort）。

每个实验需按固定结构输出：Assumption（我们相信什么）→ Experiment（具体怎么做）→ Metric（测量什么）→ Success threshold（如果对了预期值是多少）。

新产品：XYZ 假设与预原型（brainstorm-experiments-new）

针对全新产品概念，该 Skill 采用精益创业方法论与 Alberto Savoia（《The Right It》，前 Google 创新专家）的 pretotype 思想：

XYZ 假设的标准形式为："At least X% of Y will do Z"（至少有 X% 的 Y 会做 Z）：

• X%：预期参与的目标市场比例；
• Y：具体的目标市场（如"中大型豪华轿车买家"）；
• Z：他们与产品的互动方式。

推荐 2–3 个 pretotype 实验，例如：

两条核心原则来自 Savoia：

• Skin-in-the-Game：测试支付意愿而非单纯兴趣——真实承诺（时间、金钱、声誉）是唯一可靠的信号；
• YODA（Your Own Data）：通过实验收集自己的数据，而非依赖他人数据（ODP，如市场报告或类比），因为"你的想法的市场，并不关心别人想法的市场"。

五、客户研究：访谈脚本与访谈归纳

结构化访谈脚本（interview-script）

该 Skill 基于《The Mom Test》原则设计——问他们的生活，而不是你的想法。它属于持续发现Stage 1（Explore）的信息来源之一（其他来源包括利益相关方访谈、使用分析、数据分析、问卷、市场趋势、SEO/SEM 分析），强调 PM 必须"无代理地"（without proxies）直接接触用户、利益相关方、工程师与设计师，并再次强调 Product Trio 共同参与。

脚本由四个部分构成：

Opening（2–3 分钟）：介绍自己与目的（学习而非推销）；设定预期"没有对错答案，我们是来向你的经验学习的"；征求录音许可；确认可用时间。

Warm-Up 背景铺垫（5 分钟）：如"讲讲你的角色以及典型的一天/一周是怎样的""你做 [与产品领域相关的活动] 多久了"，目标是与受访者建立融洽关系、理解其背景。

Core Exploration：Jobs to Be Done（15–20 分钟），细分为四组问题：

• 当前情况与行为（过去时、具体实例）："带我走一遍你上次 [做我们正在探索的事情] 的经过，发生了什么？""用了什么工具或方法？""花了多久？还有谁参与？"
• 痛点与挫折（观察而非引导）："最难的部分是什么？""如果能挥动魔法棒，你希望改变什么？""你试过什么方法来解决？结果如何？"
• 期望结果（用他们的话说）："在这个领域，对你来说'好'是什么样的？""你如何判断它运行良好？"
• 支付意愿 / 优先级（skin in the game）："你目前在这上面花多少时间/金钱？""你找过更好的方案吗？找到了什么？""为了解决这个问题，你愿意放弃什么？"

Probing 追问技巧："Tell me more about that"（展开任何话题）、"Why?"（温柔地问 2–3 次，直达根因）、"Can you give me a specific example?"（从观点转向事实）、"What happened next?"（跟随故事）、"How did that make you feel?"（捕捉情绪强度）。

The Mom Test 规则：问他们的生活而非你的想法；问过去而非未来（"你会用 X 吗"毫无价值）；少说多听，争取 80/20 的听/说比例；访谈中绝不推销；留意强烈情绪——它标志着真实的痛苦或愉悦；赞美是噪音——"这听起来很酷！"什么也说明不了。

Wrap-Up（3–5 分钟）："有没有我没问到但你觉得重要的事？""我还应该和谁聊聊这件事？"致谢，分享后续步骤。

该 Skill 还要求附带一份笔记模板（可直接复制使用）：

Participant: [Name / ID] Date: [Date] Key Jobs: [What they're trying to accomplish] Current Solution: [What they use today] Biggest Pain: [Their #1 frustration] Desired Outcome: [What success looks like] Willingness to Pay: [How much they invest / would invest] Surprise Finding: [Something unexpected] Follow-up: [Next steps]

访谈归纳模板（summarize-interview）

把访谈逐字稿（支持文本、PDF、音频转写文件或直接粘贴）转化为结构化总结，聚焦 JTBD、满意度信号与行动项。输出模板要求信息不可用时用 "-" 占位、数值可用定性描述替代（如 "not satisfied"），并且语言要简单到小学毕业生也能看懂。模板字段包括：访谈日期、参与者（姓名与角色）、客户背景、当前解决方案、对当前方案的喜欢之处（JTBD、期望结果、重要性、满意度）、当前方案的问题、关键洞察（意外发现或值得引用的原话）、以及带日期的行动项（如2025-01-15, Paweł Huryn, Follow up with customer about pricing）。

六、结构化发现：机会解决方案树与指标看板

机会解决方案树 OST（opportunity-solution-tree）

基于 Teresa Torres《Continuous Discovery Habits》的 OST 是现代产品发现的骨架——它通过强制团队先绘制机会空间，防止团队过早跳到解决方案。四层结构：

1. 期望结果（Desired Outcome，顶层）：团队追求的单个可测量指标（如"把 7 日留存提升到 40%"），来自 OKR 或产品战略；
2. 机会（Opportunities，第二层）：通过研究发现的客户需求、痛点与渴望——是值得解决的问题而非功能，需从客户视角表述（"我挣扎于……""我希望我能……"），用 Opportunity Score（Importance × (1 − Satisfaction)）排序；
3. 解决方案（Solutions，第三层）：针对每个机会的多种可行方案，由 Product Trio 共同构思，避免"第一个想法陷阱"；
4. 实验（Experiments，底层）：快速廉价的验证手段，用于确认某个方案是否真正解决了机会，优先采用带 skin-in-the-game 的实验而非观点式验证。

关键原则：一次只聚焦一个期望结果；机会而非功能（"永远不要允许客户设计解决方案"）；每个机会至少生成 3 个方案再对比选择；发现不是线性的——实验失败就回环，杀死未获验证的方案、探索新分支；持续而非定期——每周根据访谈、分析与实验更新这棵树。

执行流程为：定义期望结果 → 从研究中映射 3–7 个机会 → 用 Opportunity Score 排序并聚焦 Top 2–3 → 每个机会从三视角生成 3+ 方案 → 为最有前景的方案设计 1–2 个快速实验（明确假设、方法、指标、成功阈值）→ 以清晰的层级格式可视化整棵树。

产品指标看板（metrics-dashboard）

发现阶段的实验与访谈最终都要靠指标来裁决。该 Skill 首先澄清概念层级：Metrics（所有可测量事物）⊃ KPIs（长期追踪的少数关键量化指标）⊃ North Star Metric（单一客户中心 KPI，是业务成功的领先指标）。

好指标的 4 条标准（Ben Yoskovitz《Lean Analytics》）：(1)可理解——创造共同语言；(2)可对比——随时间变化而非快照；(3)比率或速率——比绝对值更有揭示力；(4)能改变行为——黄金法则："如果一个指标不会改变你的行为，它就是坏指标。"

8 种指标类型：Vanity vs Actionable（只有可行动指标能改变行为）、Qualitative vs Quantitative（WHAT vs WHY，两者都要，永远别停止与客户交谈）、Exploratory vs Reporting（探索数据以发现意外洞察）、Lagging vs Leading（领先指标能加速学习周期，如客户投诉可预测流失）。

设计流程分六步：按四层框架组织指标（North Star → Input Metrics（3–5 个驱动北极星的杠杆）→ Health Metrics（护栏）→ Business Metrics（收入、成本、单位经济））→ 用六列表格为每个指标定义（Metric / Definition 精确计算公式与时间窗口 / Data Source / Visualization / Target / Alert Threshold）→ 设计看板布局（北极星居中置顶、输入指标配 sparkline、健康指标与业务指标分栏）→ 设定复盘节奏（日度看运营健康：错误、延迟、关键流程；周度看输入指标与参与趋势；月度看北极星、业务指标与 OKR 进度；季度做战略复盘与指标重校准）→ 定义告警（触发阈值、告警对象与渠道、预期响应时间）→ 按上下文推荐工具（产品分析：Amplitude、Mixpanel、PostHog；SQL 看板：Looker、Metabase、Mode；运营健康：Datadog、Grafana）。

看板布局可直接套用文档中的 ASCII 框架：

┌─────────────────────────────────────────────┐ │ NORTH STAR: [Metric] — [Current Value] │ │ Trend: [↑/↓ X% vs last period] │ ├──────────────────┬──────────────────────────┤ │ Input Metric 1 │ Input Metric 2 │ │ [Sparkline] │ [Sparkline] │ ├──────────────────┼──────────────────────────┤ │ Input Metric 3 │ Input Metric 4 │ │ [Sparkline] │ [Sparkline] │ ├──────────────────┴──────────────────────────┤ │ HEALTH: [Latency] [Error Rate] [NPS] │ ├─────────────────────────────────────────────┤ │ BUSINESS: [MRR] [CAC] [LTV] [Churn] │ └─────────────────────────────────────────────┘

七、五大 Command：把 Skills 串成工作流

除 13 个 Skill 外，模块还提供 5 条斜杠命令（源码见 commands 目录），每条命令的 front-matter 中都声明了argument-hint，方便 Agent 在缺少参数时主动追问：

深度拆解：/discover 全流程指挥链路

/discover是把上述多个 Skill 串联为 15–30 分钟端到端工作流的旗舰命令，其命令源码（discover.md）完整定义了七个步骤：

• Step 1 理解发现上下文：判定是现有产品（持续发现）还是新产品（初始发现），并询问"你在探索什么？已知什么？这次发现要支撑哪些决策？"，接受来自上传文件（研究、PRD、逐字稿、数据）、链接或会话的上下文；
• Step 2 头脑风暴（发散阶段）：调用brainstorm-ideas-existing/new，从三视角生成想法，给出 Top 10 及理由，用户可挑选 3–5 个继续（检查点："这里有 10 个想法，哪些需要压力测试？"）；
• Step 3 识别假设（批判性思考阶段）：调用identify-assumptions-existing/new，按 Value / Usability / Feasibility / Viability（新产品另加 Go-to-Market）识别假设，使用魔鬼代言人多视角分析，汇总成主清单；
• Step 4 假设排序（聚焦阶段）：调用prioritize-assumptions，映射到 Impact × Risk 矩阵，识别"信念之跃"假设（高影响 + 高不确定性），按测试优先级排序并合并可一起测试的相关假设；
• Step 5 实验设计（验证阶段）：调用brainstorm-experiments-existing/new，为每个关键假设设计 1–2 个实验，现有产品用 A/B 测试、假门、原型、用户测试、数据分析，新产品用 XYZ 假设、pretotype、落地页、礼宾式 MVP，并为每个实验附上成功标准、时间线与工作量，按依赖关系和成本排序；
• Step 6 生成发现计划：汇总为一份结构化计划文档（见下方模板），保存为 markdown；
• Step 7 提供后续步骤：询问是否需要"为 Top 想法创建 PRD""设计访谈脚本补充实验""建立指标追踪实验""估算工作量并创建 MVP 用户故事"。

发现计划文档的核心模板（命令源码内嵌）：

## Discovery Plan: [Topic] **Date**: [today] **Product Stage**: [existing/new] **Discovery Question**: [what we're trying to learn] ### Ideas Explored ### Selected Ideas for Validation ### Critical Assumptions | # | Assumption | Category | Impact | Uncertainty | Priority | ### Validation Experiments | # | Tests Assumption | Method | Success Criteria | Effort | Timeline | ### Experiment Details ### Discovery Timeline Week 1: [experiments] Week 2: [experiments] Week 3: [analysis and decision] ### Decision Framework - If [experiment] succeeds → proceed to [next step] - If [experiment] fails → [pivot/kill/investigate further]

命令源码还注明了几条运营要点：工作流耗时 15–30 分钟需提前告知用户；每个检查点用户都可重定向、跳过或深入；发现计划应是活文档，实验运行期间持续更新；新产品优先验证需求渴望（desirability）再谈可行性；现有产品先检查是否有可支撑假设的使用数据。

八、在 Agent 与命令中正确使用本模块

作为 Skill 使用：仓库采用业界标准的 Agent Skills 目录规范，每个技能文件均以 YAML front-matter 声明name与description。description中嵌入了触发场景关键词（如 analyze-feature-requests 的 "Use when reviewing customer feature requests, triaging a backlog, or making prioritization decisions"），Agent 可据此在收到相关任务时自动检索并加载对应技能。调用时，技能内的$ARGUMENTS占位符会被替换为具体任务描述（如产品、目标细分市场或功能想法），用户提供的研究文件、PRD、访谈逐字稿等可作为附加上下文一并传入。

作为 Command 使用：在交互式会话中直接输入斜杠命令（如/discover Smart notification system for our project management tool），可省略参数直接触发命令自行追问。

通用约定：多数 Skill 的指令都要求"Think step by step"并"Save as markdown"，产出应保存为用户工作区中的 Markdown 文档，便于后续跨模块衔接（如将验证过的想法输入 write-prd 或 plan-okrs）。

九、方法论溯源与项目信息

本模块的所有方法论均可追溯到公开著作：Teresa Torres《Continuous Discovery Habits》（Product Trio、OST、四类核心产品风险）、Dan Olsen《The Lean Product Playbook》（Opportunity Score）、Alberto Savoia《The Right It》（XYZ 假设、pretotype、skin-in-the-game 与 YODA）、Ben Yoskovitz《Lean Analytics》（好指标 4 标准）以及《The Mom Test》（访谈原则）。各 Skill 底部的 Further Reading 均链接到作者 Paweł Huryn 的 The Product Compass 系列（此处不展开外部链接）。

项目信息：pm-product-discovery模块由 Paweł Huryn 编写，随 pm-skills 仓库以MIT 协议开源。本模块与仓库中其他模块（如 pm-execution 的优先排序框架、pm-product-strategy 的战略输入）协同，共同构成从发现到策略、执行、发布与增长的完整 PM 技能生态。验证本仓库插件/技能文件结构合规性可参考仓库根目录的 validate_plugins.py 与 AGENTS.md。

【免费下载链接】pm-skillsPM Skills Marketplace: 100+ agentic skills, commands, and plugins — from discovery to strategy, execution, launch, and growth.项目地址: https://gitcode.com/GitHub_Trending/pm/pm-skills