《当项目数量成为价值证明，产品经理会如何选择？》
读完《IT越忙，为什么越难证明价值？》，我首先想到的是乔布斯在1997年WWDC上的一段回答。
当时有人质疑苹果为什么放弃OpenDoc。乔布斯承认，OpenDoc可能具备一些其他技术没有的能力，也能做出很精彩的演示，但真正困难的问题是：它能否融入一个完整的产品愿景，并最终创造足够大的市场价值？
他由此提出，应该从客户能够获得什么价值、拥有什么体验出发，再倒推需要什么技术；而不是先做出一项很先进的技术，再思考可以把它卖给谁。
这让我想到：如果产研团队一年上线了很多项目，我们能否由此判断这一年创造了很多价值？
项目交付只能证明我们完成了很多工作，不能直接证明产生了同等数量的价值。我们真正需要追问的是：这些项目最终改变了什么？
当然，我并不认为现在做的项目完全没有价值。大部分业务需求背后都对应着某个真实问题，很少有需求是毫无价值的。但是，“问题真实”不等于“解决方案正确”，更不等于“它是当前最值得投入资源的项目”。
这里其实存在三个不同层次：
- 需求价值：它是否对应一个真实问题；
- 方案价值：当前方案能否有效解决这个问题；
- 投资价值：相较于其他机会，它是否值得现在投入资源。
产品决策真正困难的地方，从来不是判断一个需求有没有价值，而是在多个都有价值的需求中，判断哪个更值得做。
因此，产品失败不一定表现为“做了一个完全没用的东西”。更多时候可能是：我们投入了大量资源，解决了一个真实但不够重要的问题，同时错过了更值得解决的问题。
一、企业如何衡量价值，团队就会倾向于做什么项目
文章让我进一步意识到，价值衡量方式不仅决定一个项目结束后如何汇报，还会在项目开始之前影响团队的选择。
企业用什么方式衡量价值，团队就会自然倾向于做什么样的项目。
如果主要用项目是否准时交付来衡量产研价值，团队就会优先保证按时上线。在这种目标下，一些更深层的工作可能会被压缩，例如：这个项目本身是否正确、有没有更好的解决方案、是否应该先解决其他问题，以及是否为了内部效率牺牲了供应商体验。
类似的情况还有很多：
- 只看短期降本，团队就会倾向于做自动化和减人工项目；
- 只看使用率，就可能通过强制入口提高数字；
- 只看项目数量，就可能把完整问题拆成更多小项目；
- 只看单项目ROI，供应商数据底座、统一身份、消息中心和API能力等基础建设就很难立项；
- 只看内部效率，采购减少的工作可能只是被转移给了供应商。
这些指标本身并没有错。准时交付、降本、使用率、项目数量和ROI都有意义。真正的问题是：当任何一个局部指标成为唯一目标时，团队就会围绕指标优化，而不再围绕整体价值优化。
指标不是价值本身，只是对价值的有限代理。
例如，使用率原本是为了观察产品是否被用户接受，但当使用率变成最终目标时，我们可能通过强制使用制造出一个很高的数字。数字完成了，用户价值却不一定增加。
同样，如果我们只统计内部节省了多少人工，就可能忽略供应商因此增加了多少操作。采购少花了十分钟，供应商却多花了二十分钟，这不是整个协同体系效率的提升，而是成本在不同角色之间发生了转移。
因此，价值衡量体系并不只是一个“项目结束后的汇报工具”，它实际上还是一个产品投资决策系统。它决定什么问题更容易被看见、什么项目更容易获得资源，也决定什么价值会被长期忽略。
二、为什么更有价值的项目没有被发现？
如果我们相信一定存在更值得投入的项目，那么接下来就要问：为什么这些项目没有被发掘？为什么一些价值相对有限的需求没有被否决？
这是产品经理能力不足吗？我认为能力可能是其中一部分，但不是全部。
首先，业务提出的需求天然可见，而潜在的产品机会天然不可见。
业务需求通常非常具体：某个页面不好用、某个流程需要增加功能、某项人工操作需要自动化。收到需求后，产品经理可以立即进入设计和交付。
但更高价值的机会通常需要主动研究才能发现。例如，多个零散问题是否来自同一个底层原因？供应商真正影响响应意愿的因素是什么？有没有一项基础能力可以同时解决多个业务问题？哪些问题大家已经习以为常，所以反而没有人再主动提出？
承接需求可以马上产生看得见的进度，发现机会却需要调研、数据分析和一段暂时没有显性产出的思考时间。
其次，做项目与否决项目之间存在举证责任的不对称。
做一个业务提出的需求，只需要证明业务确实遇到了问题。但要否决这个需求，产品经理往往需要证明：
- 这个问题没有那么重要；
- 当前方案不正确；
- 还有更值得投入的方向；
- 不做不会带来严重后果；
- 自己提出的替代方案最终能够成功。
这实际上是在要求产品经理证明一个尚未发生的结果。
做一个低价值需求，责任通常由多个角色共同承担；但否决一个需求，责任却可能集中在提出反对意见的产品经理身上。
因此，承接需求是一种相对安全的选择，主动否决则是一种风险更高的选择。
最后，短期交付有即时反馈，长期价值却很难马上被看见。
一个功能上线了，业务可以立即看到；一个低价值项目被阻止了，却很难有人知道因此节省了多少资源。解决一次具体问题容易得到反馈，建设底层能力的收益却可能半年后才出现。快速接受需求容易提高短期合作满意度，持续追问价值则可能让业务感受到阻力。
所以，即使组织口头上鼓励价值思考，日常的反馈方式仍然可能不断强化功能交付。
三、为什么很多产品经理最终变成了功能型产品经理？
我的第一本产品经理入门书告诉我，产品经理有四项主要职能：
- 需求：判断到底要满足用户什么需求；
- 生产：完成文档、原型、逻辑设计和功能实现；
- 销售：思考如何让用户接受产品，并最终产生市场或业务结果；
- 协同：协调不同职能的人员和部门，共同获得结果。
但在实际工作中，大部分产品经理最容易被看见的是生产和协同：
- 做了多少项目；
- 输出了多少文档和原型；
- 需求有没有按时上线；
- 业务提出的问题有没有快速响应；
- 项目推进过程中有没有发生延期和冲突。
而需求和销售更难被看见：
- 有没有发现真正值得解决的问题；
- 有没有阻止一个不值得做的项目；
- 有没有选择更优的解决方案；
- 有没有建立长期可复用的产品能力；
- 产品是否真正被用户接受；
- 最终有没有产生业务结果。
如果企业用项目交付数量证明产研价值，产品经理自然会用功能数量证明自己的价值。当组织奖励的是“做了多少”，而不是“改变了什么”，功能型产品经理就不只是个人能力和性格的结果，也可能是组织机制长期塑造的结果。
我把功能型产品经理大致分为三类。
第一类是执行型功能产品经理。他们擅长生产和协同，业务提出需求后，能够快速转化成方案并推动上线，但很少继续追问为什么做、有没有更好的选择，以及上线后究竟产生了什么结果。
第二类是适应型功能产品经理。他们原本愿意思考价值，也会质疑需求。但在多次博弈后发现：提出不同意见的沟通成本很高，基础建设和长期价值很难被感知，阻止一个低价值项目没有明显功劳，多完成几个项目反而更容易获得认可。于是，他们并没有失去思考能力，只是逐渐减少了在组织中使用这种能力的意愿。
第三类是价值坚持型产品经理。他们会持续追问“为什么要做”“做了有什么用”，也愿意拒绝价值不足的需求。这类产品经理可能很优秀，但也容易被认为不好协作、过于较真，甚至成为团队中不受欢迎的人。如果坚持价值只能长期依赖个人性格和牺牲，最终结果往往是逐渐妥协，或者选择离开。
这就形成了一个很矛盾的现象：
产品经理越对最终价值负责，越可能在短期给业务带来阻力感；越快速接受需求，短期合作体验反而越好。
很多被动的功能型产品经理并不是不知道应该关注价值，而是在一次次真实反馈中，学会了什么行为成本最低、什么结果最容易获得认可。
当正确的产品行为需要长期依靠个人勇气维持，而顺从需求能够获得更稳定的正向反馈时，组织最终筛选出来的可能不是最善于判断价值的人，而是最善于完成交付的人。
四、产品经理也不能把责任全部归因于组织
不过，评价机制不能成为产品经理放弃价值思考的全部理由。
产品经理的四项职能中本来就包含“销售”。销售不只是把产品卖给用户，也包括把问题的严重性、方案的价值和长期建设的必要性，传递给业务及决策者。
产品经理不能只知道自己是对的，还要让其他人理解为什么这样做更有价值。
例如，我们不能只说“这是基础建设”，还要进一步说明：它能减少哪些重复建设，后续项目可以缩短多少交付周期，可以覆盖哪些业务场景，以及如果不建设，组织还会持续承担什么成本。
对于长期项目，也不能等半年后才证明价值，而应该把长期目标拆成阶段性结果：第一阶段验证数据是否完整，第二阶段验证一个核心业务场景，第三阶段验证能否规模化复用，最后再观察它是否真正产生经营结果。
同样，产品经理不能只对业务说“这个需求不应该做”，还需要提出更好的选择：
这个问题是否必须解决？当前方案是不是成本最低的方式？有没有一种方案能够覆盖更多场景？如果不做这个需求，我们建议把资源投入在哪里？为什么那个方向更值得？
组织需要给产品经理合理质疑的机制，产品经理也需要具备把专业判断转化为业务共识的能力。否则，一方觉得产品只会执行，另一方觉得业务听不进去，最后双方都会退回到沟通成本最低、但未必最有价值的合作方式。
五、价值判断不能只依靠“不妥协的人”
如果企业希望产品经理关注价值，就不能只期待出现几个特别坚持、特别敢于质疑的人。
因为依靠个人勇气的机制是不稳定的。真正成熟的产品体系，应该让产品经理不需要依靠个人牺牲，也能够合理地提出问题、验证价值和否决低价值需求。
例如，对于重要项目，可以在立项时建立一份简化的“价值假设”：
- 为谁解决什么问题？
- 当前的业务基线是什么？
- 希望改变哪个用户行为或业务结果？
- 为什么选择当前方案？
- 相比其他项目，为什么要现在做？
- 上线以后在什么时间验证？
同时，不能要求所有项目都使用同一种短期财务指标证明价值。不同项目可能创造不同类型的价值：
- 用户价值：改善体验、效率和使用意愿；
- 业务价值：增加收入、降低成本、提高转化；
- 能力价值：沉淀数据、平台和可复用的公共能力；
- 风险价值：降低合规、事故、供应中断等潜在损失。
项目上线后，状态也不应该简单地变成“已完成”。更准确的状态可能是：已上线、待验证；初步验证有效；价值未达预期；持续产生价值；价值衰减，需要调整或下线。
甚至，“决定不做”也应该成为一种可以被记录的产品成果。如果产品经理通过调研证明某个需求不值得投入，帮助团队避免了资源浪费，这同样是在创造价值。
否则，组织只记录“做成了什么”，却从不记录“避免做错什么”，产品经理自然只会不断增加项目。
结语
读完这篇文章，我最大的感受是：项目交付不等于产品价值，项目数量也不等于价值数量。
企业如何衡量价值，会影响团队选择什么项目；企业如何评价个人，会影响产品经理采用什么工作方式。长期来看，这不仅会塑造企业的产品形态，也会决定组织最终留下什么样的产品经理。
一个成熟的产品体系，不应该只提升团队“把事情做完”的能力，还应该提升团队“选择正确的事情去做”的能力。
前者决定交付效率，后者决定这些交付最终能否转化为企业价值。
而产品经理真正需要负责的，也不应该只是把需求变成功能，而是帮助团队在有限资源下持续回答三个问题：
我们为什么做？
它实际改变了什么？
还有没有更值得做的事情？