第 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步操作才能完成一次订货，每一步还都要填写多个字段。经销商的原话是：我用电话下单只要30秒，你让我用这个系统要5分钟。

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

案例：大厂经验失灵

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

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

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

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

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

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

2022年，我带领的产品团队在组织结构上做了较大调整，由一位半路出家的副总裁负责统筹。新官上任三把火，他在对业务和数据都还没有认知的情况下，就启动了几个战略产品项目。其中一个是对原内容板块做一次大升级，原因很简单：抖音电商发展太快，其他电商平台都感到了危机，于是大家都觉得，凡是做内容的板块都该升级成短视频Feed流。没有调研，没有论证，决策做得又急又草率。一边是运营团队大量引进视频生产的人才，一边是产品团队热火朝天地开始给内容板块“升级”。

历经近一个月高强度的赶工，这个战略项目上马了。接下来产品和数据团队开始按日常节奏观测数据、产出报告。我在数据报告里总结：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会替代大量执行动作，但不会替你承担判断的后果。