TO B的产品经理要有什么思维?
发布网友
发布时间：2022-04-24 13:45
共1个回答
热心网友
时间：2023-10-14 23:43
把认识对象作为系统，从系统和要素、要素和要素、系统和环境的相互联系、相互作用中综合地考察认识对象的一种思维方法。
对TOB来说，客户花钱购买的是一个服务，而无论是产品功能也好，后台系统也好，都只是整个服务中的一个环节。如果将服务理解为一个系统，那么其中每个流程都是其中要素，产品经理需要对服务中各要素及联系有更全面的解析，才能更好地给客户带来价值。
1. 了解服务流程
企业服务顾名思义，先有企业，再有服务。所以这个点的核心在于：去了解企业，了解客户！（心里默念三遍）。
TOC产品经理往往研究的是群体特征，满足一群人的通用需求；TOB产品经理研究的是一个个客户的需求，每个客户需求又往往不同，比如大客户有更多定制化需求，小客户只需要基本需求（俗称大B和小B）。
那么如何确定大客户哪些需求具有可延展性（适用于小客户），小客户需求是否具备通用性，这时候就需要产品经理深入了解实际业务流程，沟通每个需求的问题背景，以解决客户核心问题，带来真正的价值。
B端产品经理做业务调研的方式有很多，比如用户访谈、轮岗实习、调研问卷等，但万变不离其宗，绝不能闭门造车。 注意，任何服务都可以用人工运营的方式实现，之所以要优化，其实就是效率问题。
那么产品经理在调研业务过程，不能只是管中窥豹，而要有更宽的视野，自顶向下去了解全局业务，否则就可能只解决了订票问题，但忽略了改签问题~
2. 定义系统能力
梁宁曾经讲过系统能力的case：一台ATM机。她提到一个简单ATM若要提供完整的系统能力需要七个岗位：战略、运营、现金、密码、硬件、客服、技术。 同样的，当产品经理提供一项系统化服务时，需要定义好各环节的能力，否则整个系统就会乱套。
当然，不同服务所需要的系统能力不尽相同，比如刚才讲到的ATM，需要现金；而如果是电商服务，需要供应链数据。在这个过程中，可以利用结构化思维，根据业务的上下游或者流程步骤，定义整个服务所需要的能力。
当然，战略、运营、技术甚至是客服，都属于B端服务的基本能力。比如客户对后台有疑惑，就需要客服同学去解决；后台系统出现故障，就需要技术同学及时处理以保持稳定；每个功能的价值传递，需要运营同学做数据分析及价值评估。
对此，有些产品同学可能认为这是公司层面的考虑，而我只负责需求产出和功能稳定即可了。对于这种观点，先不说高级产品与初级产品的思考层次。咱作为一个产品经理，最爽的快感是产品解决了客户问题，带去了价值。而客户的视角往往是认可了购买的服务，而不是其中某个功能。
如果产品经理只顾着自己的一亩三分地，不去care其他资源调配，最后服务出问题了，其实….锅还是产品经理的，哈哈哈哈哈哈~
3. 系统能力效率最大化
产品经理利用系统思维定义好服务后，要考虑各系统能力的相互影响，从而协调好资源。就如同系统思维的定义，每个环节的能力都是生生相克的。
如果产品经理定义了一个天马行空的交互，那么客户在使用过程中就会有诸多疑惑，导致使用成本指数上升，也在无形中决定了客服需要花费更多时间去做培训。
如果产品经理定义了一个硬件有问题的ATM，并且也不协调资源解决根因，任其随处爆bug，那么技术人员、客服人员都会陷入解决bug、解释bug的漩涡中无法自拔。
如果产品经理定义了一个杂乱无章的数据统计，当运营需要数据来传递服务价值时，就得花大量时间整理数据，甚至协调资源单独跑数据，一方面延误了价值传递的及时性，客户无法感受服务价值，另一方面也导致运营、技术在各种琐事上折腾，影响工作效率。
可以看到，每个系统能力如果定义有缺漏，整体服务质量会受到蝴蝶效应般地影响，不只是降低了服务提供者的ROI，更甚地是，客户认为没啥卵用。 所以回到前面所说，产品经理提供的服务，绝不仅仅是一个后台、一个工具那么简单，还包括了各环节人力的投入。如何让每个系统能力的效率得到最大化，是利用系统思维解决客户问题关键的一步。
