一个云产品经理的自我检讨

从事产品和运营工作6年了，ToB和ToC都干过，以ToB为主。最近2年多，又在做云产品的规划、落地和运营，有些体会和教训，总结一下，于人于己都有些好处。因为云是典型的ToB产品，同时又带有ToC属性，我就以云产品经理为例，具体说明我的看法。

一、定义：当我们在谈产品经理时我们到底在谈什么

什么是产品经理？

不仅国内各公司的看法不一样，国外看法也不尽一致。业界的很多看法，我觉得都有失偏颇，或者夸大了产品经理的作用，又或者管中窥豹，只看到了一点执行工作的皮毛。在我理解里，产品经理就是基于对业务的理解，整合所能触碰到的资源，来达成用户体验，最终实现商业成功。产品经理就相当于这个产品的“小老板”，整合研发、运营、销售等一切可能利用的资源，来达成自己的目的。

没做过产品经理的人呢，也容易对这个职业形成两极的看法，如我在之前的一篇文章说的：

媒体的炒作，导致产品经理这个岗位很热门，也很浮躁，鱼龙混杂。媒体的炒作带来了许多认知误区，导致了一般人对产品经理产生不切实际的看法。

常见的误区有四个：

1. 人人都是产品经理

这句话害人不浅，就像说人人都是CEO、人人都是研发那样无用而有害。

为什么不说人人是CEO而说人人是产品经理呢？因为一来CEO的职位大部分人一辈子都达不到，不敢这么说；二来CEO、研发这类工作，是要求高度的专业性，一般人根本不了解局内人在做什么，想评头论足，更无从下手。

但产品经理可就不同啦，只要敢说敢骂，对一两个模块、一两个功能评头论足、说三道四再容易不过，特别是对ToC产品，随便下载个app，完全没入行的人都能列个十几二十条“不足和改进意见”。

为什么很少看到有人对ToB产品提出改进意见呢？因为专业性不足。比如：一台云防火墙，你要去评头论足，一般人就没底气了，你得了解常见的漏洞和防护方法，你得了解常见的拦截规则，你得知道绕过难易等。

2. 产品经理这个岗位比较优越

乔布斯、马化腾、张小龙等业界大佬曾以产品经理自称，因此给人感觉产品经理是特别炫目的职位。

可他们真是产品经理么？当然不是。

首先，他们是CEO，CEO当然有决策一切产品方向的权利，当然也有改变世界的资本。再者，他们的角色，说自己是产品经理是最讨好的。

为什么大佬们喜欢说自己是产品经理呢？

其实不外乎产品经理这个角色经常和产品打交道，说自己是产品经理，就是在暗示自己关心、重视产品质量，甚至像罗永浩那样非要把工匠精神往自己身上贴，都没啥不可以的，反正是和产品相关就是了，至于是不是真的干的是产品经理的事，谁在乎呢？

3. 产品经理岗是通往高管的好途径

实际情况是，行行出状元，互联网里也分了无数行、无数个工种，哪个岗位出身的人都可能成为高管。而且至少目前还没有数据表明，产品经理做高管的概率就大，实际工作中看到的也确实如此：技术、运营、产品、销售，什么工种做管理的都有，把自己的业务吃透做好就有机会。

4. 把产品经理变成了纯执行工种

这又是一种极端，没有对操盘整个产品的信心，只负责团队一些零散的琐事，没有把握产品的方向并且取得商业成功；也没有对用户体验的追求，不再相信好产品可以改变世界，彻底失去了做产品经理的初心。

总之，产品经理要看清自己的真实定位，不被外界所误导，既不高看自己的价值，也绝不降低自己的标准，失去产品经理的初心和情怀。

二、理解：对业务的理解是产品经理看家的核心竞争力

经常有研发同学调侃，你看那个产品经理，研发也没做过，运维也没做过，连个技术名称都看不懂，就会写写PPT，怎么做好产品经理？

其实这些调侃是有一定道理的，所以ToB产品经理特别是云产品经理，如果没有做过研发，背景是有所欠缺的，但也并非无法弥补，比如业余学一两门开发语言，其实也并不困难，特别是现在的开发语言入门越来越容易，研发也并没有一般人想象中的那么困难。

那万一确实就不是技术出身的，是不是在产品上就无达成很高段位的可能了？

不是的。产品经理需要懂一些业务相关的技术，这是基础，但还不至于能决定一个产品经理业的职业发展。产品经理因为要接触各个层面的资源和信息。因此这个岗位天然是比团队里一般人所能接触到的知识更多，一个优秀的产品经理，需要高速的学习能力，去把所接触到的各种知识，转换成能带来用户体验提升和商业成功的判断。这个判断，往小的说，就叫需求的取舍，往大了说，就是战略决策。

所以产品经理最核心的竞争力是什么？是在横向工作中，快速汇总信息、得出最正确的业务判断的能力。

三、定价：价格是产品商业模式和产品思考的最终体现

定价是门很复杂的学问，你的所有的商业模式和产品思考，最终都体现在价格体系里：为什么是这个价格，每个版本的用户群是哪些、能得到多少利润、能否养活团队、如何减小成本、与友商相比是否有竞争力等等，都可以凝练在价格体系里。

所有产品经理第二个重要的技能，就是要对商业模式洞察得非常清晰后，结合团队的投入、市场的环境，给出一个合理的定价体系。一般人看到“定价体系”，认为肯定很复杂，但其实对单产品，可能就基础版1万元、高级版2万元等，要看着很简单，让用户一眼就明了为什么是这个价格、是否合理。

这里面有几个坑需要跟大家说明：

（1）如果对用户群的分解和预期不是很明确，不要把一个产品分为什么“基础版”、“企业版”之类的，因为只要这么区分，就说明在同一个品类里，用户群的需求差异非常大，因此为了满足用户需求，而人为区分这么多细分版本。

如果用户群差异不大，或者没有运营数据表明有重大差异，就不要设置这么多版本。许多企业单纯为了宰客，设置了很多版本，起到的效果就是人为地限制客户使用各种常用功能，而并没有区分好不同用户群的功能使用边界，比如功能A是否就应该设置在高级版而不是基础版里？为什么？

（2）新产品定价。这里的新产品，不是指新开发的产品，而是指这个类型的产品，在市场里没有相同或类似的品类。这时定价就要按成本、价值和预期利润，给出一个定价。因为无同类产品可参考，实际是市场引领者的角色，因此要非常慎重，必须有专业的商业设计人员的参与，单靠产品经理的产品触觉可能还无法达成一个合理的价格。

（3）但大部分产品，都是成熟的，都有相同或者类型的产品在市场里售卖。这种情况，一般都采用跟随定价，也叫随行就市定价，不了解的人也叫“抄袭定价”，即参考领导者或者行业平均水平定价。

原因很简单，市场那么久了，自然形成了现在的普遍价格，并且是用户认为的“合理价格”，高出或者低出很多，对用户或对开发产品的企业，都不见得是好事。这时就要想办法把团队的投入成本降低到行业平均或者低于平均水平，否则做这个产品是没有前途的，还不如引入其他厂商的产品来运营。

（4）绝大部分企业研发的产品都是“半生不熟”的。什么意思？

就是市场上有相似的品类，但功能又不完全一样，这也是大部分企业所说的“创新”或者“微创新”，对无经验的产品经理，就会按照领导者的老品类来定价，结果利润无法保障，团队还额外投入大量的研发和维护成本。

因此，对“半生不熟”的产品，如果用户确实愿意为创新功能买单，就要单独区分出来，甚至重新定义、创造一个品类，或者通过定义品类品牌的方法，给这些产品重新定个名字进行营销，而不要跟随领导者的路往前走。

原因很简单：别人功能各方面都没你多没你好，你却跟别人的价格一样，你能赚到钱养活团队吗？养不活团队用户的体验和服务如何保障？无法保障的产品能活下来吗？可见定价是牵一发而动全身的事情，不可小视。

四、平衡：根据团队现有资源最大化产品体验和商业成功

对云产品经理来说，在一定的技术背景之上，就要从商业的角度去审查你所负责的产品，得出你的业务判断，做出具体的决定，来帮助团队成功。比如同是一个需求，有的人认为重要，有的人认为不重要，考量的依据是什么？

不是别人给你划定好的高中低优先级，也不是用户催的急不急，也不是销售团队压不压，也不是研发同学有研发人力无研发人力。而是在你现有团队的配置下，到底优先做哪些事情？方案的取舍的依据是什么？选这个方案而不是那个方案的综合考量是什么？也就是说，从成本、产出、用户压力、内部压力等各方面进行综合平衡后，才能得出一个合适的方案。

所以我经常说，即使是同一个云产品，同样叫“云服务器”，A公司跟B公司做出来的特性肯定是不一样的，因为A公司和B公司的人力配置和市场是不一样的，他们决定做哪些不做哪些，并不能完全按照理想的“规划”纸上谈兵地进行，而只能根据公司现有的资源和市场环境，不断调整。

大家可能经常看到一个现象，明明是门外汉的用户，却经常给专业的产品经理提各种“优化”建议，就像有十亿人教张小龙做产品经理一样，但其实长期当产品经理的人都知道，大多数时候，用户的建议对产品的价值都不大，只是因为很多用户看起来“很有必要”的需求，经过市场分析或者团队资源匹配，不做或者这个时期不做，是对产品最好的选择。

这就是为什么一般人看某个产品，总会生出“你个按钮居然放这里、那个功能不应该这样”的想法，然后觉得“我要是产品经理，这产品肯定好多了”的幻觉。

内部团队也会有许多的质疑，比如说你的这个体验不行、那个工单太多要降下来等等，但要坚定自己的判断，综合团队的情况做最佳的选择，把人力用在最优的产品需求上，而不必过于计较各种声音。

一个有经验有信心的产品经理，不应该被用户牵着走，也不应该为内部其他团队的声音牵着走。这并不是说不要听用户和其他团队的声音，他们声音当然是最重要，但要以专业的眼光去判断和取舍，这才是更深层次的对用户负责，或者叫对绝大部分用户负责。

五、销量：销售团队是产品经理的第一客户

云产品，创始阶段（5年左右），主要的用户来源肯定是也只会是销售地推，这和一般的ToB产品并没有什么不同。

我在之前的文章也一再说过：ToB 产品本质是帮助企业提高生产效率的工具，企业消费，除了有可见的购买成本，还有不可见的更高昂的维护和迁移成本；因此整个过程是是理性的、专业的、团队化决策的。

每次采购，涉及的关键角色很多，至少有使用方、评估方、预算方、拍板方、签字方共同参与；不像个人的冲动消费，完全是个人决策，如在淘宝买一件衣服、安装一个 App 。

企业消费的决策特点，决定了 ToB 产品不可能像 To C 那样通过大数据、通过用户画像来运营，而只能是通过单点的销售地推来实现用户量和销售额的增长，除非已经过了创始阶段，进入大量中长尾爆发的时代。

因此，云产品销量的第一决定因素是你能否影响到、调动起销售团队（包括BD、客户经理、售前、电销、生态等）的资源，去有目标地达成产品的用户量和销售额。常用的方法大致一样：

（1）做进售前方案里。这个是最基本的，如果你的云产品不在用户的整体解决方案里，那说什么都没用，用户是不会测试更不会采购你的产品的。

（2）针对销售团队的系统性连续性通俗性的产品赋能，因为云产品种类繁多、特性多样，一定要简明扼要地给出产品是什么、能帮用户解决什么、竞争力是什么、怎么卖，其他的信息都不重要。营销套件，如主打PPT、竞争分析，要花多点精力去打磨，不仅是给用户也是给内部团队讲清楚产品的价值。

（3）宣传营销。宣传营销不是针对外部用户的吗？其实，很多时候是营销给内部团队看的，也叫“内部公关”，以让他们知道有这么个东西能帮用户解决某个问题。宣传营销不可能立竿见影，大部分时候也无法量化，但它是须臾不能缺的事情，而且是非常重要的事情，因为只要是公开发表的东西，你就不知道什么时候对什么人产生了什么重大的影响。

（4）渠道管理。云产品大量的销售额会来自各地的“地头蛇”——渠道。

渠道非常重要，为什么？

因为即使一个十几万人的公司，撒到全球甚至撒到全国，那都是微不足道的力量，更何况大部分企业或者企业里部门就百来号人，怎么去撬动尽可能多的市场？非发展渠道莫属。

海量的、扎根在各地各县的渠道商一般都有深厚的本地资源和关系，他们缺的只是产品和研发能力，而跟他们合作，优势互补，才能快速占领市场。但其中也会有困扰的地方，即那么多的云产品，而用户的预算有限，渠道会推荐哪些产品？

这就回到了问题1，根据用户的业务场景，做到方案里。总有的产品是会成交的，有的则不会，这时作为具体产品的产品经理，就要有开阔的胸襟，只要用户需求得到了满足，整体大部门完成了业绩，就不要太计较个人负责的产品是否做到方案里赚到一份销售额的小九九了。

（5）对销售团队要积极支撑。销售团队因为要销售的产品众多，做到对产品熟悉已不可能。因此实际的情况是，销售团队把线索或者项目拿回来，那剩下的答标、交付、客户交流，实际都落到了产品团队身上。

所以产品经理要配备这方面的人力，以免手忙脚乱，整日只是在应付客户零碎的问题，起到了客服的作用，既没有起到产品经理的作用，又影响项目支持。

六、数据：每日的数据看护和每月的数据分析必不可少

我前面说了，ToB产品的运营，不可能像ToC那样靠数据驱动，这里又说要看护数据，这是不是矛盾了呢？

一点也不矛盾。产品运营是产品经理的最重要的日常工作和信息来源，主要目的是通过数据的异常，查找背后单个用户产生这一行为的原因，改进产品，而不是希望通过“用户画像”数据去搞运营活动。

因此，产品经理要每天盯着自己的产品的数据看板，增长了？流失了？为什么？每天都打开运营看板，把任何一个异常点都洞察出来，然后直接跟客户经理、客户本人沟通，找出数据背后的原因。

比如有一段时间，我把云堡垒机的产品规格进行了升级并且提了价，结果发现销售额不减反增加了两倍，而且是在只给销售团队传递的情况下，而没有大量用户面的宣传，为什么呢？原因有三：

1. 最主要的是新用户对新规格的产品的认可，更能满足他们的运维使用场景。
2. 大量的老用户看到我们要逐步把老规格的版本去掉，而老版本确实比较便宜，因此很多续费。
3. 也碰上几个上半年签合同，下半年要落地交付的，但不多。

再比如有段时间客户有一定的流失，我们马上组织了回访，发现主要的原因是：

1. 为了过云上的等级保护临时买几个月。
2. 在云上主机不多，买了堡垒机发现对运维效率的提升不明显。
3. 产品太重，没有专业背景操作起来稍嫌复杂。

围绕着这些数据得出的结论，就可以有目的地调整研发路标，改善产品体验了。

七、抗压：不过分在意一时得失不断调整直到上轨道

一款产品，在未稳定之前，要经过多次调整甚至重生，才能最终成为一款得到用户基本认可、能在市场上站稳脚根的产品。这期间肯定要经历很多阵痛，这都是很正常的事。做产品的过程，就是不断试错、不断解决层出不穷的问题的过程。

比如，刚开始现网问题特别多，一会儿一个用户投诉。这时没有什么好方法，确实是产品的问题，就老老实实把问题补上，用运营方法给用户补偿，降低产品不足带来的影响。

比如，内部的销售团队为了打项目，提了很多新需求、各种内部投诉、上升到大领导层面的争论等等，都会干扰甚至破坏原有的产品规划。如果需求本身确实是之前未挖掘而且高价值的，那皆大欢喜，排到最优先的研发任务里就行。

但大部分情况下，很多没做的需求，都是筛选下来不是当时最佳的解决时机或者优先级不那么高的，这时就要分析项目整体的投入产出，如果确实不做或后做，那也给出替代方案，不至于影响项目的进行。

但总体来说，按原有规划进行研发，是效率最大化的，而各种新需求的插入，大部分只会导致整体研发效率降低。

如何平衡呢？可以分20%左右人力进行应急性的项目特性研发，而80%人力要保持在原规划下稳步前进。

又比如：刚开始运营，总以为产品用户群和销量会按自己设想的走，但实际运营下来，发现经常达不到预期，没有关系，不断调整运营方法和产品体验，只要团队不解散、公司不倒闭，就不断快速尝试，总有一个场景是符合用户需求的，从而带来价值和收入。

再比如，原以为稳定的半年度、年度规划，刚开完会又要变了，临时调整产品路线，各种路标、材料、对外口径调整。

这些都很正常。做产品跟创业没有区别，一次性地把产品做对大受市场欢迎？概率微乎其微，看着再好的产品其实内部肯定也是问题不断，没有哪个产品能舒舒服服就做强做大了。

八、总结：端到端为产品的用户体验和商业成功负责

很多公司和产品经理喜欢谈的什么能力模型，我觉得都是很表面的东西而已，可以参考，但不用花时间去研究。同在一个部门，有的产品经理只会做做售前写写PPT，有的洞察、规划、设计、运营、开发什么都会，你能说他们不懂公司的要求和方法论？

不同的人写同一个题目的文章，风格和水平千差万别，你能说他们不懂题目和字数要求？不同的人在相同的岗位干出的事情的水平可以一个天一个地，这就是主观能动性。

总之，还是上面的老话，产品经理就是一个端到端为产品的用户体验和商业成功负责的人：他要懂产品、懂市场；他要有经营意识，把产品当生意去打理；他要会平衡，知道团队的处境和所能做出的事情的极限；他要有决断，得出的合理判断就执行到底；他又要有一定灰度，不固守某个结论和成规；他只为最终的结果负责，中间用什么方法都可以。

作者： 刘洪善，公众号：小迪文集（ID：i-little-monster）

来源：https://mp.weixin.qq.com/s/Dr4qv_EQ4JKLw1KZy3CmXg

本文由 @刘洪善 授权发布于人人都是产品经理，未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议

作者暂无likerid, 赞赏暂由本网站代持，当作者有likerid后会全部转账给作者（我们会尽力而为）。


Support author:
Author's Filecoin address:
Or you can use Likecoin to support author: