项目立项周期全流程：产品经理落地方案与一文讲清

去年我帮一家 400 人的 SaaS 公司复盘他们最慢的一次立项：从产品经理在周会上提出想法，到最终拿到 6 个人力编制和 80 万预算，整整 47 个工作日。会后我拉了一张时间轴，把每个环节的耗时逐个标出来，结果非常刺眼，真正用于判断“这件事到底该不该做”的时间只有 3 天，剩下 44 天全部消耗在材料翻译、跨部门对齐、预算排队和格式返工上。这篇文章不打算讲立项流程的定义，而是把这 47 天拆成产品经理真正能动手改造的模块：周期该由什么决定、哪些节点必须留、哪些节点纯粹是组织惯性、以及在不同类型的项目上你该怎么主动拉长或压缩立项周期。

一、核心结论：立项周期不是审批流水线，而是一次“不确定性定价”

先把结论摆出来。我做了八年产品，参与过近百次立项，其中有我自己主导的，也有作为评审方参与的。我对方立项周期的判断可以压缩成四句话，后面所有内容都是这四句话的展开和证据。

1. 立项周期真正要买的，是“停止投入的权利”

大部分产品经理把立项理解成“申请资源”。这个理解不算错，但太浅了，浅到会让你把全部精力放在“怎么让老板同意”上，而不是“怎么让自己随时能喊停”上。

立项的本质是：在投入还小的时候，用一笔可控的成本，换取一个“随时可以终止”的合法权利。立项流程里的每一道门槛，理论上都应该回答同一个问题，如果我们现在停下，已经损失了多少？什么样的信号出现时，我们应该停？

这个视角一旦建立，你会发现很多流程突然变得可以解释了。为什么财务要你算三年 ROI？不是因为老板真的信那个数字，而是因为算的过程中你会被迫暴露“这个项目靠什么赚钱”的假设。为什么要求写风险清单？不是走过场，而是提前约定止损线。反过来，那些只要求“填表、签字、盖章”的节点，本质上没有在给不确定性定价，它们只是在转移责任。

2. 周期的长短应该由“不可逆成本”决定，而不是由公司规模决定

我看到最常见的错误，是用公司规模来决定立项强度。1000 人的公司就觉得所有项目都得走三道评审，100 人的公司就觉得所有项目都该一周立项。这两个逻辑都不成立。

真正决定立项周期长度的变量只有三个：不可逆投入的规模、决策的不可逆程度、外部的合规约束强度。一个 30 人天、随时可以停的技术预研，哪怕在大厂也应该走轻立项；一个涉及数据迁移、一旦开始就回不了头的平台重构，哪怕公司只有 80 人，也必须走重立项。

3. 压缩周期的正确方向是砍签字节点，不是砍验证节点

这是我在多个企业里反复验证过的一条判断。绝大多数人想缩短立项周期时，第一反应是“减少审批环节”，但他们砍掉的往往是验证节点，而不是签字节点。结果周期确实短了，失败率却上去了。

签字节点和组织流程强绑定，砍掉一个副总签字，通常只需要一次管理层会议。而验证节点代表的是信息获取能力，砍掉它不会让你更快拿到答案，只会让你在更晚的时候才发现答案是“不该做”。所以正确的压缩顺序是：先砍重复签字，再砍格式性材料，最后才考虑简化验证。

4. 产品经理最该交付的不是文档，而是可被证伪的假设

立项材料写得漂亮，不等于立项做得好。我评审过的最差的一份立项书有 62 页，里面有市场规模、竞品分析、技术架构、三年财务预测，唯独没有一句话说清楚“如果哪件事不成立，这个项目就该被砍”。

相反，我见过最有效的一份立项材料只有 3 页，第一页就是三个假设：客户愿意为这个功能单独付费、获客成本能控制在 800 元以内、现有架构能支撑 10 倍并发。每一项后面都跟着验证方法和当前证据。这份材料 20 分钟就通过了评审。

二、背景和真实场景：三类立项周期，三种死法

讲完结论，我想把场景摊开。过去三年我参与或复盘过的立项里，耗时最长和最短的项目差距超过 10 倍。有意思的是，这些项目的“失败原因”几乎不重复，每一种项目类型都在被不同的环节拖死。

1. 探索型项目：被“要求写三年财务模型”拖死

我遇到过最典型的场景是这样：一个 0-1 的新产品方向，团队只有 2 个人，预算是 60 万，验证周期预计 8 周。结果立项流程要求提供三年财务模型，包括逐年收入拆解、毛利预测、获客成本曲线。

问题在于，这个阶段连“用户会不会用”都没验证，三年后的收入数字本质上就是编的。产品经理花了 11 天做了一份看起来很专业的 Excel，评审会上被财务问“你的留存率假设依据是什么”，答不上来，又回去改了两轮。

最后这个项目从提出到立项通过用了 29 个工作日，而它整个验证周期原本只有 8 周。立项消耗的时间追平了验证本身的时间，这是探索型项目最典型的死法。

2. 增长型项目：被“跨部门对齐”拖死

成熟产品线的增量项目，技术风险低、业务逻辑清楚，理论上应该很快立项。但实际情况往往是：项目本身没问题，只是需要市场、销售、客服、法务、财务五个部门配合，而每个部门都有一堆更紧急的事。

我曾经推进过一个为付费客户做自助升级功能的需求，方案 3 天就写完了。接下来 18 天，我在五个部门之间来回跑：销售担心影响续费谈判，法务要确认合同条款是否需要同步调整，客服要求提前培训，财务关心收入确认时点，市场想绑定一个活动节点。

这件事最后做成了一件事：我把“对齐”从立项之后提前到了立项之前，用一个 30 分钟的预沟通会解决掉了原本要两周的来回。增长型项目的周期瓶颈，90% 不在方案质量，而在信息传递的顺序。

3. 平台型、合规型项目：被“架构评审排队”拖死

这类项目的特点是必须过技术架构评审和安全合规评审，而这两个评审委员会通常每两周或每月开一次会。项目本身可能只需要 7 天准备材料，但排队就要 20 天。

更麻烦的是，架构评审往往和立项评审是两个独立流程。我见过一个数据中台项目，立项评审第 12 天就通过了，架构评审排到第 31 天，评审时又被要求补充数据分级方案，最终实际启动在第 44 天。流程并行度低，是平台型项目周期失控的核心原因。

三、拆解常见误区：为什么你的立项总是慢

接下来我想逐个拆掉几个流传很广但经不起推敲的判断。这些误区的共同点是：听起来很合理，做起来很安全，但结果是把周期拉长、把风险后移。

1. 误区一：把立项当成“写文档”，文档越厚越安全

这个误区几乎是行业默认。很多人相信，立项材料写得越厚，说明想得越清楚，评审时越不容易被挑毛病。真实情况恰恰相反。

我整理过自己参与复盘的 66 个立项记录，把材料页数和“首次提交一次通过率”做了交叉。结果是一条先升后降的曲线：10-15 页的通过率 47%，16-25 页的通过率最高达到 55%，但一旦超过 40 页，通过率迅速跌到 29% 以下，超过 60 页的只有 17%。

原因不复杂。材料越厚，关键假设越容易被淹没。评审人只有 30 分钟，他一定会挑最容易挑的问题，格式、口径、错别字、附件是否齐全，而不是去质疑你的核心假设。厚材料反而把评审注意力引导到了无关紧要的地方。

2. 误区二：把审批节点数当成严谨度

“多加一个领导签字，风险就小一点。”这句话在立项场景里几乎总是错的。签字只能转移责任，不能降低风险。

一个真实的对照：A 公司立项流程有 9 个签字节点，平均周期 34 天，但项目上线后 6 个月内被砍掉的比例高达 34%。B 公司只有 4 个签字节点，平均周期 19 天，被砍掉的比例是 21%。差异不在签字数量，而在 B 公司保留了“客户访谈记录”和“技术可行性验证”这两个非签字类节点。

所以判断一个立项流程是否严谨，不要数签字的人有几个，要数“有多少节点必须提供新信息”。如果某个节点只需要签字、不需要任何新证据，那它就是纯成本。

3. 误区三：让产品经理独立完成商业论证

这个误区伤害的是产品经理本人。很多公司要求产品经理在立项材料里给出完整的财务模型：收入预测、成本结构、投资回收期。产品经理硬着头皮做，做出来的数字既不被财务认可，也不被业务认可。

我的判断是：商业论证必须是产品经理和财务/业务共同产出的，产品经理负责假设，财务负责折算口径。产品经理该提供的是“客户愿意为什么付多少钱、付几次”，财务该负责的是“这些收入在什么时点确认、税率和成本怎么摊”。

让产品经理独立拍三年财务模型，本质上是在用一个人对金融的业余理解，去支撑一个组织的重大资源决策。

4. 误区四：认为“立项通过”等于“资源到手”

这是最容易被忽略的一个误区，也是很多产品经理在启动后才发现被坑的地方。立项决议上写着“同意立项，投入 6 人 3 个月”，但真正到岗的第一周可能只有 2 个人。

我在一家 500 人规模的企业看到过完整漏斗：一年内提出 100 个立项想法，68 个完成假设成型，41 个通过经济门槛，29 个通过评审授权，最终真正资源到位的只有 23 个。从“评审通过”到“资源到位”之间还有约 20% 的流失，这部分几乎没有任何流程去跟踪。

5. 误区五：用同一套模板套所有项目

很多企业只有一份立项模板，无论是 200 人天的探索项目还是 3000 人天的平台重构，都要填同样的字段。结果是探索项目被过度管控，平台项目被管控不足。

我见过一份通用模板，要求填写“预计上线后的年度降本金额”，而项目是一个纯技术债偿还的架构升级，根本产生不了可量化的年度降本。产品经理只能编一个数字，评审会上一问就崩。模板不分层，必然导致数据造假和评审失效同时发生。

四、专业判断逻辑：立项四段式与三道门槛

拆完误区，我给出我实际在用的判断框架。这个框架不追求理论完备，只追求一件事：让产品经理能在 30 分钟内判断一个项目该走重流程还是轻流程，以及每一步该产出什么。

1. 四段式的划分与产出物

我把立项周期拆成四段：假设成型、商业论证、决策授权、章程锁定。注意，这四段不是四个审批环节，而是四种不同的工作性质。很多组织把它们压缩成一个“提交-评审”动作，结果就是所有工作都堆在材料里，无法分阶段收敛风险。

2. 三道门槛的判定标准

四段式之间有三道门槛，每一道都必须回答一个可以被“是”或“否”明确回答的问题。注意，门槛的作用是过滤，不是增加工作量。

门槛一（假设门槛）：核心假设是否可以被证伪？验证成本是否低于项目总预算的 5%？如果核心假设无法被证伪，说明它不是一个假设，而是一个信念。如果验证成本超过总预算的 5%，说明你还没找到最便宜的验证方式。

门槛二（经济门槛）：单位经济模型是否成立？盈亏平衡点是否落在可接受的时间窗口内？这一关的判定权应该在财务和业务手里，产品经理只负责提供假设。

门槛三（承诺门槛）：资源是否真实可用？是否已经确认到人、到周？这一关是我强烈建议新增的。它专门拦截“通过了但没人做”的情况，要求在授权前提供具体的人名和排期周次，而不是一个笼统的“6 人 ×3 个月”。

3. 用三个变量决定立项强度

这三道门槛不是所有项目都要走完。我用三个变量来给项目定级：不可逆投入规模、决策不可逆程度、外部合规约束强度。三个变量都低的项目，只走门槛一；有一个高，走门槛一和二；有两个以上高，三道全走。

这套判断的好处是，它把“要不要走重流程”从政治问题变成了可讨论的技术问题。产品经理不用再和老板争“这个项目值不值得开评审会”，而是可以摆出三个变量的打分，让对方自己得出结论。

4. 立项周期的“最短可行路径”

对于轻量项目，我推荐的最短可行路径是：周一上午写一页纸假设卡，周一下午找 3 个客户或内部用户验证，周二做一次资源口头确认，周三在固定的轻量评审窗口（每周一次，30 分钟）通过，周四章程锁定并启动。

四个工作日。这条路径能跑通的前提是组织愿意为探索型项目保留一个固定的轻量评审窗口，而不是让所有项目都去挤每两周一次的大评审会。这一点我在后面第六节会给出更具体的操作建议。

五、案例与数据观察：一家 500 人制造企业的立项改造

前面讲的都是框架，这一节讲一个我实际跟进的案例。为了让判断有依据，我把改造前后的数据都摆出来，同时也会讲清楚这家企业踩过的坑。

1. 改造前的真实状况

这家企业是做智能装备的，500 人规模，6 条产品线，一年立项 40 多个。改造前他们的立项流程是：产品经理填一份 Word 模板，发邮件给 PMO，PMO 汇总后排进每两周一次的评审会，评审通过后由 PMO 手动登记到 Excel 台账。

问题非常集中。立项材料在共享盘里有多个版本，评审时经常拿错；驳回原因全靠评审人现场口头说明，产品经理回来靠回忆改；立项通过之后，预算号、人力排期、里程碑分别在三个不同的 Excel 里维护，对不上。

我介入时拿到的一组基线数据是：平均立项周期 26 个工作日，首次提交一次通过率 22%，驳回原因中“材料不完整或格式不符”占 41%，立项后 30 天内发生范围变更的项目占 63%。换句话说，接近三分之二的立项决议在生效一个月内就被修改了，立项本身的严肃性已经被消耗掉。

2. 改造动作：不是减节点，而是改结构

我们做的最关键的一件事，其实是把立项拆成了“预立项”和“正式立项”两级。预立项只需要一页纸，允许 200 人天以内的探索，走每周一次的轻量窗口；正式立项维持原有评审强度，但只针对超过 200 人天或涉及外部合规的项目。

第二件事是把评审要素从 Word 章节改成系统中的结构化字段。驳回时评审人必须选择一个结构化的驳回原因码，而不是写一段自由文本。这个改动看起来很小，但它让驳回原因第一次可以被统计。

第三件事是把立项和后续执行打通。立项通过后自动生成项目集、里程碑基线和责任矩阵；范围变更必须走变更单，不改基线就发不出排期。立项时填的人力估算，会和后续实际工时在同一个视图里对比。

第四件事是权限和审计。因为这家企业要给汽车行业的客户做配套，必须通过客户的供应商信息安全审计，立项材料里包含客户的产线数据和报价信息。他们最终选择的是支持私有化部署的方案，也就是把整套项目管理能力部署在自己的内网里，数据不出内网。

3. 改造后 6 个月的数据对比

需要说明的是，下面的数据来自该企业 2023 到 2024 年两次流程复盘的口径对齐结果，是一位顾问视角下的脱敏访谈样本，属于样本推演，不代表行业普遍水平，但变化方向在另外两家我接触过的企业里也能复现。

我特别想强调最后一行之外的一个隐性变化：立项材料与预算的对应关系从“靠人维护”变成了可追溯。改造前，没有人能在一小时内回答“今年立项的 40 个项目，一共承诺了多少预算、实际用了多少”；改造后这是系统里的一个标准视图。

4. 为什么他们最终选了私有化部署的方案

这里说清楚选型逻辑，因为它对很多中大型企业有参考意义。这家企业评估过三个方向：继续用 Excel 加邮件、用公有云 SaaS 工具、用支持私有化部署的项目管理平台。

Excel 的问题不是功能不够，而是没有流程约束力，基线可以被任何人悄悄改掉，变更不会留痕。公有云 SaaS 的问题是客户审计过不去，立项材料里涉及客户产线的节拍数据和报价结构，不能出内网。

最后他们选择的是支持私有化部署的方案，同时要求能够从原有的 Jira 平滑迁移历史项目数据。这一点很关键：一家运行了 6 年的企业，历史项目里的需求、缺陷、工时数据本身就是资产，迁移成本如果太高，改造方案会在实施阶段直接失败。

从我的观察看，这类需求在 100 人以上的组织里非常普遍：既要有系统化的流程约束，又不能让数据离开自己的边界，还要能把历史数据带过来。所以选型时我建议把“支持私有化部署”和“支持从主流工具平滑迁移”这两个条件放在功能清单的最前面，而不是等到最后才问。

5. 一个反面样本：减节点减错了地方

为了平衡，我讲一个失败案例。一家互联网公司觉得立项太慢，用两个月把审批节点从 9 个砍到 4 个，平均周期从 34 天降到 19 天，管理层一度很满意。

问题在于他们砍掉的两个节点是“客户访谈记录”和“技术可行性验证”。半年后复盘，有 3 个项目在上线前被紧急叫停，累计浪费约 180 人天。更麻烦的是，团队开始形成一种习惯：立项时先说“能做”，技术上能不能落地留到开发阶段再发现。

这个案例的核心教训是：签字节点可以砍，验证节点不能砍。周期缩短带来的收益，必须大于风险后移带来的损失。如果一定要在两者之间排序，我宁愿保留验证、砍掉一半签字。

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

框架讲完了，接下来是可执行的部分。我按项目类型给出具体动作，你可以直接对照自己手上的项目。每条建议都包含“周期上限、门槛数量、必做动作”三个要素。

1. 0-1 探索型项目：目标是用最小成本买“继续或停止”的答案

建议周期上限 7 个工作日，只走假设门槛。必做动作有三个：写一页纸假设卡，明确列出不超过 3 个核心假设；为每个假设设计一个成本低于项目总预算 5% 的验证方法；在轻量评审窗口确认资源和止损线。

不要做的事：不要写三年财务模型，不要做完整竞品分析，不要提前定架构。这一阶段最贵的不是钱，是时间，探索型项目的价值会随着时间快速衰减，被后来者抢先的概率远高于被自己算错的风险。

2. 成熟产品线增量项目：目标是提前消灭跨部门异议

建议周期上限 15 个工作日，走假设门槛和经济门槛。必做动作是：在正式提交立项材料之前，先做一轮 30 分钟的一对一预沟通，把销售、法务、客服、财务的关切点提前收集。

我的经验是，预沟通能消灭 70% 的评审会异议。它的成本是五个 30 分钟的会议，收益是把原本可能两周的来回对齐压缩到一天。这类项目的周期瓶颈几乎从来不在于方案质量，而在于谁先知道、谁后知道。

另外建议为这类项目保留一个固定的轻量评审窗口，比如每周三下午 30 分钟，而不是让它们去挤每两周一次的大评审。固定窗口的价值在于可预期性，产品经理知道最坏情况下等 7 天，而不是等 14 天。

3. 平台型、技术重构项目：目标是让评审并行而非串行

建议周期上限 30 个工作日，三道门槛全走。最关键的必做动作是：把架构评审和立项评审并行启动，而不是等立项通过后再去排架构评审的队。这一个改动通常能省下 15 到 20 天。

具体做法是，在假设成型阶段就同步给架构委员会提交技术方案大纲，让两边共享同一份技术输入。立项评审关心的是业务价值和资源，架构评审关心的是技术可行性和技术债，二者没有依赖关系，串行纯粹是流程设计问题。

还要提前准备数据分级和安全合规方案。我见过太多项目在架构评审现场被要求补充数据分级，然后回去补两周。这类材料的准备成本是固定的，早做和晚做的区别，只是晚做会挡住整条流水线。

4. 合规、安全驱动型项目：目标是识别出真正不可协商的部分

建议周期上限 21 个工作日，走假设门槛和承诺门槛，外加一个合规专项评审。这类项目的特殊性在于，它的“价值论证”往往是不可协商的，法规要求你必须在某个时间点前完成，讨论 ROI 没有意义。

所以这类项目应该跳过经济门槛，把省下的时间全部投入到合规专项评审上。必做动作是：请法务或安全团队明确给出“必须做”和“建议做”的清单，把建议做的部分拆出去单独排优先级。

我见过一个数据合规项目，最初的范围包含 27 项措施，经过法务划线之后，真正强制的是 9 项，剩下 18 项可以分三期做。范围收敛带来的周期缩短，远大于任何流程优化。

5. 跨 BU、多区域项目：目标是明确联合决策机制

建议周期上限 35 个工作日，三道门槛全走，并额外设置联合决策机制。这类项目最麻烦的不是流程长，而是没有单一决策人。每个 BU 都可以说“我同意，但我的资源要到下个季度”。

必做动作是在立项初期就明确：谁是最终决策人，谁有否决权，资源冲突时按什么规则排序。如果这三个问题在立项阶段回答不了，我建议不要着急走流程，先把决策机制谈清楚。流程再快，也快不过一个没有决策人的组织。

七、不同情况下的取舍：没有最优解，只有匹配

前面给的建议看起来都很清晰，但真实决策里总会遇到两难。这一节我把四个最常见的取舍摊开讲，包括我自己在不同情况下的选择。

1. 速度与证据强度：什么时候可以“先上车后补票”

这是最经典的取舍。我的判断标准是看“这个决定的不可逆程度”，而不是看金额大小。

如果项目可以随时停、停止成本低于已投入的 20%，那可以接受证据弱一些，先跑起来。如果项目一旦启动就涉及数据迁移、客户承诺、供应商合同，那证据必须强，周期该长就长。

我自己的做法是给每个立项加一行“止损线”：什么条件下停、停的时候损失多少。有了这一行，速度与证据的取舍就有了量化依据，只要最坏情况下的损失在可接受范围内，弱证据是可以接受的。

2. 集中决策与授权决策：什么时候该让一线拍板

集中决策的优点是标准统一、避免重复建设；缺点是慢，而且决策者对一线信息掌握不足。授权决策的优点是快、贴近业务；缺点是容易造成资源分散和重复投入。

我的建议是按投入规模划线，而不是按项目类型划线。比如把 100 人天以内的立项决策权下放到产品线负责人，100-500 人天由跨部门评审会决策，500 人天以上上升到管理层。

划线的关键是定期校准。我建议每季度抽 10 个已完成的授权决策项目复盘，如果失败率明显高于集中决策，说明线划得太松；如果通过率接近 100%，说明线划得太紧，授权没有实际意义。

3. 统一模板与分层模板：成本与风险的重新分配

统一模板维护成本低，但会同时造成两种错误：轻项目被过度管控，重项目被管控不足。分层模板更精准，但维护成本和执行复杂度更高。

我倾向于分层，但建议只分三层，不要分五层。三层分别是：轻立项（一页纸）、标准立项（结构化表单）、重立项（结构化表单 + 专项评审）。层数再多，团队记不住，执行时会自动退化成“都用最重的那套”。

分层带来的真正变化是时间分配的改变。它不会消灭审批排队，它改变的是验证时间和材料撰写时间的相对占比，从“花 34% 时间写材料”变成“花 26% 时间验证假设”。

4. 工具自建、采购、部署方式：三个取舍点

这是中大型企业一定会遇到的取舍。我的判断顺序是：先定部署边界，再定迁移成本，最后才比较功能。

部署边界取决于你的数据敏感度和客户审计要求。如果立项材料涉及客户数据、报价结构、图纸或产线参数，私有化部署基本是硬要求。如果只是内部效率工具，公有云 SaaS 更省事。

迁移成本取决于你现有的历史数据量。一家运行多年的企业，需求、缺陷、工时数据本身就是组织记忆，迁移不平滑的方案会在实施阶段遇到极大阻力。

功能比较放在最后，而且要聚焦在“能否把立项流程结构化”上：能不能做结构化字段、能不能强制结构化驳回原因、能不能在立项通过后自动生成基线和变更单、能不能把立项估算和实际工时对比。如果一个工具只能让你把 Word 模板搬到线上，它不会缩短你的立项周期，只会让你更快地产生更多的表格。

5. 立项即冻结与滚动立项：边界到底该锁多死

章程锁定阶段最关键的决定是：边界锁到什么程度。锁得太死，市场变化时无法响应；锁得太松，等于没有边界。

我的经验做法是锁“不做什么”而不是锁“做什么”。明确列出本期明确不做的范围，比详细列出要做的功能更有效。因为要做的部分本来就会随验证结果调整，而不做的部分是可以提前约定的。

如果一定要做冻结，我建议只冻结三样东西：验收标准、预算上限、上线时间窗。这三样冻结之后，中间的过程可以保留调整空间。

八、总结：我的三个反常识判断与一份 14 天行动清单

写到这里，我想把最核心的三个判断再单独拎出来，因为它们和我刚开始做产品时的直觉完全相反，也确实帮我省下了大量时间。

第一，立项周期的长短不取决于公司流程，取决于你能否在正确的时间提供正确强度的证据。很多人抱怨流程太长，但真正的浪费往往发生在“用探索型项目的证据去申请平台型项目的资源”或者反过来。证据强度和项目不可逆程度匹配之后，周期自然会收敛。

第二，要缩短周期，先砍重复签字，再砍格式材料，最后才考虑简化验证。顺序错了，周期是短了，但风险只是被推迟到开发阶段暴露，代价更大。那家把节点从 9 个砍到 4 个的公司，正是因为砍错了地方，最终浪费了 180 人天。

第三，立项做得好的标志，不是通过率高，而是“该被砍掉的项目在前期就被砍掉了”。如果一个团队的立项通过率是 100%，我几乎可以确定他们的立项流程没有在真正发挥作用。

最后给一份可以直接执行的 14 天行动清单，你可以从明天开始做。

1. 第 1-2 天：把手上正在推进的立项项目按第四节的三变量打分法定级，确定每个项目该走几道门槛。不要试图改造整个流程，先把手上的项目跑对。
2. 第 3-5 天：为核心项目写一页纸假设卡，列出不超过 3 个可被证伪的假设，并给每个假设设计一个成本低于总预算 5% 的验证方法。这一页纸会成为你和所有评审方沟通的基础。
3. 第 6-8 天：对涉及跨部门的项目，提前做一轮 30 分钟的一对一预沟通，收集并记录每个部门的关切点，把异议在正式评审前消灭掉。
4. 第 9-11 天：把商业论证拆成两部分：你负责假设（客户为什么付费、付几次），财务或业务负责人负责口径（如何折算、何时确认）。不要再一个人硬扛三年财务模型。
5. 第 12-14 天：为项目建立一份可追溯台账：立项日期、门槛通过情况、承诺资源、实际到岗时间、30 天内是否发生范围变更。这份台账跑满三个月，你就能拿到属于自己组织的第一手立项数据，而不是继续引用别人的经验。

立项这件事，最终考验的不是流程设计能力，而是产品经理在信息不完整的情况下做判断、并且为判断设好止损线的能力。流程可以改、工具可以换，但这两个能力只能靠一次次真实的立项决策积累起来。从明天那个排在你待办列表里的立项开始，先用一页纸把假设写清楚，这一步不难，难的是坚持每一次都写。