📚 Product Discovery Risk Assessment — 产品发现风险评估
v1.0.0评估产品风险并决定是否构建。用于开始产品发现、评估新功能或产品创意、确定首先验证哪些风险、在原型设计和测试方法之间选择，或回答「我们应该构建这个吗？」将任何想法映射到4大风险分类（价值风险、可用性风险、技术可行性风险、商业可行性风险）加上伦理风险，按优先级排序发现活动，并为每种风险选择合适的技巧类别。
by 详细分析 ▾
运行时依赖
版本
- Product Discovery Risk Assessment 技能的首次发布。 - 根据价值、可用性、技术可行性、商业可行性和伦理风险评估产品创意。 - 帮助确定首先验证哪些风险，并为每种风险选择正确的发现技巧类别。 - 专为产品发现开始、功能评估和计划发现冲刺而设计。 - 作为中心枢纽技能；将用户引导至特定技巧的下游技能。
安装命令
点击复制技能文档
何时使用
当您有一个产品创意、功能提案或计划，并且需要决定时，请应用此技能：
- 存在哪些风险，每种风险的严重程度如何
- 部署哪些发现技巧类别
- 以什么顺序运行发现活动
这是产品发现的枢纽技能。在任何特定技巧的发现工作之前运行它。下游技巧（框架技巧选择、原型选择、价值测试、可行性测试）消耗此技能产生的结构化风险评估。
不要使用此技能来执行特定的发现技巧——它产生的是一个计划，而不是技巧本身。
上下文和输入收集
在运行评估之前，收集：
- 产品创意描述——提议的解决方案或功能是什么？至少一段。
- 目标客户/用户——谁会使用它？购买者与用户的区别很重要。
- 业务背景——这如何符合公司的收入模式、品牌、法律环境？
- 团队背景——团队有哪些工程、设计和产品能力？
- 阶段——新产品、现有产品的新功能，还是现有功能的改进？
如果存在文档（简报、PRD、机会评估），请阅读它。如果没有，请在继续之前要求用户描述这个创意。
流程
步骤 1：按阶段和新颖性对创意进行分类
确定：这是一个新产品、现有产品的新功能，还是现有功能的改进？
原因：阶段和新颖性决定哪些风险最紧迫。新产品承担最大的价值风险（客户尚未选择购买）。对现有功能的改进价值风险较低，但可用性风险更高（现有用户有既定的心理模型需要打破）。
- 新产品 → 将所有 4 种风险视为可能 HIGH，直到有证据表明并非如此
- 新功能 → 价值和可用性风险是主要的；可行性和可行性可能是中等
- 改进 → 可用性风险通常占主导；价值风险较低但不为零
步骤 2：对 4 个核心风险进行评分
对于每个风险，分配严重程度：低 / 中 / 高 / 未知。
风险 1 — 价值风险 问题：客户会选择购买或使用这个吗？ 如果以下情况，评分为高：
- 没有客户想要这个的直接证据
- 客户没有要求这个（注意：这是预期的——客户通常在看到之前无法表达他们想要什么）
- 存在解决相同底层问题的竞争替代方案
- 价值主张取决于行为改变
如果以下情况，评分为低：
- 现有客户明确要求此功能，并且您已验证他们会付费或切换使用它
- A/B 测试或需求信号已经存在
原因：价值风险一直是最难解决的风险，也是产品失败的最常见原因。大多数发现时间必须分配在这里。有可用性问题的产品可以存活；没有价值的产品不能存活。
风险 2 — 可用性风险 问题：用户能否在没有帮助的情况下弄清楚如何使用这个？ 如果以下情况，评分为高：
- 工作流程是多步骤的或需要用户判断
- 目标用户不是问题领域的技术专家
- 交互设计是新颖的（新的 UI 模式、语音、手势）
- 错误代价高昂或难以逆转
如果以下情况，评分为低：
- 工作流程是单一且易于理解的操作
- 用户是已经熟悉类似工具的 power user
原因：即使技术正确的产品，如果用户无法弄清楚，也会失败。设计技能和工程技能不可互换——而且并非每个团队都有足够的设计能力。必须用真实用户验证可用性，而不是内部团队成员。
风险 3 — 可行性风险 问题：团队是否可以在可接受的时间、成本和技术约束下构建这个？ 如果以下情况，评分为高：
- 解决方案需要团队未使用过的技术
- 存在显著的规模或性能要求
- 第三方集成或数据来源未经证实
- 涉及质量阈值不确定的 ML/AI 组件
如果以下情况，评分为低：
- 解决方案使用成熟的、生产环境中的技术
- 工程已经构建了类似的组件
原因：可行性必须在发现期间验证——不是在冲刺计划期间。如果工程师在冲刺计划时才第一次看到这个想法，团队就已经失败了。在发现期间尽早让工程师参与也能改善解决方案本身，并实现共享学习。
风险 4 — 商业可行性风险 问题：这个解决方案在所有相关维度上是否对业务有效？ 如果以下任何一项不确定，评分为高：
- 财务：我们是否有能力构建和提供它？定价模式是否有效？
- 销售：销售团队能卖掉它吗？
- 营销：它是否符合品牌和进入市场策略？
- 法律：是否存在监管、隐私或合同约束？
- 业务发展：它对现有合作伙伴有效吗？
- 高管：高层领导会支持吗？
如果解决方案明显在当前商业模式、现有合同和既定的进入市场策略范围内，则评分为低。
原因：商业可行性必须在发现期间验证——不是在产品构建之后。发现法律或财务障碍会摧毁团队士气并浪费工程投资。产品经理负责这个风险，而不仅仅是法律或财务。
步骤 3：评估伦理风险（第五个风险）
伦理风险与商业可行性不同。问：
- 即使这个解决方案在技术上合法并满足业务目标，是否可能对用户、第三方或环境造成伤害？
- 解决方案是否以产生有害副作用的方式优化业务指标（参与度、增长、货币化）？
如果对任一问题回答是：标记为存在伦理风险并注明具体关切。
当存在伦理风险时，探索解决相同底层问题而不产生有害副作用的替代解决方案。
原因：技术能力并不意味着构建的伦理许可。解决方案可以合法地满足业务目标，同时伤害用户。产品经理的角色是识别伦理风险并向领导层提出潜在的替代解决方案——不是监督，而是促成知情决策。
步骤 4：将风险映射到技巧类别
对于每个评分为中或高的风险，选择适当的技巧类别。此映射告诉您应该运行哪类发现活动。
| 风险 | 技巧类别 | 目的 |
|---|---|---|
| 价值（高） | 框架 → 然后 价值测试 | 首先澄清底层问题；然后验证需求 |
| 价值（中） | 价值测试 | 验证客户是否会选择这个 |
| 可用性（高/中） | 原型 → 然后 可用性测试 | 构建原型；用真实用户测试 |
| 可行性（高/中） | 可行性测试 | 工程主导的可行性 spike 或概念验证 |
| 商业可行性（高/中） | 商业可行性测试 | 法律、财务、销售、营销的利益相关者审查 |
| 存在伦理风险 | 框架 + 利益相关者审查 | 在承诺解决方案之前探索替代方案 |
| 所有风险都存在 | 首先使用 规划 技巧 | 使用规划技巧识别最大挑战，然后再承诺顺序 |
- 框架 — 在承诺解决方案之前澄清底层问题。用于问题不明确或收到没有清晰问题陈述的解决方案时。
- 规划 — 识别整个发现工作中最大的挑战，并结构化如何攻击它们。用于同时存在多个重大风险时。
- 构思 — 生成针对特定问题的有希望的解决方案。用于问题已经很好地框架化且当前解决方案集不足时。
- 原型 — 创建用于测试的解决方案表示。存在四种原型类型（详见下游技能：discovery-prototype-selection）。用于可用性和价值测试之前。
- 测试 — 验证特定风险。四个子类别：
原因：不同风险需要不同技巧和不同团队成员领导。将可用性测试应用于价值问题会浪费时间。将需求验证应用于可行性问题不会产生有用的信号。此映射防止风险类型和技巧类型之间的不匹配。
步骤 5：排序发现活动
应用此排序逻辑：
- 首先框架 — 如果价值风险高且底层问题尚未明确定义
- 价值和可用性验证优先于可行性 — 在有证据表明客户会使用该解决方案之前，不要在可行性 spike 上投入工程时间
- 可行性优先于深度原型 — 如果可行性风险高，在构建高保真原型之前验证技术可行性
- 商业可行性贯穿始终 — 不要将可行性利益相关者审查推迟到最后；尽早提出法律、财务和销售问题
- 伦理审查与框架同时进行 — 在承诺重大发现工作之前标记并解决伦理风险
例外：如果可行性风险如此之高以至于无论价值如何都使该想法在技术上不可能实现，请首先解决可行性。
原因：首先验证价值和可用性可以防止在客户不会使用的解决方案上进行昂贵的工程可行性工作。排序反映了犯错成本：价值失败很容易发现；构建后的工程失败代价高昂。
步骤 6：生成风险评估文档
编写结构化输出（参见输出部分），包括：
- 所有 4 个核心风险的风险评分 + 伦理标记
- 每个风险选择的技巧类别
- 推荐的发现顺序
- 迭代基准校准
输入
| 输入 | 必需 | 描述 |
|---|---|---|
| 产品创意 / 功能描述 | 是 | 提议的内容 |
| 目标客户/用户描述 | 是 | 谁会使用它，谁会购买它 |
| 商业模式背景 | 是 | 收入模式、定价、分销 |
| 团队能力摘要 | 推荐 | 工程、设计和 PM 能力 |
| 现有研究或需求信号 | 可选 | 任何之前的客户访谈、调查或分析 |
输出
输出模板：产品风险评估
# 产品风险评估：[产品/功能名称]创意摘要
[一段描述]阶段分类
[ ] 新产品
[ ] 新功能
[ ] 现有功能改进风险评分
风险 评分 证据/理由 价值 高/中/低/未知 [原因] 可用性 高/中/低/未知 [原因] 可行性 高/中/低/未知 [原因] 商业可行性 高/中/低/未知 [原因] 伦理 存在/不存在 [如果存在：具体关切]
技巧类别映射
风险 技巧类别 主导 优先级 [风险] [类别] PM/设计师/工程师 1-4
推荐的发现顺序
- [第一个活动——技巧类别，谁主导，它回答什么问题]
- [第二个活动...]
- ...
迭代基准
目标：每周 10-20 次发现迭代。每次迭代 = 测试一个新想法或方法。
与基准的当前差距：[如果团队不熟悉现代发现技巧，请注明]下游技能依赖
- discovery-framing-technique-selection：[需要是/否——价值风险高]
- discovery-prototype-selection：[需要是/否——可用性风险高/中]
- value-testing-technique-selection：[需要是/否——价值风险中/高]
- business-viability-stakeholder-testing：[需要是/否——可行性风险中/高]
- customer-discovery-program：[需要是/否——新产品且客户未知]
关键原则
这些来自结构化构建前验证（产品发现）的 10 个原则管理着如何使用此评估：
- 客户无法指定要构建什么——您的工作是解决底层问题，而不是按字面意思实现客户请求。客户不知道什么是可能的；他们无法描述他们没见过的解决方案。
- 价值是最难的问题——没有有说服力的价值，其他任何质量都不重要。在这里花费大部分发现时间。
- 用户体验比看起来更难——想出好的用户体验通常比工程更难、更关键。并非每个团队都有足够的设计技能。
- 功能、设计和技术相互交织——不是顺序的。技术使设计成为可能；设计使功能成为可能。这就是为什么产品经理、设计师和工程师必须近距离工作。
- 预期大多数想法会失败——以许多（可能是大多数）想法不会成功——或者需要几次迭代的假设来进行发现。这不是失败；这是发现过程正常工作。
- 用真实用户验证，而不是代理——内部团队、友好用户和客户研究不能替代在构建前对真实目标用户测试实际想法。
- 快速、廉价地验证——发现迭代应该至少比交付迭代少一个数量级的时间和精力。目标：每周 10-20 次发现迭代。
- 在发现期间验证可行性——工程师必须在发现期间看到想法，而不是在冲刺计划期间。尽早让工程师参与发现可以改善解决方案并实现共享学习。
- 在发现期间验证商业可行性——法律、财务、销售和高管约束必须在构建之前提出，而不是之后。
- 共享学习胜过分工——团队一起学习。关于客户痛点、失败想法和成功方法的共享上下文创建了一个赋能的团队（而不是功能执行团队）。
示例
示例 1：新的 AI 驱动的搜索功能（SaaS B2B）
场景：一家 B2B SaaS 公司想要添加 AI 驱动的语义搜索来替换他们现有的关键词搜索。工程提议使用第三方 LLM API。
风险评估：
- 价值：中 — 现有客户抱怨过搜索质量，但不清楚他们是否会为语义搜索支付更多费用或改变使用模式
- 可用性：中 — 语义搜索的行为与关键词搜索不同；当结果不完全匹配他们的字面查询时，用户可能会感到困惑
- 可行性：高 — 第三方 LLM 集成在团队数据规模上未经证实；延迟和每次查询成本未知
- 商业可行性：中 — LLM API 成本可能影响毛利率；法律担心客户数据被发送到第三方
- 伦理：不存在
技巧顺序：
- 价值测试（定性）— 5 次客户访谈：他们是否看到足够的价值来改变搜索行为？
- 可行性测试 — 工程 spike：LLM API 能否在规模上满足延迟和成本要求？
- 商业可行性测试 — 法律审查与 LLM 提供商的数据处理协议；财务模型对每次查询成本的影响
- 原型 + 可用性测试 — 如果价值和可行性通过，构建低保真原型并对 5 个目标用户进行可用性测试
示例 2：移动端入职重新设计（消费者应用）
场景：一个消费者应用想要重新设计其 7 步入职流程以减少流失。当前完成率是 34%。
风险评估：
- 价值：低 — 该应用已经有经过验证的需求；入职改进是留存工作，而不是价值创造
- 可用性：高 — 66% 的用户正在流失，这是严重可用性失败的直接证据
- 可行性：低 — 标准移动 UI 组件；不需要新技术
- 商业可行性：低 — 入职设计没有法律、财务或销售约束
- 伦理：不存在
技巧顺序：
- 框架 — 审查现有分析以确定 7 步中哪一步流失最高（在设计解决方案之前澄清具体问题）
- 原型 — 构建重新设计流程的 2-3 个原型变体
- 可用性测试 — 对每个变体进行由主持人引导的可用性测试，每个变体 5 个目标用户
- 价值测试（定量）— A/B 测试获胜变体以获得完成率的统计显著性
示例 3：新的货币化功能（消费者平台）
场景：一个消费者平台想要引入一个「boost」功能，用户付费以增加其内容的可见性。
风险评估：
- 价值：高 — 没有证据表明用户会付费；为可见性付费对这个用户群来说是一种新行为
- 可用性：低 — 简单的支付和切换交互
- 可行性：低 — 支付基础设施已经存在
- 商业可行性：中 — 收入模式有效，但营销担心品牌认知；法律需要审查广告法规
- 伦理：存在 — 为付费用户提升可见性可能会损害非付费用户的覆盖范围，并破坏对有机内容质量的信任
技巧顺序：
- 框架 — 澄清底层业务问题（收入增长）并探索不创造付费获胜动态的替代解决方案
- 商业可行性测试 — 营销品牌审查 + 法律广告法规审查
- 价值测试（需求）— 如果可以减轻伦理风险，在构建之前用目标用户验证付费意愿
- 原型 + 可用性测试 — 只有在价值和可行性明确之后
参考资料
references/four-risk-taxonomy.md— 所有 4 个核心风险加伦理风险的完整定义和评分规则references/technique-categories.md— 所有 5 个技巧类别及其 4 个测试子类别的描述references/discovery-sequencing-logic.md— 跨风险组合排序发现活动的决策树references/discovery-principles.md— 所有 10 个构建前验证原则的完整阐述
许可证
此技能根据 CC-BY-SA-4.0 获得许可。
来源：BookForge — INSPIRED: How to Create Tech Products Customers Love，作者 Marty Cagan。
相关的 BookForge 技能
此技能是独立的。浏览更多 BookForge 技能：bookforge-skills