立项与机会判断：项目为什么做
本篇解决的问题：一个听起来非做不可的需求，怎么在写第一行代码之前判断它值不值得做、为什么是现在做、为什么是我们做、什么证据出现就该收手？
本文核心：把「为什么做」拆成四种价值，再用时机三条件、反立项意见把它写成一页能接受质询的《产品立项判断》。写不出的那一项，就是判断缺口。
故事：一个听起来非做不可的需求
先认识「研习」团队——一款面向考研学生的记录工具，四十人，产品经理小林、数据分析师老周、运营阿May、研发组长大鹏、客服主管小雨。月活约八万，付费转化约 3%（教学假设）。
故事从一次周会开始。小雨把一周的客服工单投到屏幕上，二十多条反馈里有一半在说同一件事：「每次做完题，错题都要自己一张张拍照、手动分类，太烦了。能不能拍个照就自动整理好？」
小林眼睛亮了：「这不就是切入点吗？用户上传照片、系统识别、按科目归类、按遗忘曲线排进复习计划。拍照本来就发生在学习现场，很自然。」
大鹏估了估：「识别接口是现成的，先做单题识别和归类，两周能灰度。」阿May更直接：「这功能能提高打开频率，宣传有故事讲了。」
没人反对。这个需求听起来太好了：省下重复劳动，还能让产品从「被动记录」变成「主动参与学习」。只有老周小声补了一句：「听起来是对的。但『听起来对』和『现在该做』，中间还隔着一点东西。」
这句话当时没人接。两周后，大家才明白它的分量。
第一幕：先做出来，然后对着 4% 发呆
团队选了最直接的做法：先做功能。接通用识别接口，用户上传图片，系统给科目和归类，用户手动确认。范围压得很小——不做整页识别，不做手写体，先解决「拍照归集」这一件事。两周后灰度上线，覆盖约一万名用户（教学假设）。
结果不理想。真正用过的只有约四百人，占灰度用户的 4%；这四百人里约六成只传了一张图，再没回来。
数字摆在桌上，没人能立刻说清原因。小林说「至少说明有人需要吧」，老周摇头：「也可能说明，这需求只集中在极少数人身上。」
同一组数字，至少能讲出四种完全不同的故事：
- 需求是真的，但用户已有更省事的替代方案——纸质错题本、相册截图合集。拍照归集比这些麻烦，试一次就走了。
- 需求是真的，但自动识别错得太多。传一张还要自己改来改去，不如手抄。
- 用户要的根本不是「归集错题」，而是「考前能快速复习重点」。归集只是中间环节，没解决最后那个结果。
- 需求只对极少数重度用户成立。对整体八万用户，大部分人一周也没几道错题。
四种解释指向四种完全不同的下一步。团队卡住的不是「做不出来」，而是「说不清为什么做」。
这就是立项和直接开发的差别：直接开发，你验证的是「这功能能不能做出来」；先立项，你验证的是「这功能值不值得被做出来」。前者用代码回答，后者用证据回答。
第二幕：把「为什么做」拆成四种价值
回到灰度之前。如果当时团队先回答「这个问题是否值得由我们现在解决」，事情会不一样。
腾讯公开材料里反复出现几类判断角度，整理成四种价值。立项要做的第一件事，就是把这四种价值分开写，而不是只写一句「用户提过」。
用户价值，回答解决的是谁、在什么场景里的什么困难。 很多立项材料一上来就写功能：我们要做错题自动归集。但功能不是价值。用户价值要写到「谁、在什么时候、因为什么而难受」。比如：考研学生每天结束学习后的十五分钟里，能把当天错题低成本留存并分类，而不是花二十分钟手动抄写。
产品价值，回答解决之后产品的核心能力是否增强。 研习的核心能力是「复习计划」。所以问：错题归集之后，复习计划是不是更准了？还是只是加了一个相册入口、和复习计划没真正连起来？这条最容易被跳过，但它是判断「该不该由我们做」的关键。用户很需要、却和核心能力无关的功能，更适合单独做成工具，而不是长在这款产品里。
业务价值，回答它怎样影响增长、收入、成本或风险。 写具体数字假设，不能只写「提升留存」。比如：能否把次日留存提高两个百分点？能否减少客服「怎么整理错题」类工单量？每一条写成「如果……那么……」的形式，并标明是假设。
社会价值，回答它是否伤害用户、生态或长期信任。 错题归集要把用户图片交给外部识别服务，用户可能不知道笔记会被传到哪里。处理不好，省下的时间要用隐私和信任来还。社会价值不是道德口号，是真会反噬业务的东西。
四种价值不必每次都一样重，但底线是：不能只剩「老板想做」和「竞品已经做了」这两句。立项页只写了这两句，等于没有立项判断。
回到研习，试着填一遍：
- 用户价值：考研学生在每天学习结束后，能低成本留存并归类当天错题，而不是手动抄写。
- 产品价值：归集后的错题能否直接进入复习计划，让计划覆盖「错过的题」，而不仅是「收藏的题」。
- 业务价值：假设次日留存提升两个百分点，或客服相关工单每周减少十单（教学假设）。
- 社会价值：用户图片会上传外部识别服务，需说明用途与删除机制，避免长期信任受损。
写完这一页，你会立刻发现哪里是空的。写不出的那一项，就是判断缺口。
第三幕：时机不是市场热度
四种价值回答「为什么做」，还缺一个时间维度：为什么是现在，而不是半年前，也不是再等三个月。
腾讯8分钟产品课把时机拆成三个条件：行业环境、用户认知、能力储备。
行业环境：技术、社会、经济或政策是否出现了变化。对错题归集来说，通用图像识别已开放到可低成本接入，这就是一次环境变化——几年前想做，接口成本和识别质量都撑不住。
用户认知：用户是否已理解并愿意采用新行为。学生是已经习惯用拍照留存资料，还是仍依赖纸笔？如果大多数学生连「拍照整理」都没养成，教育市场的成本就很高。
能力储备：团队的技术、产品和组织能力是否到位。研习有没有人能调校识别准确率？有没有人能设计好「归集」和「复习计划」之间的连接？
用移动支付看同样的结构：移动网络和智能手机是行业环境；用户愿意扫码是认知基础；支付能力、账户体系是能力储备。三个条件合在一起，才让移动支付在某个时间点成立。
把这三条落成一张检查表：
| 问题 | 最低证据 |
|---|---|
| 用户现在为什么受阻 | 访谈、行为观察、客服记录或数据异常 |
| 不解决会发生什么 | 流失、低效、成本、风险或机会损失 |
| 现有替代方案为什么不够 | 用户实际采用的替代路径及其代价 |
| 为什么是现在 | 环境、认知或技术能力发生了什么变化 |
| 为什么由我们解决 | 数据、渠道、技术、品牌或组织优势 |
| 怎样判断做成 | 一个结果指标和至少一个护栏指标 |
时机判断里最常见的错误，是把「竞品已经做了」当成「时机到了」。竞品上线，只能说明它判断时机到了，不能说明我们的用户认知已经成熟。这两件事经常被混在一起。
第四幕：先写反立项意见
到这一步，材料越来越多，也越来越像那么回事。但有个隐蔽的陷阱：一个方案，在支持者整理的材料里，总是显得特别合理。 客服工单是支持它的，竞品动作是支持它的，识别接口降价也是支持它的。这不是因为这些证据更可靠，而是因为你收集它们的时候，心里已经有了答案。
所以立项要人为地打断一下：必须先写反对意见。否则立项会就会变成一场「用支持材料说服自己」的仪式。
对错题归集，可以写出三条反对意见：
- 问题可能只影响很小的人群。 也许只有极少数每天刷大量题的学生，才有「错题多到需要工具归集」的烦恼。
- 用户可能已有成本更低的替代方案。 纸质错题本和相册截图几乎零学习成本，而且不依赖任何工具。
- 即使功能被使用，也未必改善最终结果。 归集了错题，不等于复习了错题；如果复习计划没真正接上，前面的归集都是白费。
写反立项意见不是为了唱反调，而是给每一条意见配一个能推翻它的证据。一条合格的反立项意见，后面必须能接上一句「如果……成立，那么我们应该观察到……」。 比如第一条可以配：如果只是小人群问题，那么错题上传量应集中在极少数用户身上；如果大量用户都有低频但稳定的整理行为，这条意见就被削弱了。配不上证据的反对意见，不是真正的怀疑，只是情绪。
反立项实验：动工前就能做的便宜验证
反立项还能变成一个动工前的实验。先把假设写具体：用户已经在归集错题，只是现有方式成本过高。如果成立，通常能看到某种低效的手动行为——相册里的截图文件夹、纸质错题本、一张整理错题的表格。
那么在开发之前，先看两样东西：一是相册截图的上传数量，二是问卷里「你目前怎样整理错题」的回答分布。如果大多数用户根本没有整理行为，「手动成本过高」就被削弱了，团队要追问：用户是没有需求，还是因为不知道方法、缺少时间而没行动？这决定是停止，还是改写立项。
这个实验便宜——不用写代码，翻翻已有数据和问卷就能做；但它只能证伪一部分假设。它能回答「用户是否已经在做这件事」，不能回答「用户是否愿意用我们的方式做」。后者，交给下一讲的需求验证。
如果团队在动工前做了这个实验，最坏的结果是花一个下午发现方向错了，省下两周开发和一次失败的灰度；最好的结果是找到证据证明「有人在做，只是做得辛苦」，带着更准的问题进入开发。无论哪种，都比上线后对着 4% 的使用率猜原因要便宜。
第五幕：把判断写成五步
把前面的内容收成五步。每一步都不是「读一遍就会」，而是要落到研习这个案例上走一遍。
第一步，写下原始提议，保留提出者的原话。 别一上来就写「用户需要错题管理能力」。把小雨那句原话留下：「拍个照就能自动整理错题，不用自己分类。」这句话才是证据，后面所有判断都要回到它。
第二步，拆成四种价值，逐项写清角色、场景、困难与结果指标。 哪一项填不出来，就先标红，不要跳过。填不出来的那一项，就是这次立项最薄弱的地方。
第三步，核对时机三条件，分别写行业环境、用户认知、能力储备的证据。 每条都要有事实，不能只写「技术成熟了」。写不出来，就说明「为什么是现在」还没有答案。
第四步，写三条反立项意见，并为每条配一个可推翻它的证据或实验。 三条意见要互相独立，不能是同一件事的三种说法。
第五步，定出最关键假设，以及一次小规模验证的动作和停止条件。 最关键假设只能有一个。对研习来说，不是「识别准确率能不能做到 90%」，而是「考研学生是否真的在手动整理错题，并且为此感到麻烦」。前者是工程问题，后者才是立项问题。
模板：一页《产品立项判断》
这张表可以直接抄走。填的时候，记得把「教学假设」和「来源事实」分开标，不要用假设冒充事实。
产品立项判断
目标用户与场景：
观察到的困难：
问题造成的结果：
当前替代方案及其代价：
用户价值（谁、场景、困难）：
产品价值（核心能力是否增强）：
业务价值（增长/收入/成本/风险指标）：
社会价值（是否伤害用户或长期信任）：
行业环境证据：
用户认知证据：
能力储备证据：
反立项意见一（及可推翻它的证据）：
反立项意见二（及可推翻它的证据）：
反立项意见三（及可推翻它的证据）：
最关键假设：
成功指标与护栏指标：
下一步最小验证：
停止或改写条件：
填完这张表，找一位不看好这个项目的人来读。对方挑出的第一个问题，往往就是你该优先补的证据。
常见误区
立项的坑不多，但每个都藏在「感觉合理」的背后。
- 把「用户提了」当成立项依据。 客服工单和小雨的转述都是线索，不是证据本身。把线索当证据，可见后果是功能上线后无人使用——提议者和使用者往往不是同一群人。
- 把竞品动作当成时机。 竞品上线不代表我们的用户认知已成熟。跟进的团队常在无替代方案优势时投入，最后只能靠更低价格或更多曝光拉量，这不是立项，是跟随。
- 只收集支持材料。 你在会上越讲越兴奋，往往是因为只看了支持证据。立项会顺利通过，上线后却撞上那个被忽略的反例。
- 把立项通过当成开始完整开发。 立项通过只说明「值得为最关键假设付一次小验证的成本」。为十几个次要假设一起投入，最关键假设反而没被单独验证。
- 把「我们有这项能力」当成立项理由。 能力储备只是时机三条件之一，能力再强也替代不了用户价值和业务价值。会做，不等于该做。
本篇总结
| 核心动作 | 一句话 |
|---|---|
| 四种价值 | 把「为什么做」分开写，写不出的那一项就是判断缺口 |
| 时机三条件 | 行业环境、用户认知、能力储备，逐条要证据，别拿竞品当时机 |
| 反立项意见 | 每条反对意见都要配「如果……成立，那么应该观察到……」的证据 |
| 最关键假设 | 只能有一个，且能被一次便宜的小验证直接检验 |
立项判断不是成功预言。它不能证明产品会成功，也不能证明需求真实存在。它只能说明一件事：团队有理由，为最关键假设支付一次小规模验证的成本。
下一步
立项通过后，最关键假设通常落在用户问题上：这个问题是否真实存在？用户是否真的像我们以为的那样受阻？
下一讲《用户研究与需求验证》就从这里接下去，用访谈、行为数据与现场观察来检验这条假设。