HI,下午好,新媒易不收取任何费用,公益非盈利机构
24小时服务热线: 4000-162-306
请扫码咨询

新媒易动态

NEWS CENTER

以业务中台产品经理的视角,聊聊我所认为的“广义用户思维

2020-05-22

用户思维的概念,其实就是从用户出发,关心用户要什么;然后企业/个人提供对应产品满足用户需求。

之所以倡导用户思维,目的就是让产品开发人员换位思考;用同理心感受用户场景,最终能让产品/服务更加贴近需求本质。

但是一个产品的面世过程,会有多人协作,且经历非常多的环节才能完成,而每次沟通都有不同程度的信息衰减。

一些人理解的用户思维,更多是狭义的,只聚焦在产品使用者这一个用户视角。而我却认为PM更应该拥有广义的用户思维,善于发现隐藏的所有用户。

开始正文之前,我先定义2个概念:

  1. 用户:产品经理沟通/反馈/交付的对象;
  2. 用户问题:用户的原始需求/利益诉求/关注点。

接下来,我会以业务中台产品经理的视角,聊聊我所认为的“广义用户思维”。

为了便于大家理解,我们搭个框架,一次按照产品设计的关键环节逐一切入来看。

不同场景中,我会不断代入以上2个概念,去问用户是谁?用户遇到的问题是什么?


一、决策分析(判断信息)

首先,第一环节是决策分析,也是最重要的一个环节。

对一些纯用户产品或B端商业化产品,市场/商业分析就属于这个范畴。宏观上会根据市场、公司战略、资源、竞争等综合信息来判断一个产品是否要做,如要做还要明确大框架上的一些体量、收益、资源投入等关键指标。

而对业务中台(支撑类)产品经理,这个环节更多决策是某个业务需求要不要做,什么时候做,投入资源如何。

这里我们虚构一个案例,便于下文讲解:

案例:业务A、业务B分别给我(业务中台产品经理)提了【积分】功能和【优惠券】功能。

我接收到这个需求,第一步应该怎么做,是直接跟他聊我们已经有这个功能?聊怎么实现成本最小?聊我们资源排不上?

答案:都不是。

在这里,我们首先明确下这个场景下的用户和用户遇到的问题:

看到以上表格,大家就发现了,其实我们面对的不仅仅是业务A和业务B这两个用户,其实还有公司和中台部门这2个用户,并且不同用户之间是有优先级的。

所以,最终我们想要很好解决掉这4个用户的问题,必须先从整体上进行决策分析,而非直接去聊【积分】【优惠券】功能。

经过综合分析,作为中台产品经理,你应该首先依次确定以下问题:

  • 公司战略层面,业务A和业务B本身处于何种位置?
  • 业务A想要的【积分】功能,背后要解决的业务问题究竟是什么?这个功能对业务本身助力如何?功能如果不能实现是否有其他替代方案?这个需求在业务层面的时间预期是?
  • 业务B想要的【优惠券】功能,背后要解决的业务问题究竟是什么?这个功能对业务本身助力如何?功能如果不能实现是否有其他替代方案?这个需求在业务层面的时间预期是?
  • 假如最终确定想要解决业务A、B的问题,需要支持,那么【积分】【优惠券】功能在中台大概开发周期如何?在现有项目安排基础上,如果排上,预计是什么节点开始和结束?功能是否必须中台开发,业务是否可有自主开发的可能性?功能在中台角度,预判后续会有其他更多业务会用到吗?

针对以上问题的发问,我们稍微加工,可以得到以下信息:

  • 公司层面:中台需要优先保证业务A的需求实现;
  • 业务层面:业务A的【积分】功能,根本需求是需要一种抓手,将一定的预算,转化为可以提升用户的平台粘性(登陆、浏览、关注店铺等);业务B的【优惠券】功能,根本需求是想要一种抓手,将一定的预算,转化为可提升平台用户的转化率(下单支付);业务A和业务B对功能的实现预期都是在未来一个月内,时间上存在冲突;
  • 中台资源:在未来的一个月内,资源有限,只能支持一个项目;
  • 中台对需求实现的分析:【积分】功能和【优惠券】功能都具备最重要的共同特征:私有化凭据和流通闭环;而最大的差异性是:积分类型不能针对购买对象进行使用限制但可零散化核销(例如一次消耗5个积分或100个积分),而优惠券类型可以针对购买对象进行使用限制但必须整券核销(一张要么核销要么不核销,不存在半张券核销);
  • 中台已有功能:具备【秒杀促销】功能,已实现促销资金预算化、订单特定减额的逻辑功能,整体实现【积分】【优惠券】等减额类运算有一定的框架基础。

接下来,根据和业务的沟通协调,得到以下决策信息:

  • 中台未来一个月内开发交付【积分】功能,且会按saas化搭建框架(不同业务可以配置平行多套积分体系,互不干预);——后续可扩展,中台既支持了需求,也沉淀了中台能力,可以被后续类似业务场景拓展使用;
  • 业务A直接使用中台【积分】功能,无需多余开发;——需求解决了;
  • 业务B自己在应用层做【优惠券】化包装,但底层复用中台【积分】功能;——业务只需要少量开发,80%可以复用积分功能,需求也一定程度被解决了。

提醒:资源有限和业务B优先级低于A,这些客观因素都可以让中台拒掉业务B的需求,但这只是60分的做法。而中台去帮业务B想变通方案尽量满足业务需求才是更高级的做法。

大家发现了么?

中台在这个角度,所做的事情就是收集全“用户”问题并尽最大程度都解决掉,而决策分析其实就是获取更多信息得到最优解的过程。

二、需求分析(收集&分析信息)

以上决策分析环节,更多是从宏观层面判断一个需求做不做。在这个环节虽然也会有部分需求的沟通,但是颗粒度会粗很多。

而当决策一个需求确定要做之后,就会转到需求分析环节,而这个环节就会深入去聊许多需求细节。

接下来,我们就继续沿着上述案例往下拆解。

看看我们需求分析的对象是什么?仅仅是【积分】的功能逻辑开发么?

答案:不是的。

我们来看看此刻我们的用户和用户问题:

相关推荐