如何判定 to B 产品经理的工作成败

B端产品经理以业务为基研，产品思维都是从业务开始展开。大部分的B端产品以提升工作效率为目标，因此， B端需求都是以业务问题为导向的。

 

作为B端产品经理一定要理解业务，根据业务的实际发展，用产品思维去梳理逻辑，设计产品工具来解决问题。

 

有些业务同学会说，我希望要一个反馈功能，其实可能隐藏了一个工单系统需求。

 

如：一个管理软件中，编辑人员希望能够在完成销售商品录入任务后给运营一个反馈。在了解业务后发现编辑人员都是通过线下邮件形式接受商品录入任务。

 

 

设计思路如下:

在进行产品设计时，我们面向编辑人员和运营人员两个角色，在产品中要设计两个角色的沟通通道，并把这个沟通通道建立在已有的商品录入平台。

 

系统流程逻辑可设计如下：

运营发起任务，编辑人员认领任务或上级分发任务，

编辑人员处理任务（任务正常处理和任务非正常处理），处理过程运营可监控

处理结束后，运营可投诉

投诉后的任务可再次被分发处理（任务流转节点设计）

 

 

关注B端用户

 

 

在案例中不难发现，B端产品依旧要考虑使用者。因此在进行B端业务时，要花一定的精力关注系统的使用者。

 

例如编辑工作台设计中，编辑人员的任务认领操作可能是频率极高的，而产品设计时如果每次认领任务都要点击进入产品进行查看，甚至于点入后发现无可认领的任务，对于使用者来说是会有挫败感的。

 

增加待认领任务，并明确标记待认领任务数据，就是当实解决了编辑人员的个人需求痛点；

 

 

 

to B 产品经理应该关注哪些指标

 

 

SaaS 产品早期，客户的留存率（retention）、客户的生命周期价值（LTV）甚至公司月度性重复收入（MRR）都并没有被格外关注，因为这些数据前期无法准确计算。

 

早期产品中，我们往往更关注的是：

 

产品的使用率   

 

产品的使用率包含以下几个方面：

 

第一、客户使用产品的频率，是否持续每天使用。例如：一款CRM 产品，客户一旦停止录入客户联系资料，就意味着我们的产品失去了价值和生命力。

 

其二、客户使用的产品功能。产品负责人每天要梳理哪些客户在使用哪些具体功能：

 

如果一款自动化CRM+销售监测产品，大多数的客户只使用了自动化功能，而忽略了 CRM 。说明我们的 CRM 上手可能是困难的或者这个功能对客户价值不大。

 

第三、特定功能的接受度。无论我们推出多少功能，客户大部分都只使用其中的20%，

 

如果有的客户只使用自动化却不用客户分层、商机看板，有的只用朋友圈、群发却不用自动化，这时我们就会发现用户需求出现了分化，从而功能使用时，出现了断层。

 

 

如何判定 to B 产品经理的工作成败

 

 

评判 to B 产品经理工作成败的关键标准也是B端产品的关注指标。

 

• 使用户品频率

• 使用产品功能

• 特定功能关注度

 

这几个标准同时也要求 PM 必须充分的了解客户的需求和产品使用情况，因此B端产品经理要保持与客户的持续沟通。