饮水机出点子让它开发应用、开网店的人是谁？饮水机的老板？饮水机的产品经理？饮水机的 Python 程序员？给饮水机送水的小刘师傅？是不是谁提出上网的点子谁才是互联网产品经理？

前面说了，互联网产品经理就是持续优化产品定位和提高杠杆效率的人。优化产品定位的点子谁都可以出，提高杠杆效率的点子也是谁都可以出，但判断这些点子靠不靠谱，靠谱的点子怎么落地执行融入产品，需要一个专业岗位，这个岗位就是产品经理。

为什么老板要找人做产品经理？产品经理这个活儿老板自己干不行吗？

老板自己想的点子不一定靠谱，落地执行起来也不一定高效。如果他找到一个更专业的人，这个人用行业认知把不靠谱的点子加工成靠谱的点子，把资源严重浪费的执行变成低成本快速试错（在尝试中纠错，trial and error），对老板来说是不是更好的选择呢？

假设老板自己就是专业的产品经理，他花在这项工作上的时间可以用来和投资人聊融资，也可以出差和客户谈合作。如果他做其他事情对公司而言收益更大，从机会成本的角度考虑，是不是应该请一个专业的产品经理来解放自己的部分时间？

就算老板能者多劳，产品工作亲力亲为。当产品变得越来越复杂，或者公司有了多个产品，他会不会忙不过来？是不是就需要产品经理来分担自己的工作？

2.1 三个级别

张小龙在 2019 年 1 月的微信之夜调侃道，每天有 1 亿人教他做微信。很多微信用户都有一种幻觉，觉得产品经理这个岗位太简单，觉得张小龙太笨了，要是能听从我的建议，微信不就更好了嘛。知乎上关于“微信最应该增加的功能是什么？”的问题，有超过 2271 个回答。下面我们一起来分析一下，为什么地球上没有几个人能教张小龙做微信。

微信最应该增加的功能是什么

首先，这 1 亿人是从来哪里来的？都是麦田里的稻草人吗？还真不是稻草人，上面的 2000 多人只是冰山一角，现实生活中对微信指点江山的人更多。下图描述了邓宁—克鲁格心理效应，左边的愚昧山峰上人头攒动，这 1 亿人中的绝大部分就在这里，包括部分新手产品经理。

邓宁—克鲁格心理效应

很多心理实验表明，人类对自己的行为和情绪缺乏理解和掌控，对于外部世界也一样。承认自己无知会显得很低能。大家可以看看猫猫狗狗，它们对很多事情很无知，自己是怎么翻身摔到地上的都不知道。人类高明的地方在于通过持续不断地“说谎”（大多数时候是自己骗自己）来解释正在发生的事情，这样看起来会显得比较靠谱。有些科学家认为，人类的意识只是一个“叙事重心”，潜意识递上来什么稿子就念什么稿子，看不懂稿子也不要紧，保持镇定，一边编造一边念，所以很多时候我们“不知道自己不知道”。当一个人不知道产品经理的工作内容是什么，不知道产品经理需要具备哪些行业认知的时候，就会更容易认定产品经理都是笨蛋。

助理级产品经理

如果我们把产品经理分为助理级、总监级、老板级三个级别（大体对应实际工作中的产品经理、总监、老板），助理级产品经理对应的工作能力要求是：可以对某个产品进行“逆向工程”，产出逻辑自洽的产品需求文档。简单总结成两个字——“会抄”。在我看来，“抄”是个中性词，并不是抄袭的意思，而是代表一种模仿能力，有些人可能喜欢用“借鉴”，我觉得“抄”更简单直白。

“会抄”还是“不会抄”，一个问题就能分辨，“为什么这么做？”如果得到的答案是“某某产品就是这么做的”，那就是“不会抄”，只知道诉诸权威。如果产品经理能够运用逻辑来回答问题，就是“会抄”，比如，“这样可以让按钮变得更醒目，有机会提高点击率，进而提高付费转化率，我们可以用A/B 测试验证一下”。

请这 1 亿个能教张小龙做微信的人“抄”一下 Kik Messenger 或者 WhatsApp，就会发现 99% 的人做不到看似简单的“会抄”。大多数人逻辑混乱，无法充分理解现有产品并在此基础上把产品模块划分清楚，做到不重不漏（也就是符合 MECE 法则：相互独立、完全穷尽），比如模块 A 和模块 B 都包含了子模块 C。

2011 年 7 月，可口可乐在香港推出了“CHOK獎”应用，用户在电视播放可乐广告的时候摇动手机就能参加抽奖，奖品多达 120 万份，总价值超过 2000 万港币。2011 年 10 月，微信加入“摇一摇”功能，摇动手机可以发现同一时刻也在摇动手机的人。假设，微信的“摇一摇”是“抄”可口可乐的“CHOK獎”，这是简单的照搬照抄吗？

并不是。微信发现了“摇”所蕴含的游戏化体验， “抄”了这个交互方式帮用户发现新朋友，等到 2015 年春节微信“摇一摇”红包登上春晚舞台，抽奖又只是微信摇一摇的众多功能之一了，这时的“摇一摇”和“CHOK獎”也不是照搬照抄的关系。当然这只是假设，也许微信并不了解“CHOK獎”应用。

可口可乐的游戏化广告“CHOK獎”

愚昧山峰的人都筛掉后，还剩下 100 万人，这大概就是互联网产品经理的从业人数了。

有个笑话，“万事俱备，就差一个程序员了”，为什么没人说“我们团队什么都能开发，就差一个产品经理了”？

一个原因是，但凡靠谱点的团队都是先想好了做什么再根据要做的事情组建团队，需要开发应用就招 iOS 开发、Android 开发，需要开发小程序就招前端开发，每个岗位的人到位后马上就能开展工作。反之，如果工作内容不明确，是很难招到人的，即使招到人，等产品经理到位后才能开工也是人力浪费。

另一个原因是，很多人低估了产品经理这个岗位，大不了来一句“咱就照着某某某抄嘛”。事实上没这么简单，即便是助理级产品经理，也需要能拿得出逻辑清晰的产品需求文档。之后进入产品开发阶段，要等产品开发完成且发布后才能检验整个团队的工作成果。由于产品需求文档、开发质量、市场竞争等多个方面会影响产品的市场表现，多因一果让评估产品经理的能力变得很困难，相对容易出现滥竽充数的情况。反观程序员，他们的工作成果通过代码能否运行便能得以验证，快则几分钟，慢则几小时。行就是行，不行就是不行，写不出能运行的代码却硬说自己能做程序员的人大概率是疯了。

总监级产品经理

总监级产品经理对应的工作能力要求是：能够看到更多产品干系人，能够看到用户需求的多面性，能够在矛盾中合理地取舍。

看到更多产品干系人

在家庭宽带和网络游戏刚刚开始普及的年代，A 游戏公司和 B 游戏公司就已近进入了竞争态势。A 公司率先观察到三个情况：很多男性用户喜欢在网吧里玩游戏，男性用户的老婆则更希望老公呆在家里不要往外跑，电信运营商在推广家庭宽带但是缺乏足够吸引人的使用场景。如果游戏公司和运营商联手推广家庭宽带和网络游戏的打包服务，男性用户玩游戏更方便了，男性用户的老婆举双手支持，家庭宽带有了吸引家庭用户的使用场景，游戏有了更多用户，激励相容，多赢。

A 公司说干就干，和各地的运营商谈合作。运营商负责游戏服务器的购买和打包服务的推广，游戏公司在打包服务中赠送游戏道具，并且按游戏的同时在线人数结算游戏服务器的带宽成本，大概的成本核算方式是这个月的同时在线达到了 10 万人游戏公司就付给运营商 10 万元。这个合作模式毫无意外的成功了，运营商拓展了家庭宽带的用户规模实现了收入的稳步增长，A 公司也赚得盆满钵满。

B 游戏公司看到这个模式后也迅速跟进，但合作落地的效率和效果都比 A 公司差了很多。两家公司和运营商的合作模式几乎是一模一样的，除了开展合作的时间略有先后，还有一个细节差异，A 公司的游戏支持 10 万人同时在线需要 30 台服务器，采购成本大约是 50 万元，B 公司的游戏支持 10 万人同时在线只需要 3 台服务器，采购成本大约是 5 万元。从技术实力来看，B 公司笑 A 公司不懂优化。从运营商的采购成本来看，A 公司笑 B 公司不懂生意。“适当”的采购成本，比如游戏公司支付半年带宽费就能覆盖服务器成本，更利于调动运营商的资源，而网络游戏好不好玩和同时在线用户数是紧密相关的，哪个游戏的同时在线用户数先涨起来哪个游戏就会占据优势。

从这个故事中我们可以看到，产品的干系人并不只有用户，还包括用户身边的人、合作伙伴、合作伙伴中的具体负责人、产品团队、竞争对手、监管机构等等。如果对用户进行细分的话，可能又包括内容消费者和内容生产者，买家和卖家，顾客、骑手和餐厅等多个群体。关于用户身边的人对用户和产品会产生什么影响，我们可以看看苹果公司的案例。早期的苹果笔记本电脑在合盖状态下 A 面的苹果标志对于电脑用户而言是正的，苹果叶子朝外，但掀开 A 面之后用户身边的人看到的苹果标志是颠倒的，苹果叶子朝下，后来可能产品团队终于发现这个设计会显得苹果用户比较傻，就将标志的方向调换成了今天这样，打开后苹果叶子朝上。

思考题：通信软件为什么都有删除消息的功能？

产品团队需要数据平台、运营工具等提高工作效率，这些都是提升产品竞争力的重要需求。竞争对手会和你抢市场份额，监管机构会提醒你不要违反公序良俗、要保护未成年人。

相比助理级产品经理在思考问题的时候经常会从“我喜欢”“我习惯于”这样的普通用户视角出发，总监级产品经理则能跳脱自己的单一视角，用同理心来思考问题，比如“内容消费者想看什么”“内容生产者想得到什么”“黑粉想干什么”“小广告机器人的程序怎么设计”“产品团队需要什么”“竞争对手希望看到什么”……

同理心

看到用户需求的多面性

不同的产品干系人有不同的需求，有些需求是统一的，有些需求则是矛盾的。喜欢指点江山的“键盘侠”是意见领袖的天敌，微博的取舍是给粉丝数 10 万以上的博主全站拉黑禁评恶意评论者 3 天的权力，让意见领袖可以压制“键盘侠”。有些用户喜欢消息显示已读状态，有些用户不喜欢，觉得这样压力太大；有些用户喜欢发语音，有些用户不喜欢收语音，微信的取舍是不“抄”消息已读“抄”对讲机。

单就个体用户而言，他的需求也经常是相互矛盾的，比如对智能手机的需求，又要大屏幕，又要续航久，又要轻薄，又要键盘手感好。黑莓选择了小屏幕加实体键盘加三天一充，iPhone 选择了大屏幕加虚拟键盘加一天两充，不同的取舍造就了不同的产品渗透率和不同的市场地位。

所以，同理心需要对干系人的多样性有认知，越全面越好，也要对每类干系人的需求、想法和感受有认知。当我们具备了这些认知，就像在脑中建立了一个虚拟机，想要进入哪种角色，就在干系人列表中选取，启动运行，这样就能模拟他对产品的使用目的、使用方法和使用体验。

在矛盾中合理地取舍

打造产品需要做的事情有一大堆，资金和时间却是有限的，这是一个矛盾的三角形，对产品需求进行合理的排序也是一种取舍。谷歌给公司里忙于应付事务性工作的人起了个绰号叫“伪工作者”（Pseudo Worker），这些人每天忙到飞起，却没有什么有效的产出。如果产品经理是个伪工作者，整个产品团队都会跟着他陷入伪工作，这是很可怕的。总监级产品经理能够筛选出当下预期产出最大的工作，并按照预期产出的大小对需求列表进行排序，剔除伪工作，从源头确保整个产品团队能够持续高效地产出。

助理级产品经理容易产生新功能冲动，觉得做产品就是不断堆砌新功能、新模块，产品越庞大越复杂就越厉害。雷军说：“不要用战术上的勤奋掩盖战略上的懒惰。”这句话对于助理级产品经理不适用，因为助理级产品经理不是在战略上懒惰，而是暂时还不具备战略能力，最喜欢下图这样的解决方案。

助理级产品经理的解决方案

总监级产品经理则明白一个道理，支线功能的丰富解决不了核心体验的瓶颈问题。相比支线功能，产品核心体验的使用率和使用时长必然是整个产品中最高的。核心体验如果存在瓶颈，就会限制用户留存率、用户生命周期价值（LTV）、投资回报率（ROI）等产品竞争力的关键因素，因此突破核心体验的瓶颈才能提升整个产品的用户留存率和用户生命周期价值。用户留存率上升，每日新增用户不变的话，日活跃用户数（DAU，简称日活）就上升了，产品的市场份额就扩大了。用户生命周期价值上升，单个用户获取成本（CPA）不变的话，投资回报率就上升了，产品就更容易实现盈利。

瓶颈的重要性并不是我发现的，早在 1984 年，以色列学者伊利雅胡·高德拉特（Eliyahu M.Goldratt）就提出了限制理论（Theory of Constraints，TOC）。这个理论认为，一个复杂系统，在任何时候，只有极少的瓶颈会限制该系统达到更高的目标。简单来说，就是一条路总有一个最窄的地方，这个最窄的地方决定了整条路的承载能力。当这个地方被拓宽，原来次窄的地方就会变成新的最窄的地方，因此寻找和突破瓶颈的工作不是一次性的，而是一个不断循环往复的过程。

与产品核心体验相关的需求，就是可以优先考虑排期的需求；与产品核心体验无关的需求，坐冷板凳等着吧。比如一个短视频应用在做完基础的看视频、发视频功能后，是把短视频的内容丰富起来，推荐系统搞起来，能更快地提高用户留存率？还是做一个用户动态信息流能更快地提高用户留存率？哪个需求和产品的核心指标相关性更强？短视频里的用户动态信息流大概会有多大比例的用户使用？在内容产品中增加用户动态信息流模块和在社交产品中增加用户动态信息流模块相比，价值一样吗？

80/20 定律：80% 的产出来自 20% 的功能。将这 20% 的功能提升 10% 的效率，整体效率就提升了 8%；将其余 80% 的功能提升 10% 的效率，整体只提升 2%。把握住重点，就把握住了杠杆。

拥有同理心、能够“扮演”多样化的产品干系人，并且能够做到在矛盾中取舍，这些能力要求又筛掉了 99% 的助理级产品经理入围者，还剩下 1 万人。

如果要给自己评级的话，我大概在总监级。

思考题：假设“对讲”（发送语音消息）和“附近的人”这两个需求同时出现在了微信 2.0 的需求列表中，但由于版本排期问题只能先做其中一个，应该先做哪一个？为什么？

老板级产品经理

老板级产品经理对应的工作能力要求是：对世界有深入的理解，能够发现巨大的产品机会，能够应对激烈的竞争。

伟大的产品可能始于微小的开端，但绝对不会缺少对世界的思考。苹果电脑，人脑的自行车。DOS，让用户和开发者更高效地操作电脑。谷歌，如何更高效地检索信息。iPhone，移动互联网应该是什么样子。微信，人和人、人和机构、人和物应该怎样连接。如果说宗教是在思考人类如何获得幸福并且给人类提供思考和行为上的建议，产品则可以把美好生活直接送到每个人的手中。从这个角度看，大家称呼乔布斯为“教主”并不是过誉。

老板级产品经理会预先设想产品的演化方向（初代 iPhone 发布会刚一结束，艾伦·凯就和乔布斯在聊平板电脑了），推导出产品演化路线图，找到可行的产品切入点，并且预判路线图上的竞争对手都有谁，在什么时机可以主动开战。微信为什么要做摇一摇、二维码、支付、小程序？这些产品概念是从哪里来的？这些功能点发布的时机是如何选择的？现在回头复盘也许答案是很清晰的，可是在胶着的竞争中，总监级产品经理的 1 万人里有多少人能想到这些创新，并把握好竞争节奏？可能又要筛掉 99% 的人了，还剩下 100 人。

请注意，这 100 位老板级产品经理是分散在不同领域的，每个人的行业认知各不相同，能在即时通信领域教张小龙做产品的到底有几个人，大家可以琢磨琢磨。

2.2 团队角色

产品经理在产品团队中的位置通常如下图所示。

产品经理在产品团队中的位置

理想情况下，公司老板是老板级产品经理，公司内几个产品团队分别做不同的产品，每个产品团队都配置总监级产品经理带几个助理级产品经理。而现实的情况是，50% 的互联网公司可能从上到下找不出一个总监级产品经理。

公司老板或部门经理负责制定产品战略和把握竞争节奏，产品经理（或产品总监）负责需求排序、文档输出、测试验收、实验数据分析。不看老板或部门经理这一层的话，产品经理（或产品总监）通常和运营、开发、测试、营销等岗位是平级关系，主要通过产品需求文档和非权力性影响力来引领产品团队。

产品需求文档中的产品需求来自很多方面，比如用户需求、部门经理的战略布局、竞品动态、运营团队需求。开发团队也可以提出重构需求或系统优化需求，产品经理负责整理和归档所有需求，并排序筛选出最紧要的需求，输出产品需求文档。也就是说，部门经理也好，运营团队也好，开发团队也好，想要对产品做出改变，都要经过产品经理，产品经理通过产品需求文档引领整个产品团队的工作。

在实际工作中，部门经理可能会否定产品经理的需求排序，而把自己关心的需求调整为最高优先级。运营团队和开发团队可能也会这样做，揣着“凭什么产品经理能对排序说了算，我们说了就不算”想法的人不在少数。产品经理和运营、开发是平级，无权强压他们的想法。产品经理还是部门经理的下属，部门经理倒是有权强压产品经理。这时候就需要产品经理发挥非权力性领导力了。

非权力性领导力

产品经理的非权力性领导力主要体现在两个方面，一是逻辑，二是成功案例。

《三国yanyi》中，曹操想联合孙权铲除刘备，孙权身边的谋士基本都赞成甚至劝孙权直接向曹操投降，只有鲁肃觉得这件事不靠谱，提议联合刘备抵抗曹操。鲁肃自己没办法说服孙权和其他谋士，就请诸葛亮过来给大家分析了一波。诸葛亮并不是孙权谋士们的领导，甚至连盟友都还不是，为什么他能舌战群儒，说服东吴七个谋士呢？靠的是逻辑。

老板说，我们要自建广告系统，自建广告销售团队，提高广告收入。产品经理分析完这个需求说，我们的日活跃用户数只有 10 万，广告主们没办法直接采买日活这么少的广告，等到日活 1000 万的时候再考虑吧。开发人员说，我们要优化系统为 10 万用户同时在线做准备。产品经理说，我们现在只有 8000 用户同时在线，如果现在不快速提升留存率，产品能不能活到 10 万用户同时在线那一天都成问题。正常情况下，大家都是认逻辑的，产品经理的逻辑越清晰越严密，影响力就越强。

成功案例是在工作中逐渐积累的，某成功产品的产品经理出来创业，立马有人投钱，因为投资人都相信他。像这样有成功案例的产品经理，开发团队会不会先相信他试试？如果没有大的成功案例，只要日常工作中的大部分需求实现了既定的增长目标，也是成功案例，团队也会觉得这个产品经理靠谱。靠谱的光环越强，产品经理的影响力就越强。

产品、运营与增长经理

职场新人可能对产品、运营、增长经理这三个岗位分不清楚，我简单啰唆两句。这三个岗位的主要区别在于赢得市场份额的方式。

产品经理通过让产品发生变化来赢得市场份额，实施变化的方法是写产品需求文档来调动开发团队。产品本身无法解决的问题，比如招募意见领袖、“病毒”式营销等，就需要运营和增长经理帮忙了。

运营经理主要通过个人能力来赢得市场份额，比如刚刚讲的招募意见领袖，还有策划线上活动，筛选优秀内容，平息用户纠纷，等等。有多少个需要关注的核心指标，就有多少个运营可以发挥的领域（广告投放也可以归运营岗位负责）。当运营需要改变产品来更高效地完成自己的工作时，比如开发一个活动用的小游戏，就需要产品经理帮忙了。

增长经理的工作大致分为两块，一是寻找标准广告之外的高性价比获客杠杆，比如“病毒”式营销。如果需要开发小程序或需要联系意见领袖，增长经理就需要产品经理和运营经理的帮助。之所以要把非标准广告获客单独拆成一个岗位，我想主要是因为它与标准广告混在一起的话就没人会费心思研究高性价比获客杠杆了，全投标准广告多简单啊。二是使用 A/B 测试等手段验证产品改动、营销计划、运营活动等变化的有效性，留下有效的变化，撤销负效果的变化，其中建设数据平台和 A/B 测试平台属于产品需求，需要由产品经理统一排期。

不同的公司，不同的产品团队，会有自己的岗位组合和分工界限，比如有些公司有中台部门提供现成的数据平台，不需要每个产品都自建一套。有些公司会把产品经理细分为功能产品经理和策略产品经理，本书所描述的则是宽泛的产品经理。所以，大家要以自己所处的环境为准，职场新人有问题的话，要多多请教公司给自己分配的导师。