周末和几名工程师吃饭，席间他们吐槽自己遇到的奇葩产品经理，突然他们想到我也做过产品经理，就打个补丁说“我是例外”。其实我比他们看得更透更开，IT圈内，菜就是原罪，我比他们更讨厌低端产品经理。
我写过很多云产品的规划、设计、实施、包装、运营的公开文章，我多次参与产品线绩效评估和产品经理能力评估，我那本《云计算行业进阶指南》全书一半的篇幅都是在介绍云产品，还有章节介绍产品经理如何汇报和输出文档，所以我能评价（ToB IT行业的）产品经理。在此我结合自己的书稿，写一篇解析云计算产品经理工作的“深读实证”系列文章。本文的核心论点如下：
产品经理不用学习“雷周张”
产品经理是同名不同义的两类人
给产品思维等新名词祛魅扒皮
提出功能需求，并不是重要工作
产品经理的关键工作都很难做
工程师不要想着转岗做产品经理
看完本文想买书的朋友，可以点击下列链接：
1. 不用学习“雷周张”
雷军、周鸿祎、张小龙，都在职场辉煌中说过“我只是个产品经理”，很多产品经理也将“雷周张”视为职场偶像。但我明说，产品经理把这三位大佬挂在嘴边有点“汝之不惠甚矣”，原因有四点：
崇拜偶像，应该是借鉴和实践偶像的成功路径，而不是羡慕偶像成功后的资源和权力。“雷周张”都有公开可查的履历，他们都是天才程序员，废寝忘食的写出过明星软件。谁要是崇拜他们，应该实践偶像的成功路径，努力成为天才程序员啊。没有这个技术实力，那你们崇拜他们做什么啊？
在“雷周张”做个人IP时，为了避免制造疏离感，他们刻意隐藏了技术天才和老板富翁的身份。基于中文常识，当大佬含蓄低调的说“我只是个XXX”时，XXX都是类似于“犬子、贱内、贫僧/贫道/贫尼”这类略带自贬的称呼。也就是说，这几个大佬没有夸奖产品经理是个高大上的工作。
“雷周张”是老板和高管，所以他们的资源调度权限远超普通打工者。很多产品经理模拟“雷周张”的工作方式，找研发提需求，找销售和运营要业绩，又不知道怎么跟领导汇报，结果把自己玩成了扯虎皮做大旗的传声筒。
时势造英雄，不要刻舟求剑。“雷周张”做产品设计的时代，只有天才程序员才知道IT技术的明确能力预期。但现在的客户需求清晰、技术可行性明确、友商竞品雷同，就算是天才程序员转岗做产品经理，也难以复现“雷周张”的产品奇迹。
2. 给产品经理做分类
在大产研体系内，如果一个从业者不做具体的技术工作，也不为单个客户负责，当他找不到其他更时尚炫酷的头衔后，就可以自称产品经理。做产品设计的是产品经理，催研发进度的是产品经理，保障节点建设和资源运营的也可以是产品经理。很多产品线招聘的方案架构师，其实是专注于产品对外包装工作的产品经理。
因为产品经理是一箩筐工作岗位，所以从业者鱼龙混杂，按照工作能力可以分为三类。其中“雷周张”是万里挑一的特例，不到20%的产品经理是值得尊重的产品设计师，大于80%的产品经理就是负责喘气儿的“产品文档助理”。
云计算行业内，不超过20%的产品经理做各种高难度的产品推演、业务抉择和施工调度，即使高级研发也很佩服我们的能力、尊重我们的工作。我们不想自称产品经理，而是更想继续自称工程师，但是同事们看我们不写代码不登录服务器，就非说我们是产品经理。为了和下文的“产品文档助理”做区分，这类产品精英可以称为“产品设计师”。
80%的产品经理就是“产品文档助理”，他们做产品经理就是因为太笨或太懒，既无法做IT工程师，也不敢去销售线拼业绩。他们主要的工作包括但不限于：开各种扯淡会、在Jira里提需求、画思维导图和产品原型、无压力拜访客户、撰写使用文档。这些工作高级研发都能自己完成，但研发懒得做甩出去了这些下脚料工作，所以他们就是“产品文档助理”。
产品经理的本职工作包括了包装宣传，但是，因为80%的产品经理都是产品文档助理，无法完成这些基础工作，影响了管理层对产品经理的认识，进而导致云产品线在招聘“产品方案架构师”。这些“产品方案架构师”就是最常规、最普通的产品经理。这种行为就像你招了个打字员只会打汉字，然后你就又创造了一个“英文打字员”的新HC。
3. 给产品新名词祛魅
优秀的产品设计师会很谨慎的对待每一个名词概念，尽量用简单易懂无歧义的旧名词解释自己的理念。但是很多高管和产品文档助理都喜欢生造出来一堆有“产品思维”的新名词，这些词既不简单、又不易懂还充满了歧义，所以我要对这些词做一做辟谣祛魅。
80%的产品经理都是产品文档助理，而且他们大多没见过真正的“产品设计师”，缺乏学习榜样，只能空喊各种“产品思维产品力、优势抓手要对齐”。造新词看似是个时尚行为，但实际上是为了掩盖思维贫乏和无趣无知。
一个劳动者做好本职工作后，又有一点跨界思维和分析能力，就能拥有产品思维。产品思维是个很普通的职业技能：只要你能将“技术思维、运营思维、服务思维、客户思维、管理思维、财务思维……”等等任何两个工作思维先做一下跨界交叉，然后做一下汇总抽象，再推进具象实施，那你就不缺乏产品思维。
产品文档助理并不理解技术、运营、服务、销售等工作，没办法完成多种思维的交叉和抽象。为了给自己在简单问题上交白卷找理由，他们就要把产品思维吹嘘成稀缺的灵感。他们在自我感动、敷衍周报或者高管逼迫下，用产品经理的身份扯一堆谁都听不懂的废话，并且神秘兮兮的说这就是产品思维，这些职场求生表演既可笑又可悲。
虽然明明有“产品竞争力”这个老词，但高管骂产品经理给自己缓解焦虑时，却不提“竞争”两字，而是故作高深要去探寻“产品力”。产品销售是个复杂的过程，云产品本身有竞争力，不代表客户会抢着送钱。比如，某些云产品技术差功能少，但价格比友商便宜，这也是有产品竞争力啊。
大家稍微读点正经的管理学书籍，就会发现，所谓“产品思维、抓手对齐”等新词儿，和非互联网企业强调的“全局意识、沟通协作”没有什么本质性区别。公司大了流程长了，要求高阶人才“不仅要”低头干活，更要抬头看路。但是，绝大部分产品文档助理，在没有能力低头干活的基础上，拼命强调“我喜欢/擅长抬头看路”。
4. 提需求没有多大功劳
产品文档助理就指着“提需求”这个动作填充工作周报，他们也喜欢把产品成功归功于自己提好了需求。但是，几款重要云产品的成功过程，都和发掘产品需求没多大关系，而是产品水到渠成、市场自然演化的结果。
云产品需要做很多关键的决策，比如一款产品是收费还是免费，产品靠内存还是带宽盈利，要不要投资新建南极节点，这都很考验产品经理的工作能力，但这些工作是后台抉择，不是前台需求。本节是为了说明，某些产品经理在“抄友商、听老板、拍大腿”后提出类似于“虚拟机需要支持重启”这类功能需求，对云产品的发展没有多大的贡献。
满足客户需求和产品成功、产品线团队成功没有必然关联。“满足客户的功能性能需求”，这是一个60分基础需求，确实会拖累产品成功和产品线成功，但不会直接导致产品成功。
产品成功的标准是，客户认可这个产品的表现形式、功能性能，并主动适应产品的设计去购买使用产品，多家云厂商设计的产品功能都趋同演化了。公司考核产品线是否成功时，会考核产品线的营收、利润、成本、粘性、生态等运营指标，这些工作和提需求的动作没有必然关联。
云产品的功能非常明确，需要靠产品经理构想新功能的工作并不多。IaaS云产品必须去模拟替换客户的IDC旧方案，比如云主机模拟物理机资源、模板化云主机模拟维护软件工作、裸金属模拟交付硬件工作；PaaS云产品对客户只提供一个API接口，各云之间的API语法、功能都深度兼容。
很多云计算亲历者亲眼所见，云产品在大幅进步，不断的完善功能。但是，进步大是因为起点低，那些“不断的完善功能”对应的是“一直很清晰明确的需求”。这里没有感动和功劳，只有苦劳和渎职；某些产品经理看不懂需求，某些技术团队完不成常识性技术工作，让本该很快完工的工作拖沓到三五年完成，有什么值得夸耀的？
此外，我多次公开支持给客户定制产品、给客户做技术服务、让产品可集成可维护，这看似又给产品增加了大量的功能需求。但是，“以客户定制为目的的需求”，也可以是标准需求，给客户做技术服务，也可以做成服务产品化。在一些商业软件和友商实践中，早就把这些定制需求制作成了标准常规需求。只是这些需求比较生僻，很容易被误解成新需求。
很多产品文档助理把客户当做免费的灵感收集器，以自己能听懂为前提，把“客户随口一句话”断章取义成工作目标。产品设计师必须比客户还了解客户，产品上线时也已经满足客户绝大部分需求，“客户的反馈”只是验证产品设计的辅助证据。这也是产品经理不向单一客户负责的重要原因，因为产品可以筛选承接客户需求。
我做产品经理时，产品已经实现了该有的关键功能，也有明确的预设产品场景。当客户给我提需求时，我会拒掉大部分奇思妙想，只承接少量真实需求。在我们做出合理的拒绝后，客户会更认可我们的专业性。对于少数恶性Bug或者客户急需的需求，我们确实会立刻加班推进，但事后我会对导致加班的产研纰漏进行复盘追责。
5. 介绍云产品经理的重要工作
在云计算产品实践过程中，功能需求、产品决策都不是产品经理的重要工作，云产品经理最重要的工作就是数据分析。为了证明自己确实有数据分析能力，产品经理需要向协作方输出大量的文档。我书稿的第15章节对这些工作有严谨完整的描述，本节只针对四个常见问题进行说明。
第一，产品需要做出决策，但绝大部分产品经理没有产品决策权，日常决策权在产品总监手里，重大决策更是要企业管理层来拍板。
比如，给产品调整媒体报价后，要考虑哪些前后台依赖，可以当做产品经理的面试考题。比如，产品线只能发出建设或裁撤节点的建议，需要管理层结合营销计划进行决策确认。再比如，要不要为了压缩成本降低硬件维保标准，普通产品经理明显承担不了相应的风险责任。
第二，每个产品都有至少有数百个能力细节，产品经理需要提炼总结出关键能力，在对外沟通汇报时，只需要介绍自己完成了哪些关键能力，销售和服务环节如何承接。
比如，产品线给领导汇报时，领导只想听“通过达到A标准，节省B%的成本，拿下大客户C”，其他的功能细节都是表忠诉苦的表演而已。再比如，产品经理喜欢给同事做又臭又长、废话连篇的产品培训，但是销售只会听三分钟以内的简短产品介绍；售前售后能够接受不超过20分钟的产品培训，且不保证记忆效果，需要辅助查阅知识库。
说到这里，我忍不住吐槽一些三流产品文档助理。我参加公司层级的产品评审时，一个产品经理直接介绍了十几个功能细则，十几个参会的产品经理把无责任闲聊当做评审过程。我忍不住大骂：“我们是来审查你们的产品规划可行性和逻辑严密程度的，不是替你做功能细则的茶话闲聊的，这是年度总结会，你想让我总结出你在瞎忙？”。
大家去参加云厂商的各种大会时也会看到类似的场景：一旦到了产品线分会场，80%的产品经理都是在宣讲一些犯困的功能细节，读者们没必要听懂这些只适合当工作周报的功能细节。
第三，产品经理对于签单增收能发挥重要的支持作用，对于降本增效能发挥决定性作用，所以产品经理必须为业绩负责。产品经理不能只是简单的罗列营收和利润数字，而是必须同时分析多种产品运营数据，观点逻辑自洽且能够见微知著。
这些产品运营信息包括但不限于：客户行业、营收分布、产品用法、资源调整、人力成本、产品迭代、故障影响、友商行动。产品经理在年度规划总结和季度例行汇报中，都要以管理层能听懂的话术进行汇报。
产品文档助理在要权限要资源时，会强调自己要为产品业绩负责，但是，在不检查胜任能力，也不倒扣工资的前提下，他们所谓的负责就是“零成本上赌桌试运气”。在云行业狂飙增长的年代，虽然他们努力让本公司的增长率从100%降低到了50%，但不耽误他们赚得盆满钵满。当云行业增速放缓时，因为其他厂商、其他产品线也没完成业绩，这些人也不会显得特别平庸无能。
我的书稿7.3章节就是在引导管理层该如何考核产品线，该章节明确介绍，产品经理能做多大业绩数字，主要看公司让他管理的是不是“主力营收型云产品”，还要看公司的推销政策和市场波动。管理层要考核产品经理，不要“拿着结果倒找原因”，而是要关注产品经理是否能解释营收逻辑，是否及时发现和应对异常业绩数据。
第四，产品经理必须完成产品定义工作。“产品定义”不是说一堆晦涩难懂的产品思维废话，而是明确告知客户和销售，产品承诺了哪些能力特性，明确告知实施和服务的同事，对产品必须做到哪种力度的支持。
下列工作只有产品经理有权限定义，其他人帮忙干活很容易被反咬一口和事后追责：明确产品内部定位、预设客户和应用场景、严谨SLA定义、对外宣发口径、竞品分析和卖点优势、用户测试方法和报告、产品规格和实施周期、售后答疑和后台处理、资源运营标准、技术交付和维护标准、异常事件对接流程。
产品文档助理完不成上述任何一个工作，他们只能或者装傻不做、或者赖给售前和研发。比如，一个产品没有严谨SLA定义、资源和维护标准，那产品的成本推导就是观测线上数据后随口编出来的。再比如，他们缺乏客户级实操能力，没读过线上支持文档，文档内容都是研发帮写或者抄袭友商。还比如，很多产品经理根本没有预设客户场景、没做过实质性竞品分析，没有推荐的产品卖点话术，销售就只能跟友商竞品比价格。
6. 不推荐工程师转岗做产品经理
很多朋友做工程师做累了，都想过转岗做产品经理，认为这是个可以多指挥、少实操、还能多拿钱的工作。但是经过前文分析，我不推荐工程师转岗做产品经理。
首先，十几年前，领导们不懂泛IT行业，行业快速自然增长，领导们为了满足管理焦虑，就把产品经理的岗位拔高了。但现在领导们开始懂IT了，行业增速恢复常态，各国对互联网（以及背后的金融圈）管理越来越规范了。风停以后，产品经理的时代红利也要结束了。我现在写这种得罪人的扒皮文章，就是判定普通产品文档助理已经没有靠运气变成明星产品大佬的机会了，而那些已经上岸的幸运儿不会给我找茬儿，而是会和还在苦海扑腾的兄弟们做彻底切割。
第二，工程师是产品经理的下游部门，所以看来产品经理好似悠闲不干活，但在工程师的视线之外，产品经理过的很焦虑。无论是货真价实的产品设计师，还是混日子的产品文档助理，是否能完成业绩主要看销售和友商的运气，汇报是否挨骂主要看领导今天的心情。技术人员遇到超出能力范围的工作，还能摆烂不干，当产品经理被领导逼着“找出产品力”“产品要创新”时，明明毫无头绪还要假装很有信心，这不是什么好营生。
第三，产品经理的职场收益并不比工程师更大。当级别较低时，产品经理比工程师收入要略低。高级产品经理确实和技术专家的待遇差不多，但是高级产品经理对智商和勤奋的要求和技术专家一样高，继续做技术专家更稳定。以我为例，我依旧拥有“技术专家称我为技术专家”的技术分析能力，如果我这些年一直在技术序列打怪升级，绝对比转行做产品设计的收益大，职场压力也小很多。
第四，极端情况下，二流工程师可以兼职做产品文档助理。我前文说过了，那些产品文档助理的工作都是研发懒得做的下脚料。产研团队如果要极致化降本增效，二流工程师可以捡起来产品文档助理的工作，被分流的一定是产品文档助理。
那些在技术团队不如意的工程师们，学习产品思维也不难，可以买我一本书，看看云产品到底是怎么设计的。
625
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
