产品评审与决策治理
回答：评审会怎么开才不走样？什么决策该慢想、什么决策其实没有回头路？
簇内活跃分歧——"双向门"到底是不是借口：†two-way-door-fallacy（Shreyas Doshi：PM 常以"这是可逆决策"为借口仓促上线功能，导致 5-6 周开发后采用率低、QBR 上用轶事掩盖数据、被迫在客户面前当场加注更多工程资源——"多数看似双向门的决策，对 Bezos 而言是双向门，对你这个 PM 领导而言其实是单向门"）与 †pre-mortem-framework（Shreyas Doshi：反向假设"这个项目 6 个月后惨败了，为什么"，配合 Tigers/Paper Tigers/Elephants 词汇体系创造心理安全感）共同构成"决策前多想两分钟"的方法论——直接对立于行业默认的"速度至上、双向门就该快速试错"的创业教条。
评审会形式设计：catalyst-review-meeting、catalyst-review-system（均 Coda/Lane Shackleton 脉络）、dual-track-review-playbook（Figma）、four-point-product-review（Notion）、gsd-project-review-system（Shopify）、miro-product-review-lifecycle、principle-calibrated-product-review（Ami Vora）、product-review-feedback-prioritization（Julie Zhuo）、product-review-playbook、product-review-stages（Duolingo）、ramp-decentralized-review-playbook、review-approval-limits、snowflake-product-review、three-check-in-product-review、murder-board-principle-setting（Palantir）。
决策速度与质量：pre-mortem-kill-criteria（Annie Duke）、high-tempo-decision-making、traffic-light-decisions、trapdoor-decision-test、second-order-thinking-and-door-decisions、tradeoff-evaluation-model、kill-hope-before-hope-kills-you、project-stamina-model、long-feedback-loop-illusion（Annie Duke）、context-over-control（Geoff Charles）、wbr-mechanism（Amazon）、when-to-skip-an-experiment、hunt-for-misalignment、blameless-postmortem-playbook（发布后复盘会常变成追责会，导致参与者防御心理阻碍系统性改进）。
双向门谬误Two Way Door Fallacy
产品团队以“这是双向门（two-way door）决策”为借口，不深入思考客户动机、差异化和分发策略就匆忙上线功能，最终导致功能堆砌和团队过劳。
事前验尸框架Pre Mortem Framework
项目上线前，团队缺乏心理安全感去表达对潜在风险的担忧，导致本可避免的翻车事件频繁发生。
催化剂式评审会议Catalyst Review Meeting
传统产品/设计评审会常出现参与人员不对、缺乏背景上下文或被高管施压等常见问题。
催化剂式评审系统Catalyst Review System
传统的产品审查/决策会议存在两大痛点：1) 固定参会者导致该来的人没来，不该来的人来了，要么延期要么盲决；2) 单线议题导致会议过长或排不上日程，成为整个公司的吞吐量瓶颈。
双轨评审手册Dual Track Review Playbook
设计反馈和产品决策混同，导致会议既无法产生高质量创意，又难以高效做出方向决策，且容易被声音最大的人主导。
四点产品评审法Four Point Product Review
产品开发过程中缺少结构化的质量把关，领导反馈来得太晚或太随意，导致团队在临近发布时才发现方向偏差。
GSD项目评审体系Gsd Project Review System
如何在庞大的产品组织中，跨层级、跨职能地评审和推进项目，同时避免陷入传统任务管理工具的繁文缛节？
Miro 产品评审生命周期Miro Product Review Lifecycle
如何规范化地管理产品开发不同阶段的评审，既保证跨职能对齐和质量把控，又避免会议时间被低效的“演示”占据。
原则校准产品评审Principle Calibrated Product Review
如何避免 Product Review（产品评审）沦为信息的堆砌，并真正通过评审提升组织的决策能力，而不是让高管替团队做每一个具体决定。
产品评审反馈优先级Product Review Feedback Prioritization
在产品/设计评审中，收集到的反馈往往杂乱无章且相互矛盾（如有人关注颜色，有人关注流程），团队难以对这些反馈进行有效排序和决策。
产品评审运行手册Product Review Playbook
如何设计并运行高效的产品评审会，既能同步信息、保持问责，又不让团队感觉像在“上刑场”，真正帮助产品改进。
产品生命周期评审阶段Product Review Stages
如何在产品生命周期的不同阶段，以合适的颗粒度收集反馈并审批产品变更。
去中心化产品评审指南Ramp Decentralized Review Playbook
随着团队规模扩大，产品/设计评审成为瓶颈，高层领导成为“守门人”导致决策变慢，且产品与设计部门间容易出现反馈不一致。
产品评审审批限制Review Approval Limits
产品评审和审批链条过长导致交付缓慢，需要明确的基准数据来提升执行速度和团队自主权。
雪花产品评审法Snowflake Product Review
如何通过标准化的评审流程，确保跨产品的一致性、信息共享和及时决策，同时避免评审会沦为向领导层“推销”方案的场合。
产品审查三检法Three Check In Product Review
在大型产品组织中，如何设计产品审查流程以避免跨职能信息脱节和领导层意外？
谋杀委员会审查法Murder Board Principle Setting
如何确保新项目的计划经得起推敲，以及如何制定真正有指导意义的项目原则，而非毫无争议的废话。
事前验尸止损标准Pre Mortem Kill Criteria
项目严重超时、超支后才发现早就该放弃；沉没成本谬误和禀赋效应导致团队难以在中途理性止损。
高频极速决策法High Tempo Decision Making
组织变大后决策变慢，如何建立极速决策的文化与机制。
红绿灯决策法Traffic Light Decisions
决策会议中用 pros/cons 列表评估选项，信息扁平、难以快速比较，不同职能的视角混在一起。
活板门决策测试Trapdoor Decision Test
在推崇严谨思考的文化中，如何避免过度思考，判断一个决策需要多长的决策周期。
二阶思维与单向门决策Second Order Thinking And Door Decisions
如何评估产品决策的长期影响，并决定在某个决策上应投入多少讨论与审批精力？
权衡取舍评估模型Tradeoff Evaluation Model
在信息不全、时间压力下，如何结构化地评估产品权衡取舍问题并给出令人信服的决策。
主动扼杀虚假希望Kill Hope Before Hope Kills You
创始人和团队常常陷入对“下一个版本会变好”的盲目乐观中，导致在一个 B+ 甚至更差的产品上死耗，浪费资源。
项目耐力模型Project Stamina Model
高模糊性项目中，如何判断一个不顺利的项目该继续坚持还是应该果断放弃。
长反馈循环错觉Long Feedback Loop Illusion
认为“反馈周期太长”（如 VC 投资 10 年后才退出，或产品多年后才见成效）导致无法在当下评估决策质量，从而放弃优化。
背景重于控制Context Over Control
在追求极高产品交付速度时，如何避免领导者陷入微观管理，同时确保团队做出的决策不偏离公司目标。
WBR 运营机制Wbr Mechanism
如何在大规模组织中建立运营纪律和持续改进的文化？
跳过实验决策准则When To Skip An Experiment
在产品迭代时，判断哪些改动不应该进行 A/B 测试或实验，以及在这些情况下应该如何决策。
捕捉团队分歧法Hunt For Misalignment
团队成员（如设计师与工程师、PM与研究员、高管与团队）之间产生隐性分歧，导致项目推进受阻。
无指责事后复盘指南Blameless Postmortem Playbook
产品发布后的复盘会往往变成追责会，导致参与者产生防御心理，无法挖掘真正的系统性问题并产生有效改进。