一句话总结
判断一个项目是否值得投入，核心不是“数据好看”，而是“用户痛点是否真实”。不是盲目追求技术深度，而是先锁定价值链的关键节点；不是单轮评审决定成败，而是五轮结构化对话共同验证。正确的判断是：只要在第一轮能明确“谁在受苦、为什么受苦”，其余四步自然收敛为可执行的路线图。
适合谁看
本篇针对的读者画像为：
- 已在硅谷担任PM 2年以上，正准备晋升或跳槽的中层产品负责人；
- 正在组建跨部门新业务的创始人或CTO，需要快速评估项目可行性；
- 在大型互联网公司担任Hiring Committee成员，需要在面试中做出“是否进入下一轮”的裁决。
如果你经常在debrief会议里被问“这件事到底值不值得继续？”或在HC里被迫在几分钟内给出“通过/不通过”结论，那么本框架正是你的裁决工具。
核心内容
1. 痛点验证——不是“假设”，而是“证据”
在任何项目启动的第一步，必须把用户痛点从“我们觉得需要”转化为“用户已经在为之付费”。
场景：在一次跨部门冲刺会议上，Growth Lead 把一张用户流失曲线展示给我。她说：“我们发现 30% 的新用户在第 3 天就流失”。我立刻追问：“这 30% 中，有多少是因为功能缺失？”她答：“只有 12% 提到功能缺失，剩下的都是注册流程繁琐”。这时，我在白板上写下两条结论：
- 不是“功能缺失导致流失”，而是“注册流程的摩擦导致流失”。
- 不是“整体流失率高”，而是“特定节点的转化率低”。
随后，我们用 Mixpanel 设置了注册路径的 A/B 实验，24 小时内收集到 5,000 条真实点击数据。实验结果显示，简化验证码步骤后，转化率提升 18%。这一步的裁决是：项目进入下一轮，因为痛点已经被硬数据证实。
2. 市场容量评估——不是“行业报告”，而是“可支付用户数”
很多 PM 直接引用行业报告的 TAM 数字，结果常常高估 3 倍以上。正确的做法是把 TAM 切到可支付用户（SAM）层面，再乘以我们能够捕获的市场份额（SOM）。
场景：在一次 HC 讨论中，Hiring Manager 把一份 2023 年 AI 市场报告递给我，报告声称 TAM 为 500 亿美元。我立即指出：“这不是我们要的数字”。
随后，我展示了我们内部的用户画像：年收入 10 万美元以上的中小企业共 8,000 家，每家平均愿意为 AI 自动化付费 2,000 美元。计算后，SAM 为 1.6 亿美元，假设我们第一年能捕获 5% 市场份额，SOM 为 800 万美元。
此时，面试官问我：“若竞争对手同样提供相似功能，你的优势是什么？”我回答：“我们的优势在于 API 即插即用、部署时间 < 48 小时”。这一步的裁决是：在可接受的商业规模内继续，而不是盲目追随宏观报告。
3. 技术可行性审查——不是“技术炫酷”，而是“交付时限”
技术团队常用“我们可以做到”来掩盖交付风险。真正的审查要把技术路线拆解成里程碑，并用时间盒验证。
场景：在一次 debrief 中，我让负责后端的同事列出实现关键功能的三步走：① 数据管道搭建（2 周），② 实时推理服务（3 周），③ 前端可视化（1 周）。他给出的总时间是 6 周，但我要求他把每一步的风险点写在白板上：① 第三方日志服务 API 限流、② GPU 资源争抢、③ 前端图表库兼容性。
我们决定采用“技术原型+时间盒”策略：先在内部数据集上跑一次端到端原型，时间不超过 2 周。结果显示 GPU 争抢导致延迟 30% 超标，于是我们改用混合云方案，及时把风险降到可接受范围。判断是：技术可行且风险已量化，因此进入下一轮。
4. 商业模型构建——不是“单一收入”，而是“多维度变现”
很多项目在商业模型阶段只给出“一次性付费”。真实的可持续增长往往需要订阅、增值服务和数据变现三条线。
场景：在一次 Hiring Committee 的案例评审中，我要求候选人展示 3 年的财务预测。候选人只列出“一次性授权费 50 万”。我直接指出：“这不是可持续的商业模型”。随后，我在白板上画出三条收入曲线：① SaaS 订阅（每月 2,000 美元），② 高级 API 调用（每千次 5 美元），③ 数据洞察报告（每年 10,000 美元）。
我们用 LTV/CAC 计算得出：在第 18 个月 LTV 达到 30,000 美元，CAC 约 4,500 美元，利润率 85%。基于此，我裁定：商业模型已具备多维度变现能力，可以继续推进。
5. 运营落地计划——不是“理想状态”，而是“可执行路径”
最后一步是把前四步的结论转化为明确的里程碑、资源需求和 KPI。
场景：在一次跨部门的 Roadmap 评审会上，我让每个职能写下 3 项关键指标（KPI）和对应的资源预算。Growth 团给出 CAC < $30、转化率 > 5%；Engineering 给出 99.9% SLA、每月发布 2 次；
Design 给出 NPS > 70。随后，我把这些 KPI 汇总到一个 OKR 表格中，明确每个 KPI 的 Owner、截止日期和评估频率。
面试官追问：“如果二季度 CAC 突破 $40，怎么办？”我回答：“触发风险评审，重新评估渠道投入和产品定价”。这一步的裁决是：运营计划已落地，且有明确的风险应对机制，项目进入执行阶段。
> 📖 延伸阅读：Uber SDE系统设计面试攻略
准备清单
- 明确用户痛点的第一手访谈记录（不少于 10 份），并用数据可视化呈现。
- 计算 SAM/SOM 的 Excel 模型，列出关键假设来源。
- 技术原型时间盒计划（2 周内完成），并准备风险矩阵。
- 商业模型 3 年财务预测表，包含 LTV、CAC、毛利率。
- OKR 表格，列出每个职能的关键 KPI、Owner、评估频率。
- 系统性拆解面试结构（PM面试手册里有完整的“项目评估实战复盘”章节可参考），帮助在面试中快速展示 5 步框架的逻辑。
- 预留 10% 预算用于突发技术或市场风险。
常见错误
错误一：把宏观 TAM 当作项目可行性依据
BAD：在 HC 中直接引用行业报告的 500 亿 TAM，结论是“项目一定有价值”。
GOOD：先把 TAM 切到可支付用户层面，展示 SAM 为 1.6 亿，再用合理的 SOM（5%）说明实际收入潜力。
错误二：技术评审只看“是否能实现”，忽视交付时限
BAD：后端同事说“我们可以在两周内实现全部功能”，没有列出风险点，导致后期交付延误。
GOOD：把实现路径拆成里程碑，给每一步标注时间盒和风险点，并用原型验证关键路径。
错误三：商业模型只跑一次性付费，缺乏持续收入预估
BAD：财务预测只列出“一次性授权费 50 万”，忽视运营成本和后续收入。
GOOD：构建 SaaS 订阅、增值 API、数据报告三条收入线，计算 LTV/CAC，展示 85% 毛利率的可持续增长。
> 📖 延伸阅读：Robinhood vs Coinbase结算系统对比：中国金融科技PM的合规设计
FAQ
Q1：如果在痛点验证阶段只能拿到访谈笔记，缺乏量化数据，是否还能继续？
A：正确的裁决是 暂停，因为没有量化证据无法区分“噪声”与真实需求。曾有一次我们在初创公司内部评审时，仅凭 3 份访谈就决定进入下一轮，结果上线后 3 个月内活跃用户仅 2%。后来我们回到原点，重新做了 20 份访谈并加入行为数据，才发现真实痛点是 “账单提醒不及时”，项目才得以成功。
Q2：技术原型出现性能瓶颈，时间盒已到，但仍未达标，是否应该直接放弃？
A：不是直接放弃，而是 重新评估技术路径。在一次内部 Hackathon 中，我们的实时推荐系统原型在 2 周内达到 80% 的响应时间目标，但仍低于 200ms。团队决定在第 3 周引入混合云 GPU，性能提升到 150ms，项目得以继续。关键在于有明确的风险缓冲和后备方案。
Q3：商业模型的 LTV/CAC 计算时，如果 CAC 大幅波动，如何在面试中给出可信的判断？
A：不是仅给出单一数值，而是 提供区间和敏感性分析。在一次 Google 的 PM 面试里，我展示了 CAC 在 3,000–5,000 美元区间的敏感性图，说明在渠道优化后 CAC 可降至 3,200。面试官最终认可了我对风险的量化能力，说明在不确定环境下提供区间比绝对值更具说服力。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。