首席产品官六问把关

为什么需要这六个问题

季度路线图承诺会前，团队最常犯的错误是把功能列表当战略：有人主张加功能，有人凭调研说"用户喜欢"，留存曲线已经走平却还在争论"要不要做 X"。/cs:cpo-review 针对的正是这个场景——用六个强制问题（forcing questions）逼团队在动工前把假设写清楚，而不是等上线后用数据打脸。它不评估方案的实现细节，而是审查每个候选功能是否真的被用户"雇佣"来完成某个工作（JTBD）。

六个问题的核心逻辑

每个问题都有明确的判定标准：

• JTBD：功能要完成的工作必须用用户的语言描述，例如"帮新运营经理在 7 天内签下第一单"，而不是"优化新手引导"。工作不等于功能，雇佣不等于试用。
• North Star Metric：该功能推动的用户行为必须是先导性、基于行为、与价值相关的，且能向上汇聚到北极星指标。追不上北极星的功能不立项。
• PMF Signal：只看真实留存曲线——走平或上扬才算 PMF 信号，衰减就是没有；调研里的"用户喜欢"不算数。
• RICE Score：给 Reach、Impact、Confidence、Effort 打分，并明确该功能在队列中的位置。
• Opportunity Cost：写下如果上线这个功能，具体砍掉哪个项目。人力和时间是零和的，砍掉的清单就是聚焦的清单。
• Kill Criteria：在上线前以书面形式定义指标和阈值，回答"90 天后什么信号说明这是个错误赌注"。

工作流与输出边界

技能按三步走：先运行相关分析，再逐一回答六个问题，最后给出明确裁决。它还会路由到相邻技能：/cs:cmo-review 检查定位是否支持该功能，/cs:execute 负责执行 90 天计划，/cs:post-mortem 在触发 kill 条件时做复盘。

需要注意：这六个问题是审查框架而非分析工具——留存数据、RICE 评估需要团队自己准备，技能不会替你算。Kill criteria 必须在上线前落笔，无法定义停止标准，就谈不上负责任地发布。