硬核分享云产品定义

前段时间，我发表了《云产品向上管理准则》，从公司管理层和产品管理部的角度，对主流云产品进行了分类分析。

我能写此文就是恰好同时设计两类云产品受到触动思考，在文末我也承诺会将这两类产品的设计定义更详细举例，让上一篇产品管理角度的分析文章不太飘不太空。

我在另一篇《识别合格ToB产品经理》明确提到，我支持高层次的产品方法论分享，这是华山论剑一样的“论点共鸣+论据参考”。

醉里挑灯看剑

第三. 主力营收型产品定义

3.0 重温本产品定义

主力营收型产品就一个toB公司的命脉，一个云计算公司要利润、要现金流、要维持资源采购量级、要维持服务支撑体系，只能指望主力营收型产品。

3.1 产品展现形式

主力营收型产品，都是对于客户直接可见可购买的独立产品，而非免费产品或者配合功能模块。

3.1a 计量单位

简单解释：

简单的计量定义是可以抄友商，一句话说出本产品的售卖单位，让销售和客户能比价格做预算。

根因深究：

计量方式是产品定义的第一位最重要的概念。严肃谈计量单位定义，其涉及产品如何组装而成、后端成本和施工、客户可接受的包装方式、明牌对着黑箱承诺等一系列最本质的产品问题。

深究样例：

• 比如“1C1G/8C16G/8C24G/5M以内小带宽”，下列每一行字都能深究出一篇万字长文：我们无法卖0.6个vCPU，但要不要卖6个vCPU/p>

• 1C1G极易被云平台标记为低SLA的特殊用户。

• 8C16G会不会卖完了CPU空闲了内存，而8C24G是否会卖爆了内存。

• 自家是否欢迎小散客户，BGP广播成本、小带宽的超高复用比例、安全需求等等。

3.1b 交付方式

简单解释：

交付方式就是“客户该怎么看到、摸到和使用这个产品”。

实景举例：

• 用户就像买物理机一样使用云主机，只是免拆箱免物流；

• 开通账 以后，用户将域名指向CDN即可完成交付，并建议调用缓存预热接口；

• 这个大数据服务用起来和开源软件完全兼容，并提供了按量付费的API接口；

• 某服务需要预处理A工作3天，实施B工作4天，日常提供5×8技术支持。

根因深究：

交付方式本质上会影响三个产品方面，起手是售前包装，核心在客户感受，收尾在服务保障上。

“免维护or重保障”“标准接口or定制方案”在不同场景各有优势，客户内部不同角色对交付形式的感受也不同，我们要让决策人开心，让执行人放心。

3.1c 计费方式

简单解释：

包括评估用量和单价，预付还是后付，透支额度，阶梯和折扣、销售特殊激励等等。

根因深究：

露在计费介绍页面的几句话只是结果，严谨推导计费方式是实干精算和心理博弈。

产品的成本、价格和利润是相互决定的精算硬功；而产品和销售批折扣、厂商向客户亮底牌，都是不见硝烟的心理战。

我看到大量年营收过亿的云产品，至今算不清楚真实成本，定价靠借鉴友商和简单百分比毛利。

3.2 产品核心竞争力

这一部分就是解释两类问题，为什么要有这款产品，为什么要选你的产品/p>

3.2a 产品对内价值 — 为什么公司需要这款产品。

我不喜欢打工者先聊客户价值，我更习惯先聊清楚该产品线给公司贡献了什么价值。

定义解释：

作为主力营收产品，能给公司带来的只能是“高利润”“大额流水”或者“托起资源水位”。

如果是成熟产品必须加上实现时间和期望数字，这些数字同样也在考核销售体系；如果是探索期产品没有时间和数字，那就考研管理层和产品经理的互信关系了。

虚拟举例 — 真实场景没这么简练：

• 某产品设计毛利润35%，预计今年销售额2个亿，年增长率300%，第三年净利润有望达到15%。

• 某产品月消费额约为5亿，供应商账期4个月，客户账期2个月，迟滞流动资金10亿元。

• 某产品保证我司在某机房带宽采购量保持“最高级折扣”，价格更低、独立上联、可保底突发。

3.2b 用户使用价值 — 为什么客户需要这类产品。

定义解释：

这就是常见的产品价值、用户价值，但toB采购角色多流程复杂，描述用户价值时需要区分角色。

虚拟举例 — 真实场景没这么简练：

• 对于业务决策层，CDN和对象存储的价值是——立刻就能存图、下片儿和开直播。

• 对于采购部门，裸金属是不超卖不掺水不能随意退换的云主机，容器就是按分钟计费的云主机。

• 对于技术决策层，买云端的RDS和大数据这些模板化云主机，就是为了减少本团队责任压力。

• 对于技术执行层，采购容器可以练习K8S，采购高性能云硬盘可以减少IO优化压力。

定义的目的：

用户的使用价值可能很土鳖、没特色、没创新，但只有明确这些价值，才能保证下文核心竞争力的方向不偏颇。

3.2c 关键性能功能 — 客户为何要选你家产品。

定义解释：

主力营收型产品很少是零基础创新者，每个产品或者有友商竞品，或者有类似功能的替代方案，至少我们要按住客户自研自建的心。该产品的某些关键的性能和功能是客户最重要的评价尺度，云厂商就是靠关键的性能功能守住旧客户和开拓新客户。

分类描述：

主力营收型产品的关键性能功能，无外乎四大分类：

• 独有功能或独占资源 — 比如早期直播、某司自研或改良过的大数据软件、某云阿富汗节点。

• 产品性价比 — 某家的云主机性能更好，某家的带宽延迟更低，某家的质量相同而价格更低。

• 产品稳定性 — 大部分稳定性是能力和管理问题，但优化到极限的稳定性是成本问题。

• 资源充裕可交付 — 大客户因业务需求限时快速买大额资源，即需要产品战略肯资源储备上砸钱，也需要对资源的可描述、无缝伸缩、可复用做好规划。

关联性说明：

作为主力营收产品，其产品定义对支撑组件是选型而非实现，实现这些功能性能的主战场在“技术支撑性产品定义”。

比如一个数据库产品经理会关注到“有哪几种性价比的云硬盘”可以支撑数据库，但他们不会关心也无力解决“为什么友商的云硬盘性能比我家快10倍”；类似的独有功能、自愈稳定性、资源清晰描述和无缝伸缩等需求，也都是技术支撑性产品做支撑底座。

3.3 客户和市场分析

产品的设计和实现过程就是追逐和引导目标市场和目标客户的过程。

3.3a 适用场景和客户画像

定义解释：

我们要描述该产品适用于哪类客户，他们有哪些场景和产品需求。

定义举例：

• 透传GPU型云主机，适用于需要独占持久使用GPU资源的客户，客户分布在图形识别、用户行为画像、策略推演等行业场景。

• 云主机竞价实例，适用于有海量分布式离线计算要求且对成本敏感的客户，客户分布在科学计算、批量离线视频处理等行业。

3.3b 已有和潜在友商分析

定义解释：

何为“友商”，他的产品、客户、应用场景和我的产品出现了零和排他冲突。

分析友商就是重温和论证产品价值定义、产品竞争力定义、客户和场景定义的逻辑闭环过程。

定义举例：

• A友商的云主机的性能超过我方产品20%，但是某类客户的实质场景对于性能要求不敏感；我们应该向此类客户的采购表明他们用不了那么高的性能，并得到客户的技术决策人的点头认可。

• B友商的大数据平台拥有我司缺失的XYZ三大功能，我司产品线认可这些功能的必要性。如果我司只做出X功能可以以低价格、代为导入数据、手工维护 表等方式高成本低收益开始产品起步；如果我司做出XY两个功能但仍然缺失Z功能，则需要售前销售同事引导客户Z功能为低频使用功能。

• C友商的某产品经过我方认真评估，产品设计缺乏逻辑，功能严重缺失，资源和稳定性不足；我司不用刻意讨论C厂商的某产品。

• D友商的某产品和我方在日常销售场景下是竞争关系，但在峰值大促场景下是合作关系。我们应该和D友商拉根专线，日常用多云融合、云原生等技术抢他们的生意，但业务高峰和容灾也适度和对方合作。

3.3c 客户选型决策关键点

定义解释：

主力营收型产品的客户选型决策点比较简单，就是“价格”+“功能”+“性能”+“稳定性”。

产品经理需要明确细化这些决策点，给前端体系的承诺越明确，给支撑体系的重压就越合理。

定义举例：

• CDN产品线会每周核实空余资源，对销售的特价审批快速回复，对流失案例每月做复盘和调整。

• 某款云主机要符合安全隔离和审计等功能要求，支持国产操作系统，并且SLA达到99.99%。

• 某款NoSQL需要单库支持两百亿个键值，承诺客户读写QPS大于50万次。

3.4 关键业绩目标

这些关键业绩目标都有些赌性，没有100%靠谱的目标；企业Owner拿到产品经理的目标、证据、推导过程后，必须自己去判断自己去赌，资深产品经理只是在论证自己是个合格的赌局执行者。

3.4a 营收/交付规模

目标举例：

某金融云群集最近三年目标营收是2000万、6000万、1.4亿元。

证据举例：

• 我司走访五大行和几大股份制银行，其每年的IaaS支出为20亿；根据友商的金融云销售情况，其每年销售额约为10亿；根据我司普通云平台的存量客户，有大约1个亿的金融云需求。

3.4b 毛利率/毛利额

目标举例：

我司规划中的边缘云主机套餐，其月成本构成是硬件a元+机柜b元+ 络c元+巡检维护d元，其规划售价是X元，因此可得出的毛利率是Y%。

3.4c 客户粘性/切割难度

描述举例1：

秀场和游戏直播的目标客户群是大型互联 公司，其产品属性就是客户可以并行使用，客户切换难度极低，客户切换动作可以自动完成和人工干预，我司在A省B运营商有优势资源。

描述举例2：

• 智慧城市存储池的目标客户是地方政府，客户需要本地部署和离线维护，其部署速度慢，客户技术实施侧切换难度高，但监控数据无需迁移过期作废，我司独有的快速删除回收和AI预处理技术让客户切离难度较高。

八百里分麾下炙

第五. 对比产品的思考

a. 载誉退役的技术；

b. 火线磨砺的售前；

c. 融会贯通的项目管理；

a. 只有退役技术高手才能主导技术支撑性产品；

b. 售前的客户包装技能既可以力挽狂澜也可以画龙点睛；

c. 项目管理不容易出爆款产品，但对产品防守运营会非常到位。

5.2 考核方法的差异

确实云产品线太长太复杂，管理者们容易将几类产品混淆去谈，你们可以试试按照我写的《云产品向上管理总则》，自己只做判断题和选择题，让产品线仿效我这篇文章自己写清楚问答题的答案。

• 对于主力营收型产品，就多考核营收和利润；

• 对于技术支撑性产品，就多考核你的技术尖刀是否锋利；

• 对于辅助必选性产品，就多考核是否有关键功能缺失；

• 对于操作便利性产品，就多考核客户反馈和实操测试；

• 对于敲门搭讪性产品，就多考核客户覆盖度和销售反馈；

沙场秋点兵

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览92167 人正在系统学习中