本文来自微信公众号：云算计（ID：gh_0068c4e23a81），作者：曹亚孟，原文标题：《云产品向上管理总则》，题图来自视觉中国
引言
温故而知新，古人不欺我
几年前的夏末，南方某toB公司找我做过一次有意思的咨询。
他（她）们并不是产研专业而是几名产品管理人员。
他们不习惯也没必要从专业性的角度区分诸如“IaaS、PaaS、功能、性能、创新、集成”等等概念。
我当时整理了一堆资料，但越整理越觉得这不是外行指挥内行，这正好是从高层看toB产品如何评估。
今年我恰好同时做了两类云计算产品定义，在频繁交叉对比中让我想起了那次咨询。时隔几年又有新的成长感触，所以我做了这个总结。
该总结既是一个产品经理主动向上管理汇报的思路指南，也是其他部门管理评估产品线的操作指南。
1. 被管的觉悟
作茧自缚也是作茧自护，主动求管好过随机被拎
我们天天说对客户友好，把研发和销售当内部客户，那些承担评估责任的老板、战略规划部、产品管理部、各种评控委员会，这些人也同样是内部客户。
高级产品经理应该关注和把控，公司决策层如何评估和管理toB产品，然后理直气壮的要目标、要资源、要报酬。
这些内部客户不是专业产研人员，没必要比你还精通toB产品技术。为了避免客户乱动乱管，最简单的方法就是引导这些内部客户，主动替他们找管理我们的方法。
这道难关能把我们和水货傻大胆们区分开 —— 我们周围都不缺用公司的筹码给自己赌博的职场投机分子，这些傻大胆比我们敢承诺比我们嗓门大，但他们没有按照本文分析填充工作目标的智商。
2. 产品价值分析
你是谁 你从哪里来 要往哪里去
产品分析的核心工作永远是分析用户价值，我分析了十几款最主流最核心的云产品，梳理出五个价值预期方向。
2.1 用户所需功能和性能
最终用户客户为什么要选用整个产品？
此时常见的雷点在于“描述谁是用户时丢失主语”，还有“说不清功能性能指标”。
冷冰冰的考验和斩钉截铁的回答，就是在强制帮产研人员收拢思路。
2.2 产生了毛利润
一个云产品能带来足额利润，这就是商业上的成功。
用公司的筹码给自己赌博的职场投机分子，很乐意用空口承诺换个产品总监的美差；而高手产品经理绝对不会闭眼承诺，他们很怕弄脏自己的羽毛。
产品经理需要描述利润的规模、利润的来源、利润扩大的预期和缩小的风险，描述的越详细，听众们对你的智商和专业度就越有信心。
2.3 产生营收和流水
云产品实操层面要靠卖资源来承载营收，所以产品介绍务必说清楚产品营收能力和流水类型。
云厂商对客户提供弹性资源，但自己买的是相对固定资源。巨大的营收规模能获得较高的资源折扣台阶、更大的资源复用比和足够的客户承载能力，我们也要承担巨大的资源空置风险。
国外巨头云都是预收客户款项加拖延供应商账期，因此产生巨大的资金流水收益；但国内的云产品设计都被友商拖累，变成了供应商预付费而客户晚结账。这是采购不专业，销售太软弱，还是成本核算失职了？我觉得主要还是产品经理没有清晰规定和坚持原则。
2.4 用户友好便利性
企业客户内部有不同的角色，他们对产品友好便利性的需求完全不同。
业务决策人需要产品说明有什么业务价值，比如“采购了对象存储就不用自建存储池，能快速上线”。
采购决策人需要和竞品对比产品付费方式，或者特别方便比单价，或者只能比总包价。
技术执行层要的友好便利性是，权限系统、访问日志和API接口，还要控制台做好防止误操作。
用户财务对账失败就要拖延付费，而计费产品部也总是抱怨计量信息和折扣规则就没个准话。
用户其他部门可能也有友好便利性需求，比如各种等保合规、数据销毁等等问题。
对用户不友好不便利的产品当然也能卖出去，企业用户的愤怒是可以用性价比抹平的，那就少挣点呗……
2.5 跨产品线闭环
用户很多时候会同时用多款云产品，这里可以分为必备产品、搭售产品和多云互切产品。
当A产品售出则B产品才能工作时，A产品就是闭环必备产品，比如“带宽”和“硬盘”。
当A产品售出则B产品更容易售出时，A产品就是搭售型产品，比如“对象存储”和某些稀缺资源。
多云互联和云原生都是双刃剑，各家友商相互切量的越容易，资源空置和价格战就越惨烈。
2.6 诱饵获客和搭讪工具
正规大企业采购体系根本不会主动咬钩，所以我不看好诱饵性获客产品。但有些产品是个很好的破局搭讪工具，主要特点就是用法通用、客户普遍大量需求、可以多供应商并存。
比如客户不会天天有新项目，但销售要每周都去拜访客户。如果切下来大客户千分之一的CDN流量，销售到客户现场，开场白可以是“我来问问服务反馈”。
3. 产品价值是否量化
对于绝大部分产品，产品经理在职三个月摸清现状以后，请自信的、清晰的、明确数字的、明确时间线的说出来你的产品价值。
公司不怕你描述的产品价值特别大，你敢吹老板就敢戳，戳不破你的闭环逻辑，公司就会赌这个产品。
公司也不怕产品创造的价值小，价值小资源少但期望值也就低了，哪怕公司不同意也可以继续改。
公司最怕产品经理扭扭捏捏说一堆技术名词，或者满屏幕都是“高大上”“上百亿”“全球领先”……。
如果是创新性尝试性产品，上述价值可以只有方向和单位，但没有具体的数值和时间线。
公司当然需要创新型产品，但创新型产品经理不应该是傻大胆赌徒，而是老板的铁杆嫡系，公司相信他们是真的创新而非混底薪。
4. 产品分类分析
横看成岭侧成峰
远近高低各不同
要看产品真面目
分类抽象才能行
在琢磨产品本质时，我特别喜欢做分类来抽取共性和对比个性，写本文也是 我在做“两个且两类”产品设计时所有触动。
我将产品从实到虚做了6个分类，正好和前文的产品价值逻辑对应。
4.1 主力营收型产品
主力营收型产品承担着一个toB公司的命脉，创造着营收和利润，也携裹着巨大的风险。
现在主力营收型产品技术相对停滞，大家的核心注意力在稳定性，将来在精细化运营。
如果在战场上，主力营收产品就是坦克钢铁洪流、航母大驱编队、不列颠空战和李梅火攻。
4.2 技术支撑性产品
技术支撑性产品比较晦涩，他们的价值体现在“架构”“性能”“稳定性”和“复用比”等技术执行领域。
这些支撑性技术需要有目的有意义的主动变化，并主动邀请其他产品使用自身的新特性，它们是其他产品有竞争力的技术基础。
如果在战场上，技术支撑性产品就是雷达、核爆、高强度材料等等。
云计算最常见的技术支撑性产品就是SDN性能网络和K8S。而K8S是个反面典型，其自身缺乏变现能力，和其他产品的衔接也出了大问题。
4.3 辅助必选型产品
辅助必选型产品的核心价值是“跨产品闭环”，这种产品或者是保单必用，或者是切单必选。
如果在战场上，辅助必选型产品就是后勤保障和侦查系统，只用它们不会赢，但没有它们肯定会输。
保单必用的辅助性产品，最常见的就是BGP带宽和SDN功能网络。而对象存储是切单必选的辅助性产品，客户默认有数据存多份的需求，当有了数据极易引出算力和网络需求。
4.4 使用支持性产品
照着“用户友好便利性”的需求，去掉辅助必选型产品，这就是使用支持性产品。
如果在战场上，使用支持性产品就是军报、军旗、军号和军服。
从控制台到账单系统、从vRouter手写路由表到自定义DHCP，这些都是使用支持性产品。
我写的“xx型”都是产生营收的产品，而“xx性”都是不产生直接营收的产品。
4.5 防御补全型产品
防御补全型产品防御补全不是客户需求的必选，而是我方对友商的防御，包括保持客户信心和战略牵制友商。
如果在战场上，最像防御补全型产品的是地雷、水雷和牵制性部队。
一些云厂商搞人工智能、出海、大数据、边缘计算、云游戏，就是为了保住自家的体面和客户的信心。反正花不了几个研发人月，发几篇PR稿件、上线一个永远内测的官网并不难。
大客户经常放几个小供应商进来搅局，吓得大云厂商始终硬不起来；希望将来云计算行业竞争更激烈也更理性，云厂商能从更高的维度自己做局去牵制友商。
4.6 外包加盟型产品
外包加盟型产品是别人家的软件在你的平台上卖，或者你拿下订单转包给第三方，这是真解决方案部的最爱产品。这类产品的优点是产研成本极低，但缺点是品牌消耗待定、售后维护待定。
本来软件供应商和第三方集成商都很怂很乖很呆萌的，云厂商的logo和客户池是他们梦寐难求的。但是架不住云厂商相互拆台，把他们哄的……
5. 产品的成本管理
产品经理要理直气壮的要目标、要资源、要报酬，前文主要谈产品目标，职场报酬要日后再说，现在聊产品成本管理。
我只能泛谈一下产品管理角度的成本管理，这是产品高手的核心竞争力，而且每个特性化微操都涉密，所以我无法展开细聊。
5.1 资源成本
资源成本可以单独和分期购买、搭便车蹭用、冒险抠门运营。
5.2 研发成本
研发成本的高低在于研发团队的实力和研发团队的用法。
有时做核心云服务，可能几个高手比上百个饭桶的成本更低速度更快，但你要能找的到研发高手才行。
我写的产品设计文档有大量的“此功能可障眼法糊弄”“此功能明年再做”来降低研发成本。
5.3 管理成本
评估产品是否立项、为产品圈地仲裁、为用户行为特批、为产品线协调资源，这些都需要高管和内控部门分出时间来处理。
我见过一些悲哀的人，他们为“茴”字的写法挣个三天三夜，自己浪费生命还要拖一个公司的人下水。
我也遇到过因为嚷的嗓门不够大，导致好产品好团队就是没时间向老板的汇报情况。
5.4 配合成本
其他部门对产品线的配合成本有对接计费、权限、VPC、云硬盘这类常见公共配合，也有定制资源池、保证接口不变这类定制配合。
5.5 行销成本
企业品牌形象、销售的信心、销售的精力体力、客户的耐药性、售后的擦屁股压力，这都是成本。
上文所说的成本部分，资源和研发成本相对容易量化成数字，而另一半要老板们、战规品管、内控评估、支撑配合部门来自行评估。总之产品高手需要的资源更少产出更多，其成本构成也更有逻辑性。
6. 后记
整篇文章是谈产品管理的思想，略微有点空。
我会做一些详细到干货的具体产品分析说明，用样例说明来反哺丰富产品管理的思想。
但全文已经太长了，所以这几个产品的详细说明，我会回头写成单独的文章。
敬请期待《主力营收型云产品的核心设计样例》和《技术支撑性云产品的核心设计样例》，其他产品是否有样例，我还得考虑一下。
本文来自微信公众号：云算计（ID：gh_0068c4e23a81），作者：曹亚孟
发表评论 取消回复