硬核分享云产品定义
前段时间，我发表了《云产品向上管理准则》，从公司管理层和产品管理部的角度，对主流云产品进行了分类分析。
我能写此文就是恰好同时设计两类云产品受到触动思考，在文末我也承诺会将这两类产品的设计定义更详细举例，让上一篇产品管理角度的分析文章不太飘不太空。
我在另一篇《识别合格ToB产品经理》明确提到，我支持高层次的产品方法论分享，这是华山论剑一样的“论点共鸣+论据参考”。
希望本文能和优秀产品经理得到论据共鸣，希望能给新手产品做负重训练，希望本文能成为淘汰水货坑货产品经理的论据参考。
醉里挑灯看剑
云计算产品经理的核心技能不是画图、哄客户、哄领导、哄研发，更不是见了“高端友商”就磕头和借鉴，云产品经理的核心技能就是“看透需求”和“定义产品”，而且两者要能关联互补和逻辑自洽。
在《云产品向上管理准则》一文中，我将云计算产品分为六大类，其中最重要的是“主力营收型产品”和“技术支撑性产品”。
我将这两类产品定义说明和举例展开描述，建议读者们拿着某个熟悉的云产品，照着下文定义总结自己做个思维训练：
能映射：将实际产品和下文的产品定义逐条映射，就算难想也不要放空，这就是思维负重训练。
能推理：根据明确清晰的产品定义，自己推理出该定义对应的需求是什么。
能归类：横看成岭侧成峰，要认识一堆杂乱的产品，最简单有效的方法是按照某种原则归类。
我要完成一个产品定义设计，都是两周起步数月完工，所以本文略有冗长，这是一个工具文而非议题文。其中主力营收型产品定义最长，对其他产品更有借鉴意义，占了全文50%的篇幅。
梦回吹角连营
3.0 重温本产品定义
主力营收型产品就一个toB公司的命脉，一个云计算公司要利润、要现金流、要维持资源采购量级、要维持服务支撑体系，只能指望主力营收型产品。
3.1 产品展现形式
主力营收型产品，都是对于客户直接可见可购买的独立产品，而非免费产品或者配合功能模块。
3.1a 计量单位
简单解释：
简单的计量定义是可以抄友商，一句话说出本产品的售卖单位，让销售和客户能比价格做预算。
根因深究：
计量方式是产品定义的第一位最重要的概念。严肃谈计量单位定义，其涉及产品如何组装而成、后端成本和施工、客户可接受的包装方式、明牌对着黑箱承诺等一系列最本质的产品问题。
深究样例：
比如“1C1G/8C16G/8C24G/5M以内小带宽”，下列每一行字都能深究出一篇万字长文：我们无法卖0.6个vCPU，但要不要卖6个vCPU？
1C1G极易被云平台标记为低SLA的特殊用户。
8C16G会不会卖完了CPU空闲了内存，而8C24G是否会卖爆了内存。
自家是否欢迎小散客户，BGP广播成本、小带宽的超高复用比例、安全需求等等。
3.1b 交付方式
简单解释：
交付方式就是“客户该怎么看到、摸到和使用这个产品”。
实景举例：
用户就像买物理机一样使用云主机，只是免拆箱免物流；
开通账号以后，用户将域名指向CDN即可完成交付，并建议调用缓存预热接口；
这个大数据服务用起来和开源软件完全兼容，并提供了按量付费的API接口；
某服务需要预处理A工作3天，实施B工作4天，日常提供5x8技术支持。
根因深究：
交付方式本质上会影响三个产品方面，起手是售前包装，核心在客户感受，收尾在服务保障上。
“免维护or重保障”“标准接口or定制方案”在不同场景各有优势，客户内部不同角色对交付形式的感受也不同，我们要让决策人开心，让执行人放心。
3.1c 计费方式
简单解释：
包括评估用量和单价，预付还是后付，透支额度，阶梯和折扣、销售特殊激励等等。
根因深究：
露在计费介绍页面的几句话只是结果，严谨推导计费方式是实干精算和心理博弈。
产品的成本、价格和利润是相互决定的精算硬功；而产品和销售批折扣、厂商向客户亮底牌，都是不见硝烟的心理战。
我看到大量年营收过亿的云产品，至今算不清楚真实成本，定价靠借鉴友商和简单百分比毛利。
3.2 产品核心竞争力
这一部分就是解释两类问题，为什么要有这款产品，为什么要选你的产品？
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预处理技术让客户切离难度较高。
八百里分麾下炙
4.0 重温分类
技术支撑性产品是其他产品有竞争力的技术基础，其极少产生功能性营收所以比较晦涩，也很难找到合格的产品经理，但其在“突破性功能”“架构”“性能”“稳定性”和“复用比”等技术选型和执行领域起了决定性作用。
如果在战场上，技术支撑性产品就是雷达、核爆、高强度材料等等爆炸性科技突破。
我这一段会很难做共性举例了，而且大部分读者（包括非某细分领域的研发）也看不太懂。
4.1 核心价值
我们先要明确这个核心支撑性产品，到底带来了哪些“突破性功能”“性能”“稳定性”“架构”和“复用比”的能力提升？产品经理和主程序员要自圆其说、自证可行、通得过技术评审，保证符合IT技术常识。
编两个例子：
我要发明一个让叠瓦式硬盘也能快速写入数据的磁道编码方法。
我的编码引擎的ABCDE性能比友商好12345，用跑分证明友商的主程该转岗了。
4.2 产品展现形式
该产品的本体和核心组件部分是如何构成的，需要产品经理把产品到底长什么样介绍给公司决策层。
举例：
这是一组应用、一个盒子还是一个芯片，或者是64个软著+256个专利？
4.3 工作形式和服务边界
产品的工作形式——给客户技术、产品经理、售前、运维、实施、测试、友邻对接研发看清楚，本产品长什么样子。他们要根据工作形式确认对接方法和验收标准，并套用售前包装和维护方法论。
产品的服务边界——给客户技术、产品经理、售前、售后以及本产品程序员看清楚，本产品的服务边界承诺到哪一步了。
工作形式举例：
某智能芯片插入服务器主板以后，主板加电即可启动，SOC内置操作系统是个定制版Linux，上有我方自研应用ABCDE；其中A应用强依赖远端Server下发指令、B应用是本地优先的状态数据库……
服务边界举例：
某数据缓存支持XXX性能的并行读取和XX性能的写入，仅承诺在单节点内实现写入锁定，多节点写入的数据以最后提交者覆盖为准，全局同步在N秒内完成。
4.4 技术关键点承诺
技术支撑性产品的核心工作就是要攻坚解决某些技术关键难点。
产品经理要证明这确实是实现核心价值的技术关键点，而且要尽可能精确的承诺要攻克到什么程度。
连举带编三个例子
举例1：云游戏引擎务必保证抓屏延迟在20ms以内，才能保证玩家正常体验；如果抓屏延迟能控制到10ms以内，能极大的降低机柜和带宽成本；如果不依赖驱动支持可降低对显卡厂商的依赖。
现编2：为避免集中控制端成为误操作源点和依赖单点，也为了避免客户端不受控制，我们做了ABCDEFG多层保障设计。
现编3：我们会在云主机使用的ext4和xfs文件系统里加入一个补丁，让客户侧文件删除和云硬盘空间回收联动起来。
4.5 外延价值实现
技术支撑性产品的外延价值实现，就是本产品经理向其他的产品线推销自己的产品，向公司管理层承诺其他产品线肯定会用到自己的功能性能。
技术支撑性产品必须和公司的战略方向能捆在一起，能推销到有价值的舞台上。和公司发展方向毫无关联的技术支撑性产品，有天才程序员就带着代码跳槽创业，没天才程序员就谢谢公司养猪的福利。
我编了两个例子：
应用网卡卸载技术以后，我司能在XX成本范围内，实现宿主机网卡PPS超过XX万；预估到了M月，私有云主机即可用此性能参数打单；预估到了N月，公有云主机可在不涨价前提下承诺单机PPS为XX万。
在完成XXX算法攻坚以后，我司的视频编码速度比友商快30%，带宽占用低50%，CDN产品部会制作一个窄带高清高价直播产品。
五十弦翻塞外声
本文终于要结束了，对比本文中两大类产品，我们可以看到产品经理这些自然人的差异，以及产品线考核管理方法的差异，产品线价值变现的差异。
5.1 产品经理的来源差异
我在《识别合格产品经理》一文中明确指出，高阶产品经理都来自于转岗，转岗来源就是三大类：
读完本文的定义以及例子，我们会发现：
a. 只有退役技术高手才能主导技术支撑性产品；
b. 售前的客户包装技能既可以力挽狂澜也可以画龙点睛；
c. 项目管理不容易出爆款产品，但对产品防守运营会非常到位。
不同背景的产品经理，希望本文能让你们扬长避短，最好（但可能性不大）能补齐短板。
5.2 考核方法的差异
确实云产品线太长太复杂，管理者们容易将几类产品混淆去谈，你们可以试试按照我写的《云产品向上管理总则》，自己只做判断题和选择题，让产品线仿效我这篇文章自己写清楚问答题的答案。
对于主力营收型产品，就多考核营收和利润；
对于技术支撑性产品，就多考核你的技术尖刀是否锋利；
对于辅助必选性产品，就多考核是否有关键功能缺失；
对于操作便利性产品，就多考核客户反馈和实操测试；
对于敲门搭讪性产品，就多考核客户覆盖度和销售反馈；
沙场秋点兵
我们很少见到toB产品经理方法论，每次云产品经理分享不是吹资源就是吹项目，再要不然就是吹程序员。
迷迷糊糊这么多年，我们都能活的这么顺，做云计算真的不难。
只要大家努力做好产品经理，努力管好产品经理，云计算大行业机会仍然很多。