wehub-skill-sync
18 KiB
18 KiB
name, description, intent, type, theme, best_for, scenarios, estimated_time
| name | description | intent | type | theme | best_for | scenarios | estimated_time | |||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| discovery-process | 运行从问题假设到验证解决方案的完整探索周期。当团队需要一条结构化路径，完成问题框架、客户访谈、综合分析和实验验证时使用。 | 指导产品经理完成一个完整的探索周期——从最初的问题假设到经过验证的解决方案——通过将问题框架、客户访谈、综合分析以及实验技能编排成一个结构化流程。使用此流程系统性地探索问题空间，验证假设，并在投入全面开发之前建立信心——避免"先造出来，用户自然就来"的思维，确保你正在解决真实的客户问题。 | workflow | discovery-research |
|
|
30-60 分钟 |
目的
指导产品经理完成一个完整的探索周期——从最初的问题假设到经过验证的解决方案——通过将问题框架、客户访谈、综合分析以及实验技能编排成一个结构化流程。使用此流程系统性地探索问题空间，验证假设，并在投入全面开发之前建立信心——避免"先造出来，用户自然就来"的思维，确保你正在解决真实的客户问题。
这不是一次性的调研项目——它是一种与交付并行运行的持续探索实践，通常每季度进行 1-2 个探索周期。
关键概念
什么是探索流程？
探索流程（Teresa Torres、Marty Cagan）是一种结构化的方法，用于在构建之前探索问题空间并验证解决方案。它包含以下步骤：
- 定义问题 —— 明确你在研究什么以及为什么
- 开展调研 —— 收集定性和定量证据
- 综合分析 —— 识别模式、痛点和机会
- 生成解决方案 —— 探索多种解决方案选项
- 验证解决方案 —— 通过实验测试假设
- 决策与记录 —— 决定构建、转向还是终止
为什么这样做有效
- 降低产品决策风险： 在昂贵的开发之前测试假设
- 以客户为中心： 将决策建立在真实的客户问题上，而非内部意见
- 迭代推进： 通过小实验逐步建立信心
- 快速学习： 尽早发现"不可行"信号，避免无效投入
反模式（这不代表什么）
- 不是瀑布式调研： 探索是持续进行的，而不是开发前只做一次
- 不是用户测试： 探索验证问题；测试验证解决方案
- 不能替代交付： 探索为交付提供信息，但不替代交付
何时使用
- 探索新产品/功能领域
- 调查留存率或流失问题
- 在路线图承诺之前验证战略举措
- 持续探索（每周客户接触点）
何时不该使用
- 针对已充分理解的问题（应转向执行）
- 当利益相关者已决定解决方案时（先解决对齐问题）
- 用于战术性的 bug 修复或技术债务（不需要探索）
引导式信息来源
当以引导式对话的方式运行此工作流时，请使用 workshop-facilitation 作为交互协议。
该协议定义了：
- 会话预告 + 进入模式（引导式、背景信息倾泻、最佳推测）
- 每次一个问题，使用通俗语言提问
- 进度标签（例如：Context Qx/8 和 Scoring Qx/5）
- 中断处理及暂停/恢复行为
- 决策点处的编号建议
- 常规问题提供编号快速选择选项（必要时包含"其他（请注明）"）
本文档定义了工作流程序列和领域特定的输出。如存在冲突，以本文档的工作流程逻辑为准。
应用
完整填空结构请使用 template.md。
本工作流编排 6 个阶段，持续 2-4 周，使用多个组件技能和交互式技能。
阶段 1：定义问题（第 1-2 天）
目标： 明确你在研究什么、谁受影响以及成功的标准。
活动
1. 运行问题框架画布
- 使用：
skills/problem-framing-canvas/SKILL.md（交互式 - MITRE） - 参与人： PM、设计、技术负责人
- 时长： 120 分钟
- 产出： 问题陈述 + "我们可以如何"问题
2. 创建正式问题陈述
- 使用：
skills/problem-statement/SKILL.md（组件） - 参与人： PM
- 时长： 30 分钟
- 产出： 包含假设的结构化问题陈述
3. 定义原始人物画像（如需要）
- 使用：
skills/proto-persona/SKILL.md（组件） - 时机： 当目标客户群体不明确时
- 时长： 60 分钟
- 产出： 基于假设的人物画像
4. 映射待办任务（如需要）
- 使用：
skills/jobs-to-be-done/SKILL.md（组件） - 时机： 当客户动机不明确时
- 时长： 60 分钟
- 产出： JTBD 陈述
阶段 1 的产出
- 问题假设： "我们相信[人物画像]在[问题]上存在困难，原因是[根本原因]，导致[后果]。"
- 研究问题： 3-5 个需要通过探索来回答的问题
- 成功标准： 什么能验证/否证这个问题
决策点 1：我们是否有足够的背景信息来开始调研？
如果 是： 进入阶段 2（调研规划）
如果 否： 先收集现有数据：
- 查看客服工单、流失调查、NPS 反馈
- 分析产品数据（流失点、使用模式）
- 查看竞品研究、市场趋势
- 时间影响： +2-3 天
阶段 2：调研规划（第 3 天）
目标： 设计调研方法、招募参与者、准备访谈提纲。
活动
1. 准备探索访谈
- 使用：
skills/discovery-interview-prep/SKILL.md（交互式） - 参与人： PM、设计
- 时长： 90 分钟
- 产出： 包含方法论、问题列表、需避免偏见的访谈计划
2. 招募参与者
- 目标： 每个探索周期 5-10 名客户（Teresa Torres：持续探索 = 每周 1 次访谈）
- 分层： 聚焦阶段 1 中定义的人物画像
- 招募渠道：
- 现有客户（邮件、应用内提示）
- 流失客户（退出访谈）
- 主动外联（LinkedIn、社区）
- 激励： 50-100 美元礼品卡或产品积分
- 时长： 2-3 天（与阶段 1 并行）
3. 安排访谈
- 形式： 每次访谈 45-60 分钟（30-40 分钟对话 + 缓冲）
- 时间安排： 分散在 1-2 周内
- 录制： 征得同意，录制用于综合分析
阶段 2 的产出
- 访谈提纲： 5-7 个开放式问题（Mom Test 风格）
- 参与者名单： 5-10 场已安排的访谈
- 综合分析计划： 如何捕捉和分析洞察
阶段 3：开展调研（第 1-2 周）
目标： 通过客户访谈收集定性证据。
活动
1. 进行探索访谈
- 方法论： 来自
skills/discovery-interview-prep/SKILL.md（问题验证、JTBD、转换访谈等） - 参与人： PM + 可选观察员（设计、工程）
- 时长： 1-2 周内完成 5-10 场访谈
- 重点领域：
- 过往行为（而非假设性问题）："请告诉我上次你[遇到这个问题]的情况"
- 变通方案："你目前是怎么处理这个问题的？"
- 尝试过的替代方案："你试过其他解决方案吗？为什么停止了？"
- 痛点强度："这花了你多少时间/金钱？"
2. 做结构化笔记
- 模板：
- 参与者：[姓名、角色、公司规模]
- 背景：[他们在何时/何地遇到问题]
- 行为：[他们做了什么，逐步描述]
- 痛点：[挫败感、阻碍]
- 变通方案：[当前解决方案]
- 引述：[客户原话]
- 洞察：[模式、意外发现]
3. 查看客服工单与分析（并行）
- 客服工单： 按主题归类（onboarding、功能混淆、bug）
- 分析： 识别流失点、功能使用情况、同群组行为
- 调查： 查看 NPS 评论、退出调查、功能请求
阶段 3 的产出
- 访谈记录： 录制的会议 + 详细笔记
- 客服工单主题： 按频率排列的前 10 大问题
- 分析洞察： 关于行为的量化数据（例如："60% 的用户在步骤 3 放弃 onboarding"）
决策点 2：我们是否达到了饱和？
饱和 = 相同痛点出现在 3 场以上访谈中，无新洞察出现
如果 是（5-7 场访谈后饱和）： 进入阶段 4（综合分析）
如果 否（仍在发现新内容）： 再安排 3-5 场访谈
- 时间影响： +1 周
阶段 4：综合分析（第 2 周末）
目标： 识别模式、确定痛点优先级、映射机会。
活动
1. 亲和图（主题分析）
- 方法：
- 将每条洞察/引述写在便利贴上
- 按主题分组（例如："onboarding 困惑"、"定价异议"、"移动端访问"）
- 统计频率（多少客户提到了每个主题）
- 参与人： PM、设计，可选工程
- 时长： 90-120 分钟
- 产出： 带有频率统计的主题聚类
2. 创建客户旅程地图（可选）
- 使用：
skills/customer-journey-mapping-workshop/SKILL.md（交互式） - 时机： 当痛点跨越多个阶段时（发现、试用、购买、使用、支持）
- 时长： 90 分钟
- 产出： 按影响力排序的机会点旅程地图
3. 确定痛点优先级
- 标准：
- 频率： 有多少客户提到了这一点？
- 强度： 这个痛点有多大？（浪费时间、金钱损失、情绪沮丧）
- 战略契合度： 解决这个问题是否与业务目标一致？
- 方法： 对每个痛点按频率、强度、战略契合度评分（1-5）
- 产出： 需要解决的前 3-5 个痛点的排序列表
4. 更新问题陈述
- 使用：
skills/problem-statement/SKILL.md（组件） - 基于调研进行修正： 初始假设是否成立？根据需要调整。
- 产出： 经过验证的问题陈述
阶段 4 的产出
- 亲和图： 带有频率统计的主题
- 前 3-5 个痛点： 按频率 × 强度 × 战略契合度排序
- 客户引述： 每个痛点 3-5 条原话引述
- 经过验证的问题陈述： 基于证据修正
阶段 5：生成与验证解决方案（第 3 周）
目标： 探索解决方案选项、设计实验、验证假设。
活动
1. 生成机会解决方案树
- 使用：
skills/opportunity-solution-tree/SKILL.md（交互式） - 输入： 阶段 4 的前 3 个痛点
- 参与人： PM、设计、技术负责人
- 时长： 90 分钟
- 产出： 3 个机会，每个机会 3 个解决方案，POC 建议
替代方案：使用精益用户体验画布
- 使用：
skills/lean-ux-canvas/SKILL.md（交互式） - 时机： 倾向于使用基于假设的方法而非 OST
- 产出： 需要测试的假设、最小实验方案
2. 设计实验
- 对每个解决方案： 定义"做最少的工作，学习下一件最重要的事，是什么？"
- 实验类型：
- 白手套测试： 手动向 10 名客户交付解决方案，观察
- 原型测试： 可点击的线框图，对 10 名用户进行可用性测试
- 落地页测试： 假门测试（展示功能，衡量兴趣）
- A/B 测试： 构建最小版本，对 50% 的用户进行测试
- 成功标准： 什么指标/行为能验证假设？
3. 运行实验
- 时间线： 每个实验 1-2 周
- 参与人： PM + 设计（用于原型）、工程（用于 A/B 测试）
- 产出： 定量和定性验证数据
阶段 5 的产出
- 解决方案选项： 3-9 个解决方案（每个机会 3 个）
- 实验结果： 假设是否得到验证或否证？
- 客户反馈： 对原型/概念的定性反应
决策点 3：实验是否验证了解决方案？
如果 是（已验证）： 进入阶段 6（决策与记录）
如果 否（被否证）：
- 转向下一个解决方案选项
- 用调整后的方法重新运行实验
- 时间影响： +1-2 周
阶段 6：决策与记录（第 3-4 周末）
目标： 决定是否构建、记录决策、向利益相关者沟通。
活动
1. 做出执行/终止决策
- 标准：
- 问题已验证？（阶段 3-4）
- 解决方案已验证？（阶段 5）
- 战略契合？（与业务目标一致）
- 可行性？（工程能力、技术复杂度）
- 决策：
- 执行： 纳入路线图，编写史诗/用户故事
- 转向： 探索替代方案
- 终止： 降低优先级，现在不值得解决
2. 定义史诗假设（如果执行）
- 使用：
skills/epic-hypothesis/SKILL.md（组件） - 参与人： PM
- 时长： 每个史诗 60 分钟
- 产出： 包含成功标准的史诗假设陈述
3. 编写产品需求文档（如果执行）
- 使用：
skills/prd-development/SKILL.md（工作流） - 参与人： PM
- 时长： 1-2 天
- 产出： 包含问题、解决方案、成功指标的结构化 PRD
4. 沟通发现
- 形式： 30 分钟的汇报，内容包括：
- 问题验证（阶段 3-4 的洞察）
- 解决方案验证（阶段 5 的实验）
- 建议（执行/转向/终止）
- 参与人： 高管、产品领导层、关键利益相关者
- 产出： 对下一步行动达成共识
阶段 6 的产出
- 决策： 执行、转向或终止
- 史诗假设：（如果执行）可测试的史诗陈述
- 产品需求文档：（如果执行）正式的产品需求文档
- 利益相关者对齐： 高管对建议的支持
完整工作流：端到端摘要
第 1 周：
├─ 第 1-2 天：定义问题
│ ├─ skills/problem-framing-canvas/SKILL.md（120 分钟）
│ ├─ skills/problem-statement/SKILL.md（30 分钟）
│ └─ [可选] skills/proto-persona/SKILL.md、skills/jobs-to-be-done/SKILL.md
│
├─ 第 3 天：调研规划
│ ├─ skills/discovery-interview-prep/SKILL.md（90 分钟）
│ ├─ 招募参与者（2-3 天）
│ └─ 安排 5-10 场访谈
│
└─ 第 4-5 天：开展调研（开始）
└─ 前 2-3 场客户访谈
第 2 周：
├─ 第 1-3 天：开展调研（继续）
│ └─ 剩余的客户访谈（3-7 场）
│
├─ 第 4-5 天：综合分析
│ ├─ 亲和图（120 分钟）
│ ├─ [可选] skills/customer-journey-mapping-workshop/SKILL.md（90 分钟）
│ ├─ 确定痛点优先级
│ └─ 更新问题陈述
│
└─ 决策：是否达到饱和？（如否，+1 周更多访谈）
第 3 周：
├─ 第 1-2 天：生成与验证解决方案
│ ├─ skills/opportunity-solution-tree/SKILL.md（90 分钟）
│ └─ 设计实验
│
├─ 第 3-5 天：运行实验
│ ├─ 白手套测试、原型测试或 A/B 测试
│ └─ 收集验证数据
│
└─ 决策：是否已验证？（如否，转向下一个解决方案，+1-2 周）
第 4 周：
└─ 决策与记录
├─ 做出执行/终止决策
├─ [如果执行] skills/epic-hypothesis/SKILL.md（每个史诗 60 分钟）
├─ [如果执行] skills/prd-development/SKILL.md（1-2 天）
└─ 沟通发现（30 分钟汇报）
总时间投入：
- 快速通道： 3 周（5 场访谈，1 个实验）
- 典型周期： 4 周（7-10 场访谈，1-2 个实验）
- 全面周期： 6-8 周（10 场以上访谈，多轮实验）
示例
完整探索流程示例请参见 examples/sample.md。
微型示例摘录：
**问题：** 因术语导致的 onboarding 流失
**洞察：** 6/10 的用户在步骤 3 退出
**决策：** 采用引导式检查清单实验
常见陷阱
陷阱 1：跳过客户访谈
症状： 仅依赖分析和客服工单，没有定性调研
后果： 错过了行为背后的"为什么"，构建了错误的解决方案
修正： 每个探索周期务必访谈 5-10 名客户（即使你已有数据）
陷阱 2：提出诱导性问题
症状： "如果我们构建了[功能 X]，你会使用吗？"
后果： 确认偏误，客户出于礼貌回答"会"
修正： 使用 skills/discovery-interview-prep/SKILL.md 中的 Mom Test 问题（聚焦过往行为）
陷阱 3：未达到饱和
症状： 只访谈 2-3 名客户就宣布探索完成
后果： 样本量太小，不具备代表性
修正： 继续访谈直到相同模式在 3 名以上客户中出现（通常至少 5-7 场访谈）
陷阱 4：分析瘫痪
症状： 花 6 周综合分析洞察，从未进入解决方案阶段
后果： 没有交付，团队失去动力
修正： 将探索限定在 3-4 周内；阶段 6 结束后，转入执行
陷阱 5：把探索当成一次性活动
症状： 在构建之前做一次探索，然后停止
后果： 错失客户需求的变化和市场变动
修正： 持续探索（Teresa Torres）：每周 1 场客户访谈，持续进行
参考
相关技能（由本工作流编排）
阶段 1：
skills/problem-framing-canvas/SKILL.md（交互式）skills/problem-statement/SKILL.md（组件）skills/proto-persona/SKILL.md（组件，可选）skills/jobs-to-be-done/SKILL.md（组件，可选）
阶段 2：
skills/discovery-interview-prep/SKILL.md（交互式）
阶段 4：
skills/customer-journey-mapping-workshop/SKILL.md（交互式，可选）
阶段 5：
skills/opportunity-solution-tree/SKILL.md（交互式）skills/lean-ux-canvas/SKILL.md（交互式，替代方案）
阶段 6：
skills/epic-hypothesis/SKILL.md（组件）skills/prd-development/SKILL.md（工作流）
外部框架
- Teresa Torres，《持续探索习惯》（Continuous Discovery Habits，2021）—— 每周客户接触点、OST 框架
- Rob Fitzpatrick，《Mom 测试》（The Mom Test，2013）—— 如何提出好的访谈问题
- Marty Cagan，《启示录》（Inspired，2017）—— 产品探索原则
Dean 的作品
- Productside Blueprint —— 战略性探索流程
- [如果 Dean 有探索相关资源，请在此添加链接]
技能类型： 工作流
建议文件名： discovery-process.md
建议放置路径： /skills/workflows/
依赖项： 在 6 个阶段中编排 10 个以上组件技能和交互式技能