product-reviews

高效的产品评审

开展严谨的对齐会议，提升质量标准并加快决策。

借鉴 Lenny's Podcast 和 Newsletter 中 12 位嘉宾的见解及相关文章，帮助用户高效开展产品评审。

如何提供帮助

1. 评估评审文化 - 评估当前的评审形式，找出阻碍因素或质量标准方面的不足。
2. 选择框架 - 根据项目的复杂度和生命周期，推荐合适的评审阶段或模板。
3. 起草评审材料 - 协助梳理问题陈述、列出各种方案，并准备预读材料。
4. 引导会议 - 提供判断意见倾向、处理异议和记录明确决策的技巧。

核心原则

评估框架，而非解决方案

摘自“How Figma builds product”：“我鼓励大家先展示‘方案空间’。用一个框架映射所有可能的解决方案或问题，并以此讨论高层次的权衡或理念差异，效果非常好。”

高质量决策源于梳理所有可能的解决方案，而非孤立地争论某个提案。

建立透明的评审节奏

摘自“How Duolingo builds product”：“产品评审会议每周二和周四举行，每周共两小时。这两小时分为 20 分钟的时段，由产品团队报名进行展示。会议议程是：产品团队用前 5 到 10 分钟介绍拟议的产品改动，之后由评审人员提问并反馈。”

定期安排简短的评审时段，既能避免反馈瓶颈，也能让整个组织对质量标准形成共识。

将问题与解决方案分开

摘自“How Miro builds product”：“产品评审可以聚焦于产品开发生命周期的不同阶段：P-Strat：长期战略和愿景；P0：要推进的机会与问题；P1：拟议的解决方案；P2：已发布的内容及其表现。”

将评审划分为不同阶段，确保团队投入高保真设计工作前，领导层已就问题和战略方向达成一致。

将质量准则付诸实践

摘自“How Miro builds product”：“一位产品负责人提出了‘蒙娜丽莎原则’——简单来说，我们发布的所有内容都应该像一幅蒙娜丽莎画作，让我们为署上自己的名字而自豪。……他们每个月都会评审已发布的所有内容，并指出哪些质量高、哪些不高。”

运用简单的比喻或原则，在团队中培养直觉，帮助每个人理解卓越的标准，而无需持续监督。

对齐目标，而非推销方案

摘自“How Snowflake builds product”：“产品评审的目标不是向领导团队‘推销’新的投资，而是详细说明客户需求、就业务优先级达成一致，并明确如何应对这些挑战。”

将评审设计为协作会议，聚焦于保持决策一致，而非内部宣传或向领导层推销想法。

深入澄清问题

Tomer Cohen：“我非常强调要说出你真正的观点、可能引发争议的观点。最好的原则必须有锋芒。所以，告诉我应该打造一款简单的产品，这毫无用处。谁不想打造一款简单的产品呢？”

评审应深入探讨具体问题和有原则的观点，避免沦为缺乏战略价值的高层次进度汇报。

模板与框架

• 产品评审阶段（P-Strat、P0、P1、P2）（Miro 如何构建产品）——与产品开发生命周期相匹配的四阶段产品评审框架，每个阶段都有明确的模板和评审标准
• 不确定性 × 影响力 2x2 评审频率标准（成功管理管理者的五项原则）——供越级负责人使用的 2x2 矩阵，根据不确定性和影响力来确定对委派项目的评审频率
• 方案空间（Figma 如何构建产品）——一种产品评审框架，要求演示者在讨论具体方向前，先列出所有可能的解决方案或问题，以便更好地展开讨论
• 一致性量表小组件（Yuhki Yamashata）——一个 FigJam/Figma 小组件，显示一条光谱，评审者点击即可放置自己的头像，从而在产品评审期间快速了解一致性情况
• Snowflake 产品评审文档（Six-Pager）（Snowflake 如何构建产品）——一份六页文档，在产品评审前一周分享，概述客户问题、拟议解决方案和供领导层评审的关键数据
• Notion 的四阶段产品评审流程（Notion 如何构建产品）——在产品开发的四个关键里程碑进行结构化检查，取代非结构化的工作会议。主要采用异步方式，并转向同步沟通
• 采用 Talktracks 的异步产品评审工作流（Miro 如何构建产品）——通过将演示改为异步，并让会议聚焦于讨论，使产品评审更高效的工作流
• 项目审查小组（Nabeel S. Qureshi）——针对新项目的同行评审流程，由有经验的外部人士对一份 2 页计划进行严格评议。

完整列表及详情请参阅 references/artifacts.md。

帮助用户思考的问题

• “这个项目目前处于产品开发生命周期的哪个阶段？”
• “你们是否已经梳理出全部可能的解决方案，还是只提出了一条路径？”
• “你们试图解决的具体且细致的问题陈述是什么？”
• “这个项目在不确定性与影响力矩阵中的位置如何？”
• “团队内部是否存在应在本次评审中提出的不同意见？”
• “团队将哪些基于原则的观点带入了这次讨论？”

需要指出的常见错误

• 把评审当作状态更新——这会浪费领导层的时间，也无法解决战略障碍或质量问题。
• 评审时间过晚——团队会对某个解决方案产生依赖，使领导层的反馈听起来像令人沮丧的障碍，而不是指导意见。
• 追求共识而非一致——等待所有人达成一致会拖慢开发，且往往会导致产品决策被稀释。
• 在问题达成一致前就讨论解决方案——这会引发循环争论，因为利益相关者追求的目标各不相同。

深入了解

12 位嘉宾提供的全部 12 条见解，请参阅 references/guest-insights.md

相关技能

• 高管沟通
• 向上管理
• 主持会议
• 书面沟通