TO B 产品经理的系统思维,这3个要点要注意

2 评论 8625 浏览 33 收藏 11 分钟

系统思维是TO B 产品经理必备的思维之一,利用好系统思维为客户提供有价值的服务,需要注意流程、系统和效率三个要点。

刘润老师的一念之间

前阵子刘润老师写了一篇文章,吐槽改签火车票流程太麻(sha)烦(bi),主题表达的是我们都活在产品经理的一念之间。其实我理解刘润老师讲述的“一念之间”是指产品经理在深思熟虑后那一刻做的决定影响面大。但其实言者无心,听者有意,大部分的第一反应一定是:对!产品经理啥都不会,只会拍脑袋想需求,做出来的产品都很欠(打)思考。

首先,我要解释一下,刘润老师不是那个意思。当然,就算是拍脑袋,你们打我啊~

其次,刘润老师讲述的是一个面向铁路乘客的改签流程待优化问题,而这种流程化其实就是用户服务过程,如果流程没有在产品中设计好,一方面苦的是用户,要折腾来折腾去,还浪费了时间耽误了行程;另一方面苦的也是车站窗口的小姐姐们(车站大哥表示不服):本来是想让乘客在APP上做操作,减少窗口服务压力,结果:又来了老弟儿~。也就是说,互联网带给订票服务的提效,还不到位呢。

产品经理需要系统思维

好了,终于要强行引出题目中的关键词:系统思维。私以为,铁路乘客的改签流程恰恰是没有系统化思考产品的结果。

先来讲讲什么是系统思维,定义如下: 把认识对象作为系统,从系统和要素、要素和要素、系统和环境的相互联系、相互作用中综合地考察认识对象的一种思维方法。

对TOB来说,客户花钱购买的是一个服务,而无论是产品功能也好,后台系统也好,都只是整个服务中的一个环节。如果将服务理解为一个系统,那么其中每个流程都是其中要素,产品经理需要对服务中各要素及联系有更全面的解析,才能更好地给客户带来价值。

我讲个之前工作中的小故事:

很久很久以前啊,我们做的B端产品还在从0到1阶段,大家的精力都花费在功能迭代。 有一天,老板下了个order:“把后台的交互改一改,让整体交互更清晰点”。

我当时第一反应是:what your problem?公司现在是需要赶紧让客户满意我们的功能,从而扩大客户规模。况且B端产品也不需要太注重交互吧?这有点本末倒置了! 所以,我态度坚定,毅然决然地跟老板说:“好的,么问题,这个意见很棒呢!”

后来我深入业务,发现由于后台交互不清晰,运营同学经常要跟客户做解释。一方面导致运营工作效率低下,长期陷入培训的琐事中;另一方面也极大降低了客户体验,甚至因为不会用就不用了。 而站在老板层面上,运营成本花在这些ROI很低的事情上面,明显是亏本生意。所以我突然就明白老板的意图了,一句话:钱得花在刀刃上!

当我们提供一个服务时,如果交互不清晰(不用好看),客户在使用上需要投入更多时间,必然会影响其满意度;若乙方通过人力协助,则提升了自己的运营成本。这个就是整个系统化服务中每个环节的相互影响结果。 (P.S.后续我们通过改善交互、增加帮助说明、操作指引等方式,让客户愉快地享受我们的服务~)

TOB产品经理用好系统思维

那么,TOB产品经理该如何利用系统思维为客户提供有价值的服务呢?七爷认为有三个重要的点,且听我娓娓道来~

1. 了解服务流程

企业服务顾名思义,先有企业,再有服务。所以这个点的核心在于:去了解企业,了解客户!(心里默念三遍)。

TOC产品经理往往研究的是群体特征,满足一群人的通用需求;TOB产品经理研究的是一个个客户的需求,每个客户需求又往往不同,比如大客户有更多定制化需求,小客户只需要基本需求(俗称大B和小B)。

那么如何确定大客户哪些需求具有可延展性(适用于小客户),小客户需求是否具备通用性,这时候就需要产品经理深入了解实际业务流程,沟通每个需求的问题背景,以解决客户核心问题,带来真正的价值。

B端产品经理做业务调研的方式有很多,比如用户访谈、轮岗实习、调研问卷等,但万变不离其宗,绝不能闭门造车。 注意,任何服务都可以用人工运营的方式实现,之所以要优化,其实就是效率问题。

那么产品经理在调研业务过程,不能只是管中窥豹,而要有更宽的视野,自顶向下去了解全局业务,否则就可能只解决了订票问题,但忽略了改签问题~

2. 定义系统能力

梁宁曾经讲过系统能力的case:一台ATM机。她提到一个简单ATM若要提供完整的系统能力需要七个岗位:战略、运营、现金、密码、硬件、客服、技术。 同样的,当产品经理提供一项系统化服务时,需要定义好各环节的能力,否则整个系统就会乱套。

当然,不同服务所需要的系统能力不尽相同,比如刚才讲到的ATM,需要现金;而如果是电商服务,需要供应链数据。在这个过程中,可以利用结构化思维,根据业务的上下游或者流程步骤,定义整个服务所需要的能力。

当然,战略、运营、技术甚至是客服,都属于B端服务的基本能力。比如客户对后台有疑惑,就需要客服同学去解决;后台系统出现故障,就需要技术同学及时处理以保持稳定;每个功能的价值传递,需要运营同学做数据分析及价值评估。

对此,有些产品同学可能认为这是公司层面的考虑,而我只负责需求产出和功能稳定即可了。对于这种观点,先不说高级产品与初级产品的思考层次。咱作为一个产品经理,最爽的快感是产品解决了客户问题,带去了价值。而客户的视角往往是认可了购买的服务,而不是其中某个功能。

如果产品经理只顾着自己的一亩三分地,不去care其他资源调配,最后服务出问题了,其实….锅还是产品经理的,哈哈哈哈哈哈~

3. 系统能力效率最大化

产品经理利用系统思维定义好服务后,要考虑各系统能力的相互影响,从而协调好资源。就如同系统思维的定义,每个环节的能力都是生生相克的。

如果产品经理定义了一个天马行空的交互,那么客户在使用过程中就会有诸多疑惑,导致使用成本指数上升,也在无形中决定了客服需要花费更多时间去做培训。

如果产品经理定义了一个硬件有问题的ATM,并且也不协调资源解决根因,任其随处爆bug,那么技术人员、客服人员都会陷入解决bug、解释bug的漩涡中无法自拔。

如果产品经理定义了一个杂乱无章的数据统计,当运营需要数据来传递服务价值时,就得花大量时间整理数据,甚至协调资源单独跑数据,一方面延误了价值传递的及时性,客户无法感受服务价值,另一方面也导致运营、技术在各种琐事上折腾,影响工作效率。

可以看到,每个系统能力如果定义有缺漏,整体服务质量会受到蝴蝶效应般地影响,不只是降低了服务提供者的ROI,更甚地是,客户认为没啥卵用。 所以回到前面所说,产品经理提供的服务,绝不仅仅是一个后台、一个工具那么简单,还包括了各环节人力的投入。如何让每个系统能力的效率得到最大化,是利用系统思维解决客户问题关键的一步。

 

本文由 @steseven 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!
4人打赏
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 好文!

    回复
  2. 不明觉厉! 😉

    回复