第 1 章 · 认知困局

政治任务型惯性：当“必须做”替代了“为什么做”#

所谓政治任务不一定是老板拍脑袋的决定，更多时候它是一种弥漫在组织空气中的共识：“大家都觉得应该做”、“行业里都在做”、“不做就落后了”。你有没有经历过这样的场景：业务沟通会上一个想法、功能被提出来，在场所有人都是认同的，不是因为大家都认真思考过，而是因为这个“听起来很对”，例如“做社区”、“做直播”、“做私域”、“做 AI”，每一个热词背后，都有无数产品团队正在开足马力做功能，但当你问“我们的用户真的需要这个吗？”，回答往往是“先做了再说”，你刚想把问题拉回原点，对方很可能会说：“得先上功能，这样才能谈未来。”

当一个团队习惯了用“做功能”来证明自己的价值，“不做”就成了一种不可接受的状态。你必须永远在规划、在设计、在迭代，你的周报上必须写满“本周完成 XX 功能设计”“推进 XX 需求上线”，如果你停下来思考，你的周报就会显得空，而空的周报，在大多数组织里，意味着你“没干活”。这种情况不止发生在小团队，行业里反复出现过类似现象：一个项目因为战略上“看起来必须做”，因为竞品也在做，因为某个热词正在风口上，于是资源、排期、组织注意力迅速聚拢，大家开始讨论系统架构、功能清单、上线节奏，却很少有人继续追问：“这个场景里，用户是不是真的需要它？”、“商家是不是真的愿意改变原来的工作方式？”、“它解决的是业务真实问题，还是只是在回应组织的焦虑？”。

这类项目的每个局部决策往往都能自洽：战略需要、资源到位、团队强大、方案完整，唯一缺失的环节是最初那些上述问题没有被认真回答，不是没人敢问，而是在“所有人都觉得必须做”的氛围里，这个问题根本不会被提上议程。这些案例的共同点是什么？**不是团队不努力，不是能力不够，而是太努力了、能力太强了，当一个组织把“做功能”等同于“创造价值”，它就会陷入一种自我强化的循环：“做更多功能→需要更多人来维护→需要更多功能来证明这些人有价值→需要更多人”。**直到有一天，产品变成了一个所有人都不知道怎么用但所有人都害怕删掉任何一个功能的庞然大物，很多团队负责的项目，正是在这个过程中慢慢变重的。

架构自嗨型惯性：当专业能力成为认知牢笼#

如果说政治任务型惯性的驱动力来自外部：组织的期待、行业的共识、KPI 的压力，那么还有一种更隐蔽的惯性，它的驱动力来自内部，我把它叫作“架构自嗨型惯性”，这是产品经理最容易踩的坑，越资深越容易踩到，而且你踩进去的时候完全意识不到，因为它披着“专业”的外衣，这里有发生在我身边的两个案例：

案例：那个我差点就想多的门店工具

2017年我差点也掉进“架构自嗨型惯性”这个坑里，当时我们这个新零售平台的平台端基本已见雏形，公司计划针对线下 300多家实体店打造门店端，这个时候我的“架构脑”开始活跃：“是不是应该做一个完整的门店管理系统？把订单、库存、会员、营销、对账全部纳入一个统一的架构体系？”，这个想法在技术层面极其优雅，一个入口，一套流程，把所有问题都收进来。

在启动前我逼自己去做了情境调研，我们不着急发调查问卷和数据分析，而是跑到门店站在店员旁边看他怎么工作。我看到的场景是这样的：一个店员早上九点到店，打开电脑登录企业网银、打开 POS 机、拿出自己的手机打开个人微信和支付宝，用户到店购买一台手机，可能用银行卡付一部分、花呗分期付一部分、微信付尾款，店员要分别在 POS 机、个人微信、企业网银和运营商系统里操作，一个流程下来，用户要等近 1 小时，同时下班之后，店员还要花 1～2 个小时对账，把各个渠道的收款和订单一一匹配。

这才是真实的问题：不是“架构不优雅”，不是“系统没打通”，而是店员每天在多个工具之间疲于奔命，用户因为等待时间太长而放弃购买。如果我当时去做一个宏大的系统，我可能会花半年时间做出一个“架构优美”的系统，但它解决不了店员今天晚上就要面对的对账问题。庆幸我做了情景调研，我把“做一个完整系统”的想法压缩成了一个具体的产品决策：先做聚合支付支持一码多扫、多码一扫，将款项直接汇入公司账户；同时解决订单对账问题，将款项与订单一一对应。最终对账从 1～2 小时变成不需要对账，用户等待时间从 1 小时降到 0.5 小时以内，并且也让我赢得了绝大部分线下门店店长/店员的高度认可和信任，为后续新零售平台的线上线下结合打下了夯实的信任基础。

这才是产品经理该做的事，不是做一个让自己满意的架构，而是解决一个让用户痛苦的问题。但是必须承认，架构自嗨的诱惑力是巨大的：它满足的不是用户的需求，而是产品经理自己的需求，对系统秩序与完整的成就感。越资深的产品经理，这种冲动越强，因为你看过足够多的系统，你脑子里有足够多的“最佳实践”，你天然地想把一切都纳入一个优雅的框架，但用户不在乎你的架构，用户只在乎自己的问题有没有被解决。

案例：那个被寄予厚望的中台项目

2024年我所在团队接收到来自于老板的课题“打造大平台”，这个想法来源于老板多年经营业务得到的下游反馈，在过往发展中存在过多条业务线，每次新增一条业务线时的做法都是将之前一个相对成熟业务线对应的全套系统进行代码复制进行修改调整兼容，所以老板总是能听到一些重复的反馈声音：“这个功能在这个系统要做一遍，在那个系统也要做一遍”、“这个功能不适配新的业务模式，需要修改”、“这个系统定制化比较严重，只能硬编码”……

恰在当时，公司开始引入一批有大型平台经验的技术、产品负责人，其中不乏对中台化有认知的伙伴。中台化的提出瞬间击中了老板多年的痛点，仿佛找到了多业务线统一管理和运作的终局解法，于是这个项目启动了。起初出发点是提炼出多个系统中最核心关键的板块进行中台化构建，例如商品中心、价格中心、订单中心，但作为一个全公司最顶层的超级大项目，各方领导虽然不直接下场，却开始提出各类诉求。产品/研发 Leader 们的关注点不再局限于部分核心板块的中台化构建，而是放大到对公司所有业务系统整合性的重构，开始陷入架构自嗨阶段，想要在这套最新的大平台上呈现最佳实践。

这个项目断断续续进行资源投入，历时 1 年完整版本上线，开始进行了各条业务线的切换，但这个切换过程阻碍重重，一线业务同学不想、不敢切换，生怕影响业绩；已经切过去的业务线，虽然系统好用不少，兼容能力增强不少，数据也更清晰，但实际业绩并没有明显提升，用户使用感受也没有明显提升，内部对于这个项目褒贬不一。

一个架构可以更先进，一个后台可以更统一，一个平台可以更“像未来”，但如果它没有改变一线业务的关键成本，没有改善用户的核心体验，没有让组织在更少代价下做出更好的决策，那么它最多只能证明我们做了一个更大的系统，不能证明我们做了一个更有价值的产品。当你把“做功能”当成证明自己专业能力的方式，你就已经开始偏离产品经理真正该回答的问题，真正专业的能力，不是“能把功能做得多好”，而是“能判断什么功能不该做”。

组织惯性：当“做功能”成为唯一的价值证明#

“政治任务型”和“架构自嗨型”这两种惯性其实都可以在某种程度上归结于产品经理个人的认知局限，但还有一种惯性，不属于个人，而是烙印在整个组织的运作方式里，我把它叫做组织惯性。在一个习惯了用功能产出衡量价值的体系里，“不做”是很难被看见的工作。工程师的产出可量化，设计师的产出可量化，产品经理却很难用量化方式来展示“我思考了三周，最终决定不做任何功能”。于是“做了多少功能”成了最方便、最直观的度量方式，但它本身就在鼓励一种错误的决策，即做得越多=价值越大。产品经理的价值恰恰常常在于“不做”：砍掉一个有害的功能，叫停一个没有真实需求的项目，拒绝一个看似紧急实则不重要的需求。一个产品经理越忠于“为用户创造价值”这个核心职责，在组织的常规评价体系里反而越容易被低估。

论坛案例就是如此，团队里所有人都投了赞成票，不是因为他们没有判断力，而是因为在那个场景里，“做社区”是一个安全的决策，它符合行业趋势，能填满下个季度的迭代计划。“不做社区”则是一个“危险”的决策，你拿什么填下个季度？“不做”的风险是个人承担的，“做”的风险是团队和系统分摊的。我自己花了好几年才学会在组织里“体面地不做”：在评审会上不说“这个需求我们排一下”，而是说“这个需求对应的用户问题是什么，有没有更轻的方式去验证”；在周报里没有“功能产出”时，写下“本周做了 5 个用户访谈，发现了一个被忽视的场景”。每一次这样的小追问，都是在瓦解组织惯性的一块砖。但如果组织惯性之上还有组织氛围在左右这件事，而环境始终无法改变，那最差的选择也不过是离开，在此之前，至少你已经改变了自己对“不做”的理解。

为什么越资深越危险#

写到这里，你可能会有一个疑问：按这个逻辑，资深产品经理岂不是比新人更容易犯错？答案是：是的，而且犯的错更贵，一个初级产品经理犯的错，通常是“这个按钮放左边还是右边”、“这个流程能不能少一步”，这些问题影响范围小，改起来也快；但一个资深产品经理犯的错，往往是“我们要不要做一个新业务”、“这个方向值不值得投入”，这个量级的决策一旦出错，是几十人甚至上百人几个月的时间，是几百万甚至上千万的预算，是市场窗口期的错失。更可怕的是，资深产品经理的犯错概率并不比新人低，新人容易犯“无知之错”：因为不知道而做错，这种错误会随着经验持续的积累自然减少；资深产品经理容易犯的是“认知之错”：因为太知道而做错，你的知识结构、方法论框架、成功经验，共同构成了一个强大的认知滤镜，你看到的所有问题，都会自动被映射到你擅长的解决方案上。你擅长增长，看到的所有问题都是“流量不够”；你擅长架构，看到的所有问题都是“系统没打通”；你擅长用户体验，看到的所有问题都是“交互不流畅”。锤子眼里全是钉子，而你手里的锤子越重，你砸下去的时候越自信。

我在做论坛的时候就是如此，当时的我擅长做产品规划、功能设计，所以当“做社区”这个方向被提出来的时候，我的第一反应是“怎么把这个社区做得更好”，而不是“这个社区本身有没有价值”。我的专业能力给了我一种虚假的控制感：只要我设计得足够好，这个功能就一定能成功。但现实是一个从根上就不该做的功能，设计得越好，死得越彻底，这不是能力问题，是习惯问题，当你太久没有下到一线，你就会失去对真实场景的敏感，当你的日常工作变成评审、汇报、规划，你就很容易用概念替代观察，用判断替代证据，用“我见过”替代“我看见”。

打破执行惯性的第一刀，不是砍向某一个具体的功能，而是砍向你自己，砍掉那种“我必须做点什么来证明我有价值”的焦虑。作为产品经理，你的价值从来不在于你做了多少功能，而在于你帮用户解决了多少真问题，而要想找到真问题，你必须先停下来，把手从键盘上拿开，走到用户身边，去看、去听、去问。不是带着“我要做什么功能”的前提去调研，而是带着“我不知道答案”的空杯心态去寻找。这不是一个技术问题，这是一个认知问题，而认知问题的解决，往往比技术问题难得多，因为它要求你主动放弃你最引以为傲的东西：你的专业直觉，你的成功经验，你的“我一看就知道该怎么做”的自信。下一节我们要讨论的，正是这个问题：为什么你最擅长的东西，恰恰是你最需要警惕的。

当拿手的方法论突然失效#

“经验负债”这个概念听起来有点反常识，我们不是一直说“经验是宝贵的财富”，怎么突然就变成负债了？关键区别在于：经验帮你解决的是“同类问题”，而负债产生的条件是“问题变了，你没意识到”。

在移动互联网红利期，增长是一个相对确定的游戏：流量便宜，用户对新 App 的接受度高，社交传播的边际成本也低。在这个阶段，增长黑客方法论确实好用：A/B 测试快速验证、裂变机制低成本拉新、漏斗分析定位转化瓶颈，这些方法帮助无数产品完成了从 0 到 1 的用户积累。但后来游戏规则逐渐发生改变，流量红利消退，获客成本上升，用户对营销套路产生了抗体，一个裂变活动在早几年可能带来可观新增，到了今天可能连成本都收不回来。这不是方法论本身的问题，而是场景变了。如果还在用过去的手段解决今天的增长问题，你就不是在“运用经验”，你是在“背负负债”。很多增长团队都在这个问题上吃过亏：照搬一套曾经有效的裂变机制，前期数据看起来不错，新增用户上来了，活动页热闹了，报表也好看了；但等到进一步看留存、复购、投诉和补贴成本，才发现来的不是目标用户，而是一群只对奖励敏感的人。这个问题的悲剧之处在于：如果放在更早的流量环境里，同样的策略可能是有效的，但团队没有意识到，用户变了，市场变了，薅补贴的产业链也变了，他们把“过去有效的经验”当成了“永远有效的真理”，结果经验变成了陷阱。我自己在 2019 年的经历也是如此，我不是没有方法，而是方法太多了，多到我忘了第一步应该是“清空自己，重新理解这个业务”，而不是“翻开我的方法论工具箱，看哪个工具能用”。

案例：显得多余的八年产品经验

我的一个老同事，他做了 8 年电商产品，从商品到订单再到营销，每一个模块他都做过，行业内叫得出名字的电商平台，他至少深度研究过其中一半。他有一个习惯，接到任何需求都能在短时间内给你画出一个“标准做法”：“这个你看某平台是这么做的，我们照着来就行”。这个习惯帮他高效交付了无数需求，但也正是这个习惯，让他在一次关键的产品决策上翻了大车：当时公司要做一套面向经销商的订货系统，他用了三天时间，拿出了一套对标主流电商后台的完整方案，功能齐全、流程规范、架构合理。评审的时候，所有人都觉得没问题，但上线之后，经销商几乎没人用，为什么？因为经销商不是运营人员，他们不关心“功能全不全”，他们只关心“能不能 5 分钟内下完 1 单”。他设计的系统需要 7 步操作才能完成 1 次订货，而且每一步都要求填写多个字段，经销商说：“我用电话下单只需 30 秒，你让我用这个系统要 5 分钟！”。

这位老同事的问题在于，他用“电商后台的标准做法”替代了“经销商到底需要什么”的思考，他的 8 年经验帮他快速产出了一个“看起来专业”的方案，但也阻断了他在做方案之前先去了解用户真实场景的动机。

案例：大厂经验失灵

另一个老同事做 C 端用户增长的，在一家大型互联网公司工作过 4 年，经手的活动累计带来过千万级 GMV 的新增。加入公司项目后，他做的第一个增长方案是一套完整的“签到+任务+积分+兑换”体系，逻辑严密，设计精美，但上线之后效果平平，问题出在哪？他的增长经验全部建立在“平台有海量流量可以分配”的前提之上，在大厂的时候，任何一个活动入口都能带来百万级的曝光，转化率哪怕只有千分之几，绝对值也很可观。但当时面对的仅是一家中型企业中的创新项目，DAU 只有 10 万出头，在这样的量级下，他设计的“签到+任务+积分”体系需要用户连续七天打卡才能兑换一个奖品，以我们的用户规模，最终只有几百人能走完这个流程，几百人的行为数据，在任何漏斗分析里都形同噪声。

不是能力不行，而他是带着大厂的“经验滤镜”在看一个完全不同的战场，他的成功经验告诉他“积分体系有效”，但这个经验没有告诉他“积分体系有效的前提是你有足够多的用户来摊薄固定成本”。

借用这两个老同事的故事，想要跟大家说明一个道理：经验的真正价值，不是让你下次照搬，而是让你下次更快地识别“这次不一样”。如果你不能识别“不一样”，你的经验就是一剂麻醉药，它让你感觉自己很专业，同时让你失去对新问题的敏感。

数据不会说谎，但人会骗自己#

经验负债还有另一种更隐蔽的形态，它藏在数据里。产品经理大概是整个互联网行业里最“迷信”数据的一群人，我们相信数据不会说谎，相信 A/B 测试能告诉我们真相，相信指标能度量一切，但做了 10 多年产品之后，我越来越觉得：数据从来不说谎，但人会选择性地让数据说他想听的话。

案例：你这个数据说法我不喜欢

2022 年我带领的产品团队在组织结构上发生了较大调整，由一位“半路出家”的副总裁负责统筹，新官上任三把火，在对业务和数据没有认知的情况下开展了几个战略产品项目，其中有一个项目是对原内容板块进行大升级，原因比较简单：抖音电商的快速发展让其他电商平台感觉到危机感十足，电商模块只要是做内容的板块就应该升级为短视频 Feed 流模式。于是在没有调研论证的背景下匆匆忙忙且草率的决策后，一边是运营团队引进了大量视频生产的人才，一边是让产品团队如火如荼的进行内容板块“升级”。

历经近 1 个月高强度的赶工，该战略项目上马了，接下来产品与数据团队开始了常态的数据观测及报告产出，我在数据报告中总结：“PV 从曝光至下单转化率均值为 0.42%，相对于原模式转化率 7.2%有较大差距”、“用户人均停留时长 13s，环比上周提升 2.5s，相对于原模式 21s 存在较大差距”……于是在该项目周期性汇报会上，我们如实反馈，副总裁眉头紧锁，指责在场所有产品、数据同学：“这不是我要的数据，这个项目是非常重要的，把数据结论调整为它应该有的样子！”。

迫于压力，产品和数据同学不得不调整数据报告，于是最后在公司战略复盘会议上，上述数据被表述为“PV 从曝光至下单转化实现了质的飞跃，实现了 0 的突破，模式得到用户认可”、“用户人均停留时长环比上周提升 23.81%，内容质量大幅提升”……一样的原始数据，却出现了截然不同的结论，最后这个项目经过若干个月的运作后，还是被叫停了，但中间消耗的人力、财力成本已经无法追回。

除了上述我自己的亲身经历，行业中每天都可能在上演类似的事情：一个功能让某个指标变好，团队就在复盘里证明它成功了，但如果把投诉、复购、长期留存、用户疲惫感一起放进来，结论可能完全不同。数据没有说谎，问题在于人选择了哪些数据，又故意忽略了哪些数据，这就是数据驱动最大的陷阱：为了优化指标而优化指标，而不是为了用户价值，很多时候数据好看了，用户反而走了。为什么资深、善用数据的产品经理反而更容易掉进这个陷阱？因为越资深的人越懂得如何“用数据讲故事”，你知道什么样的指标组合能支撑你的论点，你知道怎么切分人群能让某个数字好看，你知道什么样的 A/B 测试能产出你想要的结论，数据在你手里不再是一个客观的检测工具，而变成了你论证自己“做对了”的武器。这就是经验负债在数据层面的表现：你太擅长用数据了，擅长到你可以用数据骗过自己。

“专家”是最危险的一个词#

在我写这一节的时候，我问了自己一个问题：有没有一个词，能精准地概括经验负债的最高级形态？我想到了一个词：专家。不是这个头衔本身有问题（毕竟我从 2021 年开始就是产品专家岗，总体还是觉得这个词是褒义的），而是近些年我屡屡看到一些人一旦被冠以“专家”之名，就会下意识地认为自己“已经懂了”，而“已经懂了”是产品经理这个职业最危险的认知状态。

很多资深产品经理聊起方法论头头是道：第一性原理、用户心智、价值主张、北极星指标，哪一个都能讲，但让他真的去跟10个用户聊半小时，他未必知道该问什么，他习惯了在会议室里用白板推演用户需求，而不是走到一线去看用户真正在干什么。这不是某个人的问题，而是一个很容易被职级、分工和日程共同放大的职业病：职位越高，离用户越远；会议越多，离现场越远；越擅长抽象，越容易把抽象当作事实。

问题不止出现在大厂，创业公司的“专家病”同样致命，只是表现形式不同。创业公司的产品负责人往往是公司里最懂产品的人，因为其他人更不懂，这种“相对专家”的地位会带来一种危险的自信：你是团队里唯一能“看到全貌”的人，你的判断就是最终判断。我自己在上述那个论坛案例中就犯过这种病，当有人提出“做社区”的时候，我作为团队里核心的产品负责人，有义务去追问“为什么”，但我没有，因为我的“专家直觉”告诉我这个方向是对的：内容+社交=留存，这套公式在行业内被验证过无数次，我被自己的“专家判断”说服了，跳过了验证环节，直接进入了执行阶段。我总结了一条作为产品经理应该牢牢记住的原则：当“我觉得”三个字出现在你脑子里的那一刻，先把它当成危险信号而不是决策依据。

定期“卸载”成功经验#

“卸载经验”不意味着抛弃经验，把过去积累的一切全部扔掉，那不叫成长，那叫失忆，我指的其实是“不让经验成为你接触新问题时的第一反应”，具体来说，可以有几种方式：

• 每进入一个新领域，先做三天“新手”：不画架构图，不写方案，不引用过去的案例，就是去看、去听、去问、去用户工作的地方站一天，去翻投诉记录里被忽略的细节，去和一线客服吃顿饭。很多真正有价值的洞察，藏在这些看似琐碎的问题里。
• 给每个成功经验标上“有效期”和“适用条件”：在你的知识库里，每一条“有效的方法”下面都加一行：“这个方法有效的前提是……”。当你把这些前提条件写清楚，下次遇到新场景时，你的第一反应就不再是“这个方法能用”，而是“这些前提条件还成立吗”。
• 定期找一个你完全不懂的领域去“受挫”：做了多年电商的人去理解社交产品的逻辑，做 C 端的人去做 B 端工具——那些让你感到“不对劲”的地方，正是你的经验盲区。在你熟悉的领域里，这些盲区被经验自动填充了，你根本意识不到它们存在。

经验不是负债本身，拒绝更新经验才是。当你的经验从“帮你理解世界”变成了“替代你理解世界的”，这时候经验就变成了负债，而区分这两者的手段就是下次做事之前，你问问你自己还愿不愿意承认“这次我不懂”。

砍功能比加功能更难#

如果你觉得“发现问题”已经很难了，那我要告诉你一件更难的事：砍功能。2019 年如上述我接手一个社交电商平台 C 端产品工作，这个平台一开始的定位是拼团模式：用户发起拼团、邀请好友参团、成团后享受低价，逻辑很清楚，市场上也有成功先例，但上线之后效果不好。核心问题在于拉新困难，因为没有用户基础，拼团需要社交传播，而种子用户本身没有传播能力，来的用户大多是薅羊毛的，低价吸引来的用户只买拼团商品，客单价极低也不复购。最致命的是，我们期望的“C 端用户转 B 端经销商”这条路径完全跑不通，用户注册之后，转化门槛太高，信任度不够，而且就算转化了也无法承载后续的投入。当时团队面临一个艰难的选择：继续优化拼团？还是砍掉拼团？

• 优化拼团理由：过去已经投入了近半年的开发、功能框架搭好了、供应链也接入了。如果放弃就等于承认之前的投入全部白费，而且拼团模式在行业里有现成的成功案例，只要我们把体验做好、把商品选好、把传播机制调好，说不定能翻盘。
• 砍掉拼团理由：目标用户根本就不对，拼团模式的核心用户是 C 端消费者，他们对价格敏感，追求性价比，社交传播是自然行为，但我们实际触达的用户是谁？是一群微商和淘客，他们不是来买东西的，他们是来卖东西的，他们需要的是一个能帮他们经营生意的平台，需要的可能是会员体系、佣金结算、供应链支持，而不是一个拼团工具。

这是一个“定义问题”层面的错误，不是拼团功能设计得不好，而是“做拼团”这个决策本身就是错的：因为你定义错了用户，定义错了需求，定义错了产品应该创造的价值。最终我们选择砍掉了拼团，把产品重新定位为会员制社交电商模式，核心功能变成了会员体系和佣金结算，核心服务变成了健康品类和供应链支持。第一季度就取得了不错的数据表现：GMV 突破两亿、注册用户超过五十万、自营订单量突破三十万笔……

这个过程教会我最重要的一件事：砍功能最难的从来不是技术上的，而是心理上的。砍一个已经在线上跑着的功能，意味着你承认自己之前判断错了，对于资深产品经理来说，这比承认自己不会做某个新技术要难得多，因为新技术是“我还没学”，而砍功能是“我学到的那些东西，在这个决策上没用”。但这种“承认错误”的能力，恰恰是从“做产品”跃迁到“定义产品”的必经之路，因为你不可能每次都定义对，定义产品的本质就是做判断，而判断一定有对有错。区别在于：做产品的人错了可以改一个按钮、调一个流程，成本很低；定义产品的人错了要改方向、砍业务线，成本很高，所以定义产品的人需要的不是“每次都判断对”的超能力，而是“错了能快速承认并修正”的心理素质。

定义问题比解决问题重要#

我想讲一个行业内公认的经典案例，不是因为它成功，而是因为它精准地展示了“定义问题”和“解决问题”的区别。早期短视频产品的迭代里，有一个常被行业拿来讨论的例子：团队一开始看到的现象，是用户看完一条视频后，还要回到列表或重新选择下一条内容，操作路径长，停留时长不够理想。按照最直接的理解，问题似乎是“返回和切换不够顺”，解决方案自然会导向按钮位置、交互动效和页面跳转效率的优化。但后来真正改变产品体验的，并不是把某个按钮打磨得更好，而是重新定义了用户在刷短视频时的核心状态：很多用户并不想主动选择下一条内容，他们更希望在一个低决策成本的状态里连续消费。

这才是真正的“问题定义”：不是“操作路径太长”，而是“用户不想主动做选择，需要降低决策成本”。这两个定义引导出的解决方案完全不同，前者导向“优化返回按钮”，后者导向沉浸式 Feed 流：用户不需要反复做选择，手指上滑就自动进入下一条内容。这个变化后来成为短视频产品最典型的体验范式之一。这个案例之所以值得放在这里，不是因为它成功，而是因为它精准诠释了“能力嵌套”的含义：团队里有很多人能把“优化返回按钮”这件事做到极致，调整位置、增加动效、优化响应速度，这些都属于“做产品”的能力；但真正改变产品命运的是那个追问“用户在刷视频的时候到底在想什么”的人，这个人的能力，不是“把功能做得更好”，而是“定义什么才是真正需要被解决的问题”。这种能力的获得，不是通过做更多功能来训练的，它是通过“不做”来获得的，在接到需求的时候不急着画原型，在看到数据的时候不急着下结论，在所有人都说“优化一下”的时候停下来问一句：我们优化的真的是对的事情吗？

能力嵌套的三个层次#

行业内有一个被反复引用但很少有人认真展开的框架：阿里对 P7、P8、P9 产品经理的能力定义。我在自己的职业生涯中反复对照过这个框架，不纠结它是否指的是“晋升标准”，只将它作为能力跃迁的三套标准：

俞军在《产品方法论》里有一句话精准地概括了这三个层次：“产品经理的层级，本质是定义范围的层级，低阶定义怎么做，中阶定义做什么，高阶定义为什么做。”从 P7 到 P8，是“怎么做”被嵌套进“做什么”的判断里；从 P8 到 P9，是“做什么”被嵌套进“为什么做”的判断里。每一层嵌套都是一次自我否定——否定那个“把功能做到极致就有价值”的自己，才能变成“定义真正问题”的自己；否定那个“解决所有问题就有价值”的自己，才能变成“判断什么值得解决”的自己。

怎么知道“什么值得做”#

你可能会问一个很实际的问题：到底怎么判断“什么值得做”？有没有方法论？我的回答可能让你失望：没有一劳永逸的方法论，但有一些思维习惯，可以帮你越来越接近这个能力。但在讲这些思维习惯之前，首先需要明确“从做产品到定义产品”这个跃迁，在你的日常工作里到底意味着什么？它不是某一天你突然开悟了说“从今天起我不做功能了，我只做判断”，它是一个渐进的、需要刻意练习的过程，具体表现为三个思维转变：

• 从“怎么实现”到“该不该实现”：初级产品经理接到需求，第一反应是“怎么做”；资深产品经理的第一反应是“该不该做”。“怎么做”是舒适区，有经验、有方法论、有标准答案；“该不该”是不确定区，可能查不到数据，可能找不到参照，可能需要承认“我不知道”。
• 从“局部最优”到“全局最优”：执行型产品经理追求“我负责的模块做到最好”；定义型产品经理追求“在所有模块中，当前哪个最值得投入”。资源永远是有限的，优化 A 就可能牺牲 B，局部最优不等于整体最优。
• 从“答案思维”到“问题思维”：执行型产品经理拿到一个现象，直接找答案：“用户流失率高？答案是做召回机制。”定义型产品经理先判断：“是真的流失了，还是季节性波动？如果是真的流失，是竞品抢走了用户，还是产品解决的需求本身正在消失？”如果在错误的问题上工作，再好的答案也是徒劳。

这三个转变：从“怎么实现”到“该不该实现”，从“局部最优”到“全局最优”，从“答案思维”到“问题思维”，没有一个可以通过“做更多功能”来完成，它们只能在“做更少、但想更多”的节奏中逐步内化。这对习惯了快节奏交付的产品经理来说，是一个非常痛苦的过程，因为你必须忍受“输入减少”带来的焦虑，你不再像以前那样每天产出原型和文档，你的周报看起来比之前空，你可能自己都会怀疑自己是不是变懒了，但如果你能熬过这段焦虑期，你会发现一个不一样的东西：你不再需要用产出来证明自己的价值，因为你开始用判断来创造价值。

我的一句话定义#

以前我会将“产品经理就是发现问题，并提出解决方案，最终将解决方案产品化的人”作为产品经理的一句话定义，但是工作多年后，我发现这句话已经无法真正定义产品经理，尤其在面临越来越多的认知困局下。如果你现在一定要我用一句话来定义产品经理，我会这样说：产品经理是在有限的资源下，决定“什么问题值得解决”以及“用什么方式解决”的人。这句话里有三个关键词：

行业大佬们怎么说#

俞军的定义是：“产品经理是用产品解决用户问题、实现商业价值的人，核心能力是用户模型和交易模型”。这个定义的重心在“用户价值”和“商业价值”的平衡，你不是用户的代言人，你也不是公司的代言人，你是这两种价值之间的翻译者和平衡者。

梁宁的定义是：“产品经理是把用户需求翻译成产品功能，再把产品功能变成商业结果的人，核心能力是共情和框架能力”。这个定义的重心在“翻译”和“转化”，从需求到功能，从功能到商业。但这个“翻译”不是机械的传话，而是创造性的转化，你需要共情能力去理解用户，也需要框架能力去把理解变成可执行的方案。

王诗沐的定义是：“产品经理是产品的 CEO，需要对产品的全生命周期负责，本质是通过产品实现价值的人”。这个定义的重心在“全生命周期”，不是做完功能就交给别人，而是从洞察到定义到设计到上线到运营到商业化，全程参与，全程负责。

这三个定义放在一起，你会发现它们尝试用不同的语言描述同一件事：产品经理存在的理由，不是因为他会做什么，而是因为他能判断什么值得做，并且能把它做成。俞军强调“交易模型”，是在说你需要判断商业上值不值得；梁宁强调“共情能力”，是在说你需要判断用户是不是真的需要；王诗沐强调“全生命周期”，是在说你需要确保这个判断能从想法变成现实。三条线交汇的地方，就是产品经理的不可替代性，不是什么都会一点，而是能在一个复杂系统里做出正确的取舍。

“人人都是产品经理”的反思#

2010 年苏杰老师写的《人人都是产品经理》书籍，让产品经理这个岗位火遍了整个互联网行业，到后来我入行做产品经理的时候，这本书也成为入行必看的书籍之一。在听到关于“人人都是产品经理”这句话，我的第一反应是：对，产品思维确实不应该只局限于产品经理这个岗位，设计师应该有产品思维，工程师应该有产品思维，运营也应该有产品思维。每个人都在为用户创造价值，每个人都应该思考“我做的事情对用户来说意味着什么”，这是这句话的初衷，也是它有价值的那个层面，但十几年过去，这句话在行业里的实际影响，恐怕连作者本人也没有预料到。

它最大的副作用是让很多人误以为产品经理是一个“门槛很低”的岗位。“人人都是产品经理”那当然谁都可以是，不需要懂技术，不需要懂设计，不需要懂运营，只要有想法，就可以是产品经理。这种误读导致了两个严重后果，第一个是人才市场的泡沫，大量没有受过专业训练的人涌入这个岗位，拉低了整个行业的平均水平和薪资预期；第二个也是更严重的后果，它遮蔽了产品经理真正的专业壁垒在哪里。产品经理的专业壁垒不在“原型画得有多好”、“文档写得有多规范”、“评审讲得有多流畅”。这些技能，AI 现在已经能做得很好，未来会做得更好。产品经理真正的专业壁垒，在那些无法被标准化和流程化的判断里，哪些用户反馈是真的痛点，哪些只是抱怨？在多个可行的方案里，哪一个对当前的业务阶段最合适？当一个功能和核心体验冲突的时候，以谁为准？当数据告诉你 A、直觉告诉你 B 的时候，你信谁？

这些问题没有标准答案，没有人能给你一本操作手册。你能依赖的，只有你对用户的理解深度、你对业务的全链路认知、以及你从无数成功和失败的经验中沉淀下来的判断力。这就是为什么资深产品经理如此稀缺。不是因为他们会的工具多，而是因为他们在没有标准答案的场景里做出了更多正确的判断。苏杰老师在 2023 年的一次访谈里自己也说过一段反思：“我现在经常说不是人人都能做好产品经理。当年的口号是为了普及产品思维，现在行业成熟了，我们需要更理性地看待这个岗位的能力要求。”这句话我深以为然。产品思维确实人人可以有，每个人都应该思考自己做的事情为用户创造了什么价值，但产品经理这个岗位，“人人”做不了。

AI 时代，产品经理还重要吗#

讨论产品经理定义的时候，不可能回避 AI，AI 可以写需求文档了，可以画原型了，可以做竞品分析了，这些过去被视为产品经理基本功的东西，AI 正在快速覆盖。这引发了一个自然的恐慌：如果 AI 能做这些事情，产品经理还重要吗？我自己的思考是：正因为 AI 能做这些事情，产品经理也许才有真正的机会做产品经理该做的事。在 AI 出现之前，大部分产品经理的时间是被“执行”吃掉的：写文档、画原型、做汇报、跟进度。你明知道自己应该去用户那里待一个下午，但手上有几个需求文档明天要评审，你只能选择待在工位上写文档。AI 的出现，让很多执行动作可以被更快地完成，它能帮你写文档第一稿，搭竞品分析框架，整理会议纪要，甚至生成一个粗糙的原型。这并不意味着产品经理不重要，恰恰相反，它会把产品经理从一部分执行消耗里释放出来，逼你回到更难的事情上：去跟用户聊天，去门店站一个下午，去判断那个被搁置了三个月的问题：我们的产品到底为用户创造了什么价值？

所以 AI 不会淘汰产品经理，AI 淘汰的是“只有执行能力、没有判断能力”的产品经理。如果你过去的价值只在于原型画得快、文档写得清楚，那你确实应该焦虑；但如果你的价值在于“别人都觉得应该做这个功能，只有你说服大家先不要做”，那 AI 威胁不到你的核心位置。因为 AI 可以分析、归纳、总结，但它不能替你承担取舍之后的后果，AI 会替代大量执行动作，但不会替你承担判断后果。