（1）基本业务知识

我一直强烈推荐to B产品总监去上一个正规的MBA，对商业的基本认知有个体系性标准性的认知。很多to B产品卖不好，核心就是这些产品本身就不符合商业基本认知，也不符合商业标准。比如人家美国采购经理都去考采购经理证书，而咱们中国搞to B 采购管理的产品经理，对采购连基本章法都不了解。这种情况，在人力、供应链、生产制造、营销、销售、服务等等各条产品线，都存在产品经理对业务专业不胜任的情况。

（2）价值认知

在上述前提之上，咱们再谈价值认知。

一个业务的流程工序、Operation方法往往非常复杂。但真正有价值的点却不多。很多工序动作是过程必备动作，需要做，但价值又不高。

所以我们非常有必要识别有价值的点。有的点能撬动地球，这就是点在的位置决定的。

什么是有价值的点呢？我先讲两个小故事然后再说。

在十多年前，我创立移动创新研发中心时我对员工说：你们不要把ERP大象塞在智能手机里。如果你们设计的功能不能利用上智能手机的硬件特性，那么就不要做在智能手机上。

在四年前，我跟云服务研发BG同事说：你们不要把ERP大象放在云上。如果你们设计的功能不能利用上互联网的连接、交易特性，那么就不要做在云服务里。

所以，对于产品总监的规划，我一般看有没有以下的价值要点：

1、高刚海需求：是不是高频、海量、刚需的特性

2、交易卡位：是不是处于交易卡位的关键位置：如电子合同、电子发票、企业支付、银行连接、税务局连接

3、产业链级：是不是网络效应：人-人连接、人-物连接、物-物连接、互联网电子商务连接、政府连接...

4、社会级：是不是社会化资源/信息数据的整合、卷入、调度

5、国家级：是不是受国家强监管

6、数智化技术：是不是IoT软硬一体化、是不是高算法门槛

我有时候想：我特别想要求每个产品经理都开一个天猫商铺，让他们做做生意去，让他们实际历练历练对于商业的感知。

（3）商业模式

价值功能倒是设计出来了，但怎么收钱也很重要。很多产品总监啊，抱着金饭碗要饭：

交易服务：比如交易订单怎么收费模式？

交易服务：比如电子合同、电子发票这类服务怎么收费模式？

交易服务：比如支付通道服务怎么收费模式？

交易服务：比如产业资源智能调度服务怎么收费模式？

网络连接服务：比如银企联云、税企联云怎么收费模式？

网络连接服务：比如企业的消费者也上这个平台，怎么收费模式？比如企业的供应商和配套厂商也上这个平台，怎么收费模式？

数智化服务：比如产业主数据服务怎么收费模式？比如产业横向测评服务怎么收费模式？比如一个模板怎么收费模式？

数智化服务：比如AI服务怎么收费模式？

数智化服务：比如带了AI特性的IoT智能硬件，怎么收费模式？

IT平台服务：比如通讯平台怎么收费模式？

IT平台服务：比如工作流引擎怎么收费模式？比如低代码开发工具怎么收费模式？

我昨天在朋友圈发了一段文字：什么是云时代的三大傻，那就是：

第一傻：产品：拿项目做产品

第二傻：销售：私有本地部署，还搞订阅模式

第三傻：交付：做POC

现在是云时代啊，怎么就不好好利用一下这个特性呢？

我有时候想：我特别想要求每个产品经理都去打《王者荣耀》和《征途》，去感受感受游戏里层出不穷用户诱导激励模式和商业模式。

（3）用户体验

现在to B产品也都特别讲究用户体验了。

在微软80年代就有一句很知名的话，叫：吃自己的狗食。自己写的Windows、Office、开发工具，自己先拿来用。

但是对于中国to B行业呢，往往有个臭毛病：自己内部不用自己的东西。我过去说过京东和四通一达的案例。京东物流主要是自己用，所以如果不提高效率，成本全是自己的。所以京东物流拼命做无人仓、无人机、无人车。而四通一达主要是给别人搬箱子，搬一次就收一次的钱。所以四通一达没有优化效率的动力，因为机制原因，自己越优化，自己越不容易赚钱。这就是机制问题，怎么优化也是杯水车薪。如果做软件是自己自用而不是卖给别人，那自己自用当然是越简单越好，否则就是给自己自找麻烦。如果是卖给别人，那就越复杂越好，这样就能在竞标时说：我们为啥比竞争对手卖的贵、我们为啥比竞争对手好，就是因为，我们有1500个功能点，竞争对手才1000个功能点。

所以我老推荐：要业务+IT一体化。

因为只有业务+IT一体化，才能从机制的根上解决用户体验的问题。

因为只有业务+IT一体化，在中国，只会卖IT实施IT，而不会业务咨询IT咨询、开发增值服务、数据分析服务的这些分销商们，在SaaS年度订阅模式下，才能有其他的钱可赚。否则，中国的IT分销网络在SaaS时代是会崩溃的。

我有时候想：业务+IT，对于中国大多数SaaS厂商是难以做到的商业模式。那如何改进用户体验？那就只能用KPI来硬压了。先自动化统计和测试一遍，设立一个数据基线，然后KPI要求，每年，应用的点击数量和输入栏位数量要减少10%。人为造成的复杂性，是to B软件最大的用户体验敌人。

现在，搞用户体验度量的工具太多了：

比如跟踪用户使用行为的工具：用户行为跟踪、流量分析，给产品经理、客户运营人员使用

比如提高系统稳定性的工具：服务跟踪链，给应用架构师使用

比如提高系统高性能的工具：APM，给技术架构师、技术部署专家使用

比如提高系统高可用的工具：日志，给运维工程师、技术部署专家使用

比如提高系统安全性的工具：安全监控预警，给安全专家使用

大家要知道，to B用户体验，既包含功能方面的用户体验，也是包含非功能性方面（如高稳定、高性能、高可用、高安全）的用户体验的啊。

（4）分工协同

当然，这么多的要求也不能压在产品经理一个人的身上啊。打板子也不能全打到产品经理的屁股上啊。那就得分工。

非功能性需求，上述已经提到了：

高稳定：应用架构师、技术架构师负责

高性能：技术架构师、技术部署专家负责

高可用：运维专家、技术部署专家负责

高安全：安全专家负责

对于模块-模块之间、系统-系统之间的集成性，由应用架构师负责。他会和上游的产品经理、下游的技术架构师一起对接协同落地这个职责的。

对于功能性需求，人机交互体验设计改进，可以交给：UI、UE设计人员。他们专门研究人机交互怎么更加舒服自然的。

对于数据分析型功能，可以交给：数据服务专家，他们会识别主数据、制定数据标准规范、建立数据洞察应用模型的。

对于产品的收费模式、定价，可以由产品营销经理和产品经理一起磨合制定。大家可能对啥叫产品营销经理不太熟悉。但实际上，产品经理最初最初的来源就是产品营销岗。1927年，宝洁首创了世界上第一个产品经理岗位，这个岗位就是捕捉客户需求、市场热点、竞争对手差异点，然后定义产品特性规格，然后上市去推广产品，让更多的分销商和客户接受产品，从而达成公司营收业绩。而微软把宝洁这套玩法用到了软件产品行业。微软有四驾马车：产品经理、程序经理、架构师、测试经理。而微软说的产品经理就和宝洁说的产品经理是一回事，都属于产品营销部门。而微软说的程序经理其实就是产品研发部门的产品经理。产品经理和产品营销经理也往往会互相之间流动。

对于产品日常细节改进，因为有用户行为跟踪工具，所以，产品经理和客户运营人员会一起天天观察、分析这些数据，来持续改进产品细节。

（5）考核

咱们经常会说一句话：你考核什么，你就会得到什么。

如果你让一个三岁孩子去找一碗水，那么他很可能只能去马桶里给你舀一碗水。

对于非功能性要求（高稳定、高性能、高可用、高安全），该考核谁，该怎么考核？

对于功能型需求用户体验方面，该考核谁，该怎么考核？难道不是考核减少了多少人工点击多少人工输入么？

对于交易类功能特性产品，该考核谁，该怎么考核？难道不是考核交易的精准性、交易GMV么？

对于网络连接类特性产品，该考核谁，该怎么考核？难道不是考核连接了多少应用么？每天API调用次数是多少么？

对于数据分析类特性产品，该考核谁，该怎么考核？难道不是考核模型数量么？

对于数据服务类产品，该考核谁，该怎么考核？难道不是考核数量量、数据维度、数据精准性标准性、数据标签数据关系图谱加工么？

对于AI服务类产品，该考核谁，该怎么考核？难道不是考核API调用次数么？

对于低代码开发类产品，该考核谁，该怎么考核？难道不是考核产生了多少云原生应用，这些云原生应用被客户下载或购买了多少套么？