本文来自微信公众号:云算计(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),作者:曹亚孟