阶段门怎么做？产品经理风险控制：项目阶段从0到1

去年我接手一个 B 端产品的复盘，项目从立项到正式发布用了 11 个月，其中将近 4 个月的时间花在返工上，需求文档推翻重写两次，技术方案推翻一次，UI 稿重构一次。复盘会上有人问我：“我们明明每个阶段都开了评审会，为什么还是走到这一步？”这个问题我后来想了很久，也在后面十几个项目里反复验证：不是评审会开得不够，而是这些会根本不是阶段门。评审会讨论的是“做得对不对”，阶段门要回答的是“还要不要继续做、下一笔钱该不该投”。

这两件事看起来像，实际差着十万八千里。

一、先说核心结论：阶段门是风险定价机制，不是流程仪式

如果你只从这篇文章带走一句话，我希望是这句：阶段门（Stage-Gate）的本质，是在不确定性还很低成本的时候，做一次“继续投入 or 立即止损”的重新定价。它管理的对象不是文档、不是进度，而是风险敞口。

我见过太多团队把阶段门做成了“文档齐全度检查”。需求文档写了没有、原型画了没有、测试报告出了没有，齐了就过门。结果门是过了，风险一个没少，等到发布前才发现用户根本不用。这不是阶段门失灵，这是把阶段门用错了地方。

1. 阶段门真正在管的，是三个变量

我把这套东西拆解了很久，最后发现有价值的阶段门只回答三个问题，而且必须按顺序回答。

• 假设验证到什么程度了？当前阶段承诺的核心假设，有没有被真实证据支持，还是只停留在团队内部共识。
• 下一阶段要花多少钱、多长时间？这是投入额的定价，门的意义在于让你在花这笔钱之前再想一次。
• 如果判断错了，退回来的成本有多高？也就是可逆性。可逆性越高，门可以越松；可逆性越低，门的判据必须越硬。

这三个问题里，第三个最容易被忽略，但它其实是整道门的设计依据。一个可以一周内推翻的原型方案，和一套已经开始对外的定价体系，风险等级完全不在一个量级上。

2. 从 0 到 1 和从 1 到 N，门的逻辑是反的

这是我最想强调的认知差。从 1 到 N 的阶段门，核心目标是防偏差，流程标准化、交付一致性、成本控制。而从 0 到 1 的阶段门，核心目标是防沉没，防止团队在一条错误的路上越走越深。

这两种目标导向下，门的位置、判据、决策人都不一样。0 到 1 的门应该更关注“我们还要不要做这件事”，1 到 N 的门应该更关注“我们做得够不够规范”。拿 1 到 N 的门去卡 0 到 1 的项目，最常见的后果是团队学会写漂亮的文档来应付，而不是学会诚实地面对风险。

3. 一个反常识判断：0 到 1 的门应该更少，但更难糊弄

很多产品经理的直觉是“早期风险高，所以要多设门”。我的观察恰恰相反。0 到 1 阶段最稀缺的资源是探索速度，阶段门太密会直接掐死试错空间。

正确做法是减少门的数量，同时把每一道门的判据做实。三个难过的门，比八个走过场的门有用得多。我经手的项目里，凡是阶段门超过六个的早期项目，几乎没有一个是按门真正做决策的，最后都演变成形式主义。

二、真实场景：三个让我改掉做法的项目

抽象讲方法论容易，但真正让我调整做法的，是三个具体的失败。它们分别对应门的位置、门的判据、门的人这三件事。

1. 案例一：门开在了错误的位置

2021 年我参与一个内部效率工具项目。团队在立项后第 6 周就设了一道“原型评审门”，要求输出完整可点击原型。为了这道门，设计和前端投入了将近三周时间，做出一个 40 多个页面的高保真原型。

问题在于，这个阶段真正没被验证的是“目标用户是否愿意改变现有工作习惯”，而不是“界面做得漂不漂亮”。我们把门开在了最容易验证的地方，而不是风险最高的地方。原型做得很精致，过了门，投入继续加大，等到第 5 个月做用户测试时才发现，用户根本不愿意从现有的表格工具迁移过来。

后来我复盘，如果当时那道门改成“15 个目标用户中至少 8 个愿意在两周内试用替代方案”，成本不到原来的五分之一，但能提前四个月发现致命问题。

2. 案例二：评审会开成了汇报会

第二个项目更典型。我们确实设了阶段门，也确实开会了，但会议结构是这样的：项目负责人讲 40 分钟 PPT，然后大家提问题，最后主持人问“大家还有意见吗”，没人反对就通过。

这种会的致命缺陷是默认通过。没有明确的否决责任，没有预设的判据，没有“不通过怎么办”的预案，那么门的实际通过率必然是 100%。

我后来统计过这个项目全部 5 次评审：4 次全票通过，1 次“有条件通过”，而那次“有条件通过”的条件，最后也没人跟踪。门形同虚设。

3. 案例三：判据从“能说清”滑向了“能讲好”

第三个项目是我印象最深的。我们给概念门定了一条判据：“能清晰说明目标用户和核心价值”。这条判据听起来没问题，但它有个致命缺陷，它衡量的是表达质量，不是证据质量。

结果就是，谁的 PPT 做得好、谁的故事讲得顺，谁就更容易过门。有个方案在内部讲得极其顺畅，全场鼓掌通过；另一个方案准备仓促，讲得磕巴，被打回去补充材料。三个月后，被打回的那个方向在市场上验证成功，被鼓掌通过的那个悄无声息地死了。

这件事让我彻底改掉了判据写法：凡是能用“说清楚”来判定的，一律改写成必须用“证据数量”来判定。

4. 从这三个失败里，我提炼出三个可观察信号

后来我把这些经验固化成三个可以在会上直接观察的信号，用来判断一道门是不是真的在起作用。

1. 是否出现过“不通过”的决策。如果一个季度里所有门全部通过，基本可以判定门是假的。
2. 是否有项目因为过不了门而被主动终止或降级。没有终止能力的门，本质是资源分配确认书。
3. 决策人和汇报人是不是同一个人。如果是，门的独立性就消失了。

三、拆解六个最常见误区

这六个误区我几乎在每个团队都见过至少一个，而且它们经常同时出现。我按“危害程度”从高到低排列。

1. 误区一：把阶段门等同于评审会

这是根本性误解。评审会是信息同步机制，阶段门是资源决策机制。评审会可以没有结论，阶段门必须有结论，而且结论只有有限的几种。

我现在的做法是：阶段门会议的议程里，汇报时间被严格限制在 15 分钟以内，剩下时间全部用于回答一个固定问题，“基于现有证据，我们应该继续投入、缩减投入、还是停止？”如果讨论跑偏到方案细节，主持人要立刻拉回来。

2. 误区二：用同一套门禁卡所有项目

很多团队只有一套阶段门模板，无论项目是 2 人小迭代还是跨部门大项目，都走同样的门、交同样的材料。这会导致两种后果：小项目被流程拖死，大项目觉得流程太轻不够用。

我的处理方式是分级。按投入额度和可逆性把项目分成 A、B、C 三档，每档对应的门数量、判据严格度、决策层级完全不同。一个两周内可回滚的试验，不需要惊动决策委员会。

3. 误区三：只管准入，不管退出

大部分阶段门文档只写“通过本门需要满足什么条件”，却从不写“如果长期达不到条件怎么办”。这就造成了一个普遍现象：项目卡在某个阶段迟迟不动，既不推进也不终止，长期占用资源。

我现在给每道门都配一条“最长停留时间”。比如概念门最长停留 6 周，超过就自动触发一次重新评估，评估结论必须落在“继续、降级、终止”三者之一，不允许出现“再观察观察”。

4. 误区四：把通过率当成团队 KPI

这是隐性危害最大的一个。一旦阶段门的通过率跟团队绩效挂钩，团队的行为立刻会转向：要么把判据往宽了写，要么把证据往好看了做。阶段门一旦成为考核工具，就失去了发现真相的能力。

我从不在团队里公布“通过率排名”，只公布“早期发现问题数”和“及时终止项目数”。这两个指标才是阶段门真正应该优化的方向。

5. 误区五：决策者缺席，参会者不决策

非常常见的场景：阶段门会议来了十几个产品、研发、设计同学，但真正能决定“这笔预算给不给”的人没来。会议开完，结论是“我们把情况汇报给领导，等他定”。

这道门实际上被推迟到了某个不确定的时间点，而团队往往会默认“没被否决就是通过”，继续往下做。决策者不到场，这道门就不算开过。

6. 误区六：文档齐全就等于风险清楚了

这是最容易自我欺骗的一条。我见过一个项目的阶段门材料多达 80 页，涵盖了市场分析、竞品分析、技术方案、风险评估，装订精美。但当我问“这里面哪一页能证明用户愿意付钱”，全场沉默。

我现在要求每一份过门材料必须有一页“风险清单”，里面只写三列：未验证的关键假设、验证它的最小成本方法、如果不成立的后果。这一页比前面 79 页都有用。

四、专业判断逻辑：一套真能拦住风险的阶段门长什么样

讲完误区，说方法。我把阶段门的设计归纳成一个可操作的推导顺序：先定风险假设，再定门的判据，最后定决策人和退出规则。顺序不能反，反了就会变成先有会议再找内容。

1. 第一步：先把当前阶段的风险假设列出来

任何一次阶段门之前，团队应该能列出本阶段最关键的 3 到 5 个假设。注意，是假设，不是任务。比如“用户愿意把现有数据导入我们的系统”是一个假设，“完成数据导入功能开发”是一个任务。

阶段门要检验的是假设，而不是任务完成度。我习惯用一句话句式来写：“我们认为 ____，如果错了，会导致 ____。”后半句很重要，它决定这条假设是不是值得单独设一道门。

2. 第二步：门必须包含四个要素，缺一不可

这是我踩了足够多坑之后总结出来的最小完整结构。缺任何一个要素，门就会失效。

• 判据：可量化、可被第三方核验的通过条件。比如“15 位目标用户中至少 8 位在两周内完成 3 次以上操作”。
• 证据：支撑判据的材料形态。必须区分“观点类证据”和“行为类证据”，行为类证据权重更高。
• 决策人：一个具体的人，不是委员会。他有权做“继续、缩减、终止”的决定。
• 时限：这道门必须在什么时间之前完成决策，超时的默认动作是什么。

我特别强调“默认动作”。很多门的失败在于超时后没人管。我的做法是：超时未决策，默认降一级处理。这个规则反向逼着决策者按时出现。

3. 第三步：用可逆性决定门的密度

可逆性是我认为最被低估的一个判断维度。同样是一百万的投入，花在可以随时叫停的软件功能上，和花在已经对外承诺的硬件开模上，风险完全不同。

我的简化规则是：可逆性高、成本低的阶段，门可以合并甚至跳过；可逆性低、成本高的阶段，门必须独立且判据从严。这条规则能解决大部分“到底该设几道门”的争论。

4. 第四步：把判据分成 A、B、C 三级

不是所有判据都必须全部满足才能过门。我给判据分三级，让决策更有弹性，也更有重点。

这个分级最大的好处是：把“过或不过”的二元决策，变成了有梯度的资源调整决策。很多项目不是该不该做的问题，而是该投入多少的问题，A/B/C 分级正好对应这个灰度。

5. 第五步：把判据变成系统里可查询的字段

只要判据还停留在文档里，它就一定会被遗忘。我要求所有 A 级、B 级判据都要成为项目管理平台里的结构化字段，能在任意时刻查到“这个项目当前卡在哪条判据上、卡了多久、责任人是谁”。

这听起来像小事，但效果非常明显。之前我们是靠项目管理同学手动跟进，一个人最多同时盯 5 个项目；结构化之后，任何人都能在系统里看到全局，包括哪些项目已经超出门的最长停留时间。

五、0 到 1 的六道门：具体判据与操作细节

前面讲的是原理，这一节我给出一套可以直接拿去改用的具体门禁设计。需要说明的是，这是我在 B 端产品和中台项目里打磨出来的版本，直接套用到硬件或强监管行业需要调整。

1. 第一道门：机会门

这道门只回答一个问题，这件事值不值得投入研究资源。它不评估方案，不讨论怎么做，只看方向是否成立。

判据我一般设三条：目标问题在近三个月内被至少 5 个真实用户主动提及；这个问题当前没有令人满意的现成解法；解决它跟当前业务方向有明确关联。

最常见的错误是把“老板想做”当成通过条件。我不是说老板的判断不对，而是它应该被翻译成上述三条中的某一条，否则这道门无法积累任何经验。

2. 第二道门：概念门

概念门是淘汰率最高的一道，也是最有价值的一道。它要验证的是问题真实性和付费意愿的早期信号。

我用的判据通常是：完成至少 12 位目标用户的深度访谈；其中至少 6 位描述过自己为解决该问题付出的具体成本（时间、金钱或其他工具）；至少 3 位愿意做后续的试用种子用户。

注意最后一条，“愿意做种子用户”和“说这个功能不错”是完全不同的证据强度。前者是行为承诺，后者是社交礼貌。我在项目里只把前者算作有效证据。

3. 第三道门：方案门

这道门检验的是“在给定约束下能不能做出来”，而不是“方案优不优雅”。我见过太多团队在方案门上花大量时间比较技术选型，却忽略了最关键的约束条件。

判据我一般会写成：核心链路的可行方案已明确；关键技术风险点已完成验证性实验；开发工作量估算误差控制在 ±30% 以内；方案不依赖任何未到位的外部条件。

最后一条特别重要。我遇到过项目在方案门通过时，依赖的一个第三方接口还没谈下来，结果开发到一半接口方案变更，整个数据层重构。现在我的规则是：任何未落地的外部依赖，都必须在方案门之前变成确定项，否则这门不算过。

4. 第四道门：原型门

原型门验证的是“用户能不能真的用起来”，而不是“功能全不全”。这道门的判据必须来自真实操作行为，不能来自演示。

我的判据模板是：15 位目标用户中至少 10 位在无引导情况下完成核心任务；任务平均完成时间低于预期上限；至少 5 位在试用后一周内主动再次使用。

“无引导”这三个字很关键。带引导的演示几乎总能成功，因为用户会顺着你的思路走。我在一个项目里做过对照：同一版原型，带引导测试通过率 92%，无引导测试通过率 43%。这个差距才是真实的产品可用性。

5. 第五道门：验证门

验证门是决定“要不要规模化”的关键节点。它看的不是功能完成度，而是关键业务指标是否达到继续投入的阈值。

这里我要强调一点：阈值必须在项目开始前就定义好，而不是事后根据结果倒推。否则一定会出现“虽然没达到 30% 留存，但我们发现用户在另一个维度上很有热情”这类自我安慰。

6. 第六道门：发布门

发布门是最接近传统阶段门的一道，关注的是交付能力和长期风险。判据通常包括性能压测结果、故障处理预案、支持文档完备度、合规检查项。

这道门最常见的漏洞是“带条件通过”太多。我见过一个项目连续三次带条件通过发布门，每次的条件都没在规定时间内闭环。所以我现在要求：发布门的任何 B 级条件，必须在下一个迭代内闭环，否则自动升级为 A 级否决项。

六、工具落地：怎么把阶段门变成系统里的硬约束

方法论讲完了，接下来是一个很现实的问题：怎么保证阶段门在真实项目里被执行，而不是在第三个迭代就悄悄消失。我的答案是，不要用文档管门，用系统管门。

1. 为什么文档管不住阶段门

文档的三个致命问题：状态不可查、责任不清晰、超时无提醒。一份阶段门评审模板存在共享盘里，三个月后没人知道哪个项目卡在哪一道门，也没人知道某条 B 级条件有没有闭环。

我做过一次对比：同样的阶段门规则，用文档管理的团队平均有 40% 的门会因为各种原因延迟或跳过；用系统做硬约束的团队，这个比例降到 12% 左右。

2. 以研发项目管理平台为例的配置思路

我目前最常用的做法，是在研发项目管理平台里把阶段门直接建成工作流状态。以 PingCode 为例，它主要服务中大型企业及 100 人以上组织，在流程自定义和工作项建模这块能力比较完整，适合承载这类“门 + 判据 + 决策记录”的结构。

我的配置逻辑分四层。

1. 工作项类型层：把每个阶段门建成独立的工作项类型，字段包括判据清单、责任人、决策人、最长停留时间、当前状态。
2. 判据层：每条 A/B/C 级判据做成一个子项或检查项，必须逐条标记“已满足 / 未满足 / 不适用”，不允许整体勾选。
3. 决策记录层：每次过门必须留下结构化的决策记录，包含证据链接、结论、下一步动作，而不是一段会议纪要文本。
4. 超时机制层：超过最长停留时间的工作项自动升级提醒，并进入降级队列。

第三层是我认为最有价值的。会议纪要文本在系统里等于不存在，因为无法查询、无法统计。结构化决策记录则能让你在半年后回溯：“当时这条判据的证据是什么，谁做的判断，后来证明准不准。”

3. 配置示例：一条 A 级判据的结构

下面是我在实际项目里用的判据配置结构，可以直接参考改造。它同时包含了判据定义、证据要求、责任人和超时动作。

{
"gate_id": "G2_concept",

"gate_name": "概念门",

"max_stay_days": 42,

"criteria": [

{

"id": "C-A1",

"level": "A",

"statement": "完成不少于 12 位目标用户深度访谈",

"evidence_type": "行为类",

"evidence_required": "访谈记录 + 用户画像标签 + 时间戳",

"owner": "产品负责人",

"satisfied": false

},

{

"id": "C-A2",

"level": "A",

"statement": "不少于 6 位用户能描述为解决该问题付出的具体成本",

"evidence_type": "行为类",

"evidence_required": "访谈原话摘录 + 成本量化记录",

"owner": "产品负责人",

"satisfied": false

},

{

"id": "C-B1",

"level": "B",

"statement": "不少于 3 位用户承诺参与后续试用",

"evidence_type": "行为类",

"evidence_required": "书面或系统内确认记录",

"owner": "用户研究员",

"satisfied": false

}

],

"decision_maker": "产品线负责人",

"decision_options": ["继续", "缩减投入", "终止"],

"on_timeout": "自动降级为观察状态并触发重新评估"

}

这套结构最大的价值在于它把“口头共识”变成了“可审计记录”。当所有人知道判据会被逐条核验、结论会被留存，准备材料的重心就会自然从“怎么讲得漂亮”转向“怎么把证据做实”。

4. 迁移和私有化场景下需要注意什么

如果你的团队正在从其他项目管理工具迁移过来，有两点我建议提前想清楚。一是历史项目的阶段门数据要不要一并迁移，我的建议是只迁移近一年内的在跑项目，历史项目走归档即可，否则清洗成本远高于收益。

二是字段映射要一次到位。阶段门涉及的状态字段、人员字段、时间字段比较多，建议在正式迁移前先用 2 到 3 个项目做灰度，验证字段映射和自动化规则是否正常，再全量迁移。

另外，对于数据敏感度较高的团队，支持私有化部署的平台会更合适，这样阶段门里的判据证据、用户访谈记录、决策记录都能留在自有环境内，不用担心合规问题。

七、不同情况下的行动建议

阶段门不是一套标准答案，它在不同规模、不同行业里的落地方式差别很大。我按四种典型情况给出建议，你可以直接对号入座。

1. 10 人以下小团队：只留两道门

小团队最忌讳流程重。我的建议是只保留概念门和发布门，其他阶段用周会同步即可。重点是概念门一定要认真做，因为小团队承担不起方向性错误。

具体做法：概念门不需要正式评审会，但必须有一个明确的清单，你访谈了几个用户、他们说了什么、你打算怎么验证。这份清单存在共享文档里也可以，关键是要写下来，不能只在脑子里。

2. 30 到 100 人团队：四道门 + 分级管理

这个规模是阶段门最容易产生价值的区间。我建议上四道门：机会门、概念门、原型门、发布门，同时引入项目分级，小项目走简化流程。

这个阶段最关键的动作是把判据结构化。哪怕暂时不用系统，也建议用表格把每道门的 A/B/C 判据列成固定字段，逐条核验。很多团队就是卡在“判据太模糊”这一步。

3. 100 人以上中大型组织：六道门 + 系统承载

到这个规模，靠人和文档已经管不住阶段门了。我的建议是完整六道门，并且一定要用系统做硬约束，否则执行率会随着项目数量增长而急剧下降。

这个阶段还有一个额外挑战：跨部门的门的归属权。比如发布门涉及研发、测试、运维、安全，谁来做最终决策？我的经验是必须指定一个对业务结果负责的人作为决策人，其他部门提供判据和证据，但不参与最终决策，避免责任稀释。

4. 强监管行业：门要前置，判据要外化

如果你在金融、医疗、汽车这类行业，阶段门的逻辑要调整。核心变化是合规判据必须前置，不能等到发布门才检查。

我的做法是把合规要求拆解到每一道门里，作为 A 级判据。比如数据采集相关的能力，在原型门之前就要确认数据来源合规，否则原型做得再好也要推翻。

八、取舍：阶段门必然带来的成本，以及怎么交换

任何流程都有代价。我不认为阶段门是无成本的，恰恰相反，它的成本非常真实，只是很多人不愿意正面谈。这一节讲清楚四组取舍。

1. 速度 vs 确定性

这是最直接的一组冲突。每加一道门，平均会延长 1 到 3 周的决策周期。在竞争激烈的赛道，这几周可能就是先发和后发的差别。

我的处理方式不是取消门，而是压缩门内的等待时间。真正拖慢进度的很少是决策本身，而是决策前的准备，材料反复修改、关键人凑不齐、数据没跑出来。把这些前置动作做好，门本身的耗时可以压到很低。

2. 标准化 vs 灵活性

标准化能让经验沉淀，但会抑制特殊情况下的灵活处理。我见过团队为了应对一个从没出现过的场景，硬生生把流程手册加了 20 页，结果后面的项目全都背上了这个负担。

我的原则是：标准流程只覆盖 80% 的常见情况，剩下 20% 走特批通道，但特批必须记录理由。这样既不牺牲灵活性，又能通过特批记录发现流程本身的盲区。

3. 流程成本 vs 返工成本

这是唯一一组我认为可以量化比较的取舍。加一道门的成本通常是几天的会议和准备时间，而一次方向性返工的成本往往是数周到数月。

我给团队算过一笔账：一个 20 人团队，每道门平均消耗 3 人天，六道门合计 18 人天。而一次 4 周的方向性返工，消耗约 400 人天。只要阶段门能拦住一次这样的返工，全年的流程成本就赚回来了。这也是我愿意坚持做阶段门的根本原因。

4. 工具约束 vs 团队自治

把阶段门放进系统，意味着团队的操作空间被约束了。有些团队会抗拒，觉得被流程绑住。我的经验是：约束应该加在“记录”上，而不是加在“做法”上。

也就是说，团队用什么方式做用户访谈、用什么形式做原型，不需要统一；但每道门的判据核验结果和决策记录必须进系统。这样既保留了执行层面的灵活，又保证了决策层面的可追溯。

九、一页纸模板，以及你明天可以开始做的事

我不喜欢只给方法论不给动作的收尾。所以这里给一个可以直接抄走的一页纸结构，以及三个按优先级排序的下一步动作。

1. 一页纸阶段门模板

每个阶段门用一页纸描述，包含以下七项，写不满说明门还没想清楚。

1. 本门名称与所属阶段
2. 本阶段要验证的 3 到 5 个关键假设
3. A 级判据（否决项）清单
4. B 级判据（条件项）清单，含责任人与截止时间
5. 唯一决策人姓名
6. 最长停留时间与超时默认动作
7. 不通过时的三条备选路径（缩减、转向、终止）

2. 明天可以做的三件事

如果你现在就想动起来，我建议按这个顺序做。

• 第一件：挑一个正在跑的项目，写一份风险假设清单。不要超过 5 条，控制在半小时内完成。这一步能立刻暴露你现在最不确定的地方在哪里。
• 第二件：把你现有的评审会流程改成决策流程。汇报时间压到 15 分钟，剩下的时间回答“继续、缩减还是终止”，并且必须给出明确结论。
• 第三件：选一道门做结构化。把判据、证据、责任人、时限写进系统字段，跑一个完整周期看看效果。这一步是验证阶段门能不能在你团队长期存活的关键实验。

3. 我的最后一个判断

做了这么多年产品，我对阶段门的看法越来越朴素：它最大的价值不是让项目更成功，而是让失败变得更便宜。绝大多数 0 到 1 的产品最终都不会成为爆款，这不是团队能力问题，是概率问题。既然失败是常态，那么真正决定团队长期战斗力的，就是你有多快、多便宜地从错误方向里撤出来。

阶段门就是那个让你体面撤退的机制。它不保证你选对，但它保证你不会在一条错的路上把子弹全部打光。当你把这套东西从“评审会”重新理解为“风险定价机制”，你会发现很多原本纠结的问题，设几道门、谁来决策、判据写多细，突然都有了清晰的答案。