产品经理的本质——从需求执行到价值负责

一、开场：一个常见的教学困境

先问大家一个问题。

你的产品上线了一个新功能——运动后的"恢复建议"。用户完成一次跑步训练后，手表会生成一个恢复时间建议，告诉用户"建议休息 48 小时"。

你作为这个功能的产品经理，你觉得你做完了什么？

大多数 2-3 年经验的产品经理会这样回答："我完成了需求调研，输出了 PRD，跟研发排了期，测试验证了逻辑，功能上线了。"

这是一个标准的、工厂流水线式的答案。但这个回答里，没有一个字提到用户是否因为这个功能变得更好。

上线两周后，数据出来了：恢复建议的点击率不到 3%，用户留存没有变化，差评区多了十几条"这个恢复时间根本不准确"的反馈。

运营问你：是不是该优化 UI 让点击率更高？ 研发问你：是不是算法模型需要调参数？ 你老板问你：这个功能到底是不是用户想要的？

这就是一个标准的"需求执行者困境"：事情做了，但价值没出来。谁的问题？

---

二、核心概念：产品经理的两种截然不同的工作方式

2.1 需求执行者 vs 价值负责人

我用一个简单的对比来说明。

本质上，"需求执行者"是在一个别人定义好的框里填内容；"价值负责人"是自己画框，并确保这个框装的是对用户和业务都有意义的东西。

产品能力是训练一个人判断信息、抓住要点、整合有限的资源，把自己的价值打包成一个产品向世界交付，并且获得回报。 注意这个表述——不是"把需求转化为功能"，而是"把自己的价值打包成产品"。

你是把自己的判断力、洞察力、对用户的理解，打包成一个产品。如果你只是把别人的需求翻译成文档，你的价值在哪里？

2.2 什么是一个"好产品"的三个标尺

判断你在做"需求"还是在做"产品"，有一个非常实用的检验框架——俞军提出的好产品三要素：

一个好产品要有三个属性：对用户有效用，对企业有收益，可持续。

我们来拆解一下。

第一，对用户有效用。 用户用了你这个功能，他得到了什么？不是"他点击了按钮"，而是"他的某个问题被解决了，某个需求被满足了"。恢复建议这个功能，用户真正得到的是一个"让我更科学训练、减少受伤风险"的确定性。如果他觉得数据不准、不信任，说明效用没建立。

第二，对企业有收益。 这个功能帮公司实现了什么？可能是活跃度提升、付费转化、品牌信任度增加。恢复建议如果没人用，对企业就没有收益——甚至带来了负面收益（差评、用户流失）。

第三，可持续。 不是做一锤子买卖。这个功能能不能持续运作、持续产生价值？用户会不会持续使用？成本能不能覆盖？有没有技术债？

用这三个标尺去衡量你手头的任何一个需求，你的判断会完全不同。

---

三、经典方法论拆解：用户价值公式

3.1 俞军的用户价值公式

俞军是百度前产品副总裁，也是中国产品经理圈公认的理论奠基人之一。他提出了一个极其简洁但深刻的公式：

用户价值 = 新体验 - 旧体验 - 替换成本

这看起来就是一个简单的减法公式。但它揭示了一个残酷的事实：用户不会因为你做了新功能就用，除非你的新功能带来的体验提升，超过了用户切换到你的成本。

我们来展开说。

新体验：你的产品/功能给用户带来的新感受。比如恢复建议可以告诉用户"你的身体状态正在恢复，下次高强度训练建议在 48 小时后"。 旧体验：用户在没有你这个功能之前，是怎么解决这个问题的。比如用户可能之前是靠"体感"——跑完觉得累就多休息，不累就继续跑。这个方法虽然不精确，但免费且简单。 替换成本：用户切换到你这里需要付出的代价——学习成本（要理解什么是 HRV、什么是恢复建议）、信任成本（你的算法准吗？）、行为改变成本（以前凭感觉，现在要看数据）。

所以，如果你的恢复建议功能只做到了"展示 HRV 数据"，那它的新体验是「一堆看不懂的数字」。而旧体验是「凭感觉休息，简单直接」。用户价值 = 看不懂的数字 - 凭感觉 - 学习信任成本 = 负数。

用户不傻。当用户价值为负时，他们不会用。

3.2 从这个公式推导出的产品行动

这个公式告诉我们三件事：

1. 要么把新体验做到极致。 不只是"展示数据"，而是"把专业数据翻译成用户能理解的一句话和一个行动指令"。比如："你的 HRV 比基线低 15%，建议今晚正常休息，明天可以进行低强度有氧恢复跑。"

2. 要么大幅降低替换成本。 让用户不用学就能用。比如首次佩戴时做个简单的引导问答，把恢复建议"翻译"成用户能理解的"红黄绿灯"。

3. 要么发现旧体验本身就极差的市场。 比如，对于马拉松备赛用户来说，他们之前靠教练给训练计划，但私教贵、难约，旧体验本身就不好。这时你的新体验哪怕只做到"比较靠谱的 AI 建议"，替换成本也值得。

---

四、业务深度案例：心率不准——一个"简单"问题的背后

现在我们来做一个完整的案例推演。这是智能穿戴业务中几乎每个 PM 都会遇到的一个经典问题：用户反馈"心率不准"。

4.1 需求执行者是怎么做的

需求执行者接到这个反馈后的典型路径：

1. 把"心率不准"记录为一条用户反馈。

2. 去跟算法团队确认："咱们的心率算法准确率是多少？"

3. 算法团队回复："实验室条件下准确率 95%，市场上主流水平。"

4. 需求执行者得出结论：算法没问题，可能是用户佩戴姿势不对。于是写了个弹窗引导 "请正确佩戴手表"。

5. 功能上线。用户继续反馈"不准"。

这个过程中，需求执行者做了"正确"的事情：确认问题、找到原因、给出解决方案、推动上线。但问题解决了吗？没有。为什么呢？

因为他没有去问一个更本质的问题：用户说"不准"的时候，他到底在说什么？

4.2 价值负责人是怎么做的

价值负责人会先做一件事：重新定义问题。

"心率不准"这四个字，可能对应完全不同的几种情况：

• 场景 A：用户在安静状态下，手表显示 75，他用手测是 72。偏差 3bpm，但对用户来说"不准"。 这说明用户的预期是医疗级精度。这不是算法问题，是预期管理问题。

• 场景 B：用户在高强度间歇跑时，手表显示 165，但他感觉"喘不过气来，应该有 180"。这个场景下，光电心率在剧烈运动时确实有延迟和误差。 这是技术限制问题。

• 场景 C：用户的跑步记录里，心率曲线有一段突然从 150 掉到 90 又弹回 150。这是典型的"心率锁定"（手表没戴紧，光学信号丢失）。 这是佩戴或算法抗干扰问题。

• 场景 D：用户把心率数据和朋友的佳明手表对比，发现不一样。这不是谁不准的问题，是两个品牌算法不同、测量位置不同。 这是用户认知问题。

同一个反馈"心率不准"，对应四个完全不同的根因，需要四种完全不同的解决方案。

价值负责人的做法：

1. 先定性分类：拉取后台数据 + 客服记录 + 用户访谈，把这四种场景的比例搞清楚。

2. 然后分别方案：

   • 场景 A：产品侧加一个"心率测量说明"引导页，说明运动手表心率与医疗设备的区别。

   • 场景 B：在运动模式中标注"高强度运动时心率数据仅供参考"，同时在算法侧投入优化。

   • 场景 C：运动开始前加"佩戴检测"——检测到信号不稳定时提醒用户重新佩戴。

   • 场景 D：做竞品数据对比文档，在帮助中心和社区里做用户教育。

3. 最后排优先级：根据各场景的影响面（多少用户遇到）、技术可行性、开发成本，排出先后顺序。

4.3 这个案例教给我们的

同样的用户反馈，需求执行者做的是"把反馈流转下去"；价值负责人做的是**"重新拆解问题，找到真正的病灶，对症下药"**。

前者花了一周上线了一个弹窗，问题没解决。 后者花了三周做了一整套方案，真正降低了"心率不准"的差评率。

这就是"从需求执行到价值负责"的第一次跨越：从被动接收反馈，到主动定义问题。

---

五、反例：我们是如何把"精准睡眠"做砸的

下面这个案例综合了多个睡眠监测产品的常见教训。某个智能穿戴品牌在 2021 年推出了"精准睡眠监测"功能，主打卖点是"能监测深睡、浅睡、REM 各个阶段，准确率与 PSG（多导睡眠监测仪）相当"。

5.1 问题出在哪

这个功能上线后，数据是这样的：

• 新用户首次查看睡眠报告的比例：68%（还不错）

• 一周后仍持续查看的用户：22%

• 一个月后持续查看的用户：不到 5%

• 差评集中点："说我睡眠质量差，但我感觉睡得挺好的啊""我睡了 8 小时你给个 75 分，焦虑了"

这又是一个"功能做了，但价值没建立"的典型。

5.2 复盘分析

用我们今天学的框架来分析：

用户价值公式检验：

• 新体验：一份看起来很专业的睡眠报告，有各个阶段的时长和评分。

• 旧体验：用户原来怎么评价睡眠质量的？"昨晚睡得还行""没睡好"——简单、主观、不精确，但够用了。

• 替换成本：看了报告后，发现自己睡眠分数低，反而焦虑了。这是负替换成本——用户不仅没什么收益，还增加了焦虑。

好产品三要素检验：

• 对用户有效用？没有——报告没有给用户明确的行动建议。"你深睡只有 1.5 小时"然后呢？用户接下来该做什么？

• 对企业有收益？低——没人看，没有留存，没有商业化可能。反而产生了负面口碑。

• 可持续？不可持续——用户看一两次就放弃了。

5.3 如果重新做，会怎么做

如果当时用"价值负责人"的思维来做这个功能，可能会是另一个方向：

1. 先问"用户在睡眠这件事上真正想要什么"——用户不是想要一张报告，用户想要的是"白天精力更好"。睡眠监测只是手段，不是目的。用户真正雇佣这个功能完成的任务是："我想知道我该几点睡、怎么睡，才能让我明天精力充沛。"

2. 功能的终局不是报告，而是行动建议——"你的 REM 睡眠偏短，这可能跟最近压力大有关系。建议睡前 1 小时避免高强度运动，试试 10 分钟呼吸练习。"

3. 给用户一个"可操作的闭环"——看报告→得到建议→执行→下次报告验证改善。这才是真正的用户价值。

---

六、实操工具：价值判断六问

当你在工作中接到任何一个需求，在开始写文档、排期之前，先问自己这六个问题。我称之为 "价值判断六问"。

使用这个方法很简单：接到任何一个需求，把它写下来，然后一行一行回答这六个问题。如果前三问你答不出来，说明你还没理解这个需求。如果第四问你答的是"切换成本很高"，那你要么加大方案力度，要么放弃。如果第五问你答不上来——那你上线后怎么证明自己做了对的事情？

这个模板你可以保存下来，作为你日常工作的"检查清单"。每次开需求评审会之前，先拿它自检一遍。你会发现，很多需求在第六问就被否决了——因为连 MVP 版本都讲不清楚有什么价值。

---

七、本讲重点总结

我们来回顾这一讲的核心内容。

最后，说一点个人观察。

做 2-3 年产品经理的时候，最容易陷入一个陷阱：觉得"完成了"就是"做好了"。 需求评审过了、排期定了、代码上线了——这些"完成"的成就感，恰恰是产品进阶路上最大的敌人。因为"完成"的标准在别人手里，"做好"的标准才在你自己手里。

下一讲，我们会深入讨论产品判断——当用户价值、企业收益和可持续性发生冲突时，你该怎么做决定？这个能力，是把普通产品经理和优秀产品经理区分开的关键。

八、课后思考

1. 价值公式自检：想一想你正在做的一个功能，如果用俞军的用户价值公式去算，新体验、旧体验、替换成本分别是什么？用户价值是正还是负？试着把这个计算讲给一位同事听，看看他的直觉判断和你是否一致。

2. 问题拆解：回忆最近一个月你们团队收到的一个高频用户反馈（比如"GPS 轨迹不准""续航太短"等），试着拆解一下，它可能对应几种完全不同的根因？不用写报告，能在脑子里分出三四类就很好了。

3. 自我复盘：回忆一下过去三个月的功能，有没有哪个"做完了但没做好"的？用六问模板重新审视一下，看看当初可能漏掉了什么。