产品方案复盘

为什么要在动手前复盘

PRD 里最常见的写法是「解决用户痛点」——但痛点来自谁、有没有访谈、工单或行为数据支撑，往往说不清楚。更麻烦的是，方案一路膨胀，版本范围没人划，上线之后才发现指标没埋点、验收没口径，只能事后补故事。这个技能要做的，是在动工前把问题是否真实、值不值得做、能不能做完这三件事查清楚。

它如何工作

核心机制是证据分级。用户提供的访谈、工单、行为数据和已确认约束标为 [事实]；价值判断、优先级和研发影响标为 [推断]；没有证据的需求一律标为 [未知]，不允许悄悄升级成事实。

完整流程分八步：

• 提取目标用户、场景、问题、现有做法、方案目标和限制条件；
• 按 [事实] / [推断] / [未知] 给材料打标；
• 联网搜索竞品定位、功能、价格和公开用户反馈（优先查产品官网、应用商店评论、36氪、极客公园、虎嗅），记录来源和日期；
• 依据 references/models.md 选适用模型，分别检查问题价值、方案差异、优先级、用户路径和验证方法；
• 从用户问题、产品价值、市场差异、范围优先级、体验完整、技术可行、验证闭环七个维度评分；
• 列出必须保留、建议删减、需要实验和暂缓的条目；
• 输出 MVP 范围、验收标准、指标、埋点和上线后的继续/停止条件；
• 最后运行报告检查，修正无法执行或无法验收的建议。

边界与注意点

几条硬约束：没有用户证据时不声称需求已验证；竞品有某功能不构成立项理由；不编造用户数量、转化提升或研发工期；也不代替安全、隐私、医疗、金融等领域的专业合规评审。每项评分都要对应到材料章节或用户证据，外部资料标注来源和日期，优先使用三个月内的信息。