产品机会简报

先解决什么问题

很多产品需求在进入工程评审时，还停留在「我们要加个语音功能」这类模糊表述上。工程师难以判断这个需求到底要解决什么用户问题、边界在哪里、成功后该如何衡量，甚至不知道有哪些隐藏依赖会导致延期。最终要么需求反复修改，要么上线后才发现和用户真实痛点不匹配。

这个技能如何工作

这个技能通过5个核心步骤，引导产品经理把模糊的想法转化为工程可执行的简报：

1. 先收集上下文：追问问题驱动因素（用户反馈/竞品压力/数据表现）、目标用户（全量还是特定细分）、约束条件（技术限制/时间压力），避免盲目开始写简报
2. 聚焦What和Why：不替代工程团队设计How，而是明确产品要达成什么目标、为什么这对用户和业务重要
3. 结构化输出：每次输出包含问题陈述、解决方案、用户价值、成功指标、范围（In/Out）、开放问题、依赖项、时间线8个部分，保持格式一致
4. 用数据锚定Scope：把Out of Scope写成明确的决策而非暂缓，比如「不支持桌面端，因为移动端占该场景92%会话，当桌面端占比超20%再重新评估」，减少无意义的「为什么不做」争论
5. 暴露隐藏依赖：要求每个依赖项都记录负责人、沟通情况、对方时间线、延期对项目的影响，避免「无依赖」的假象

关键模式

• 指标落地：拒绝无法在项目周期内测量的指标，比如4周上线的功能不能写「提升留存率」，要写「将首日功能激活率从X%提升至Y%」
• JTBD问题陈述：不说「我们缺少语音消息功能」，而是说「消息高频市场的用户在打字比说话慢时会放弃当前会话，转去WhatsApp」
• 渐进式披露：简报支持3种阅读速度——30秒扫问题+方案+指标、5分钟读全文、需要时查依赖和开放问题

适用边界

• 需要你提供基本上下文（问题、目标用户、业务动机），不能凭空生成需求
• 不能替代深度用户研究或技术架构设计，依赖项的owner和时间线需要你确认
• 指标必须有已知数据源和合理测量周期，缺少基线时会明确标记为缺口