6

产品经理怎么告诉老板你做了什么?

 2 years ago
source link: https://www.huxiu.com/article/462510.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

产品经理怎么告诉老板你做了什么?

本文来自微信公众号:云算计(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. 产品分类分析

横看成岭侧成峰

远近高低各不同

要看产品真面目

分类抽象才能行

85

在琢磨产品本质时,我特别喜欢做分类来抽取共性和对比个性,写本文也是 我在做“两个且两类”产品设计时所有触动。

我将产品从实到虚做了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 行销成本

企业品牌形象、销售的信心、销售的精力体力、客户的耐药性、售后的擦屁股压力,这都是成本。

上文所说的成本部分,资源和研发成本相对容易量化成数字,而另一半要老板们、战规品管、内控评估、支撑配合部门来自行评估。总之产品高手需要的资源更少产出更多,其成本构成也更有逻辑性。

整篇文章是谈产品管理的思想,略微有点空。

我会做一些详细到干货的具体产品分析说明,用样例说明来反哺丰富产品管理的思想。

但全文已经太长了,所以这几个产品的详细说明,我会回头写成单独的文章。

敬请期待《主力营收型云产品的核心设计样例》和《技术支撑性云产品的核心设计样例》,其他产品是否有样例,我还得考虑一下。

本文来自微信公众号:云算计(ID:gh_0068c4e23a81),作者:曹亚孟


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK