前言:文章目录

Part 1:为什么会有想要输出此文?

Part 2:如何更高效地获取真实需求?

1、深谙业务背景

1.1、实用的抽练工具:用户体验地图+转化漏斗

1.1.1、用户体验地图

1.1.2、转化漏斗

1.2、区分业务问题和业务方案

1.2.1、举个例子

1.2.2、如何规避 X-Y Problem ?

2、用业务目标来做决策

2.1、先抛弃与核心业务流程无关的需求

2.2、优先做完善核心业务流程的需求

2.3、发现新的功能价值点

Part 1:为什么会有想要输出此文?

相比用户端需求而言,后台类需求需要产品经理更谨慎地区分出问题事实与业务的想象。相较于以往做用户端的需求重点依赖用户反馈、用户数据分析。后台类需求来源强依赖于内部的运营、市场等团队,而产品直接面向的“目标用户”也从用户变成了内部的运营人员。而运营人员常常会因为业务遇到某个问题,而试图提交需求希望产品给予解决。

这个过程中,业务方往往会将自己加工过后的需求提报给产品,而忽略甚至掩盖掉业务实际遇到的问题或困难导致最终产品出了个“伪需求”,却并没有解决掉业务的问题。

我曾在酷壳网看过一篇文章讲 X-Y Problem 的故事。X-Y Problem的意思如下:

1)有人想解决问题X

2)他觉得Y可能是解决X问题的方法

3)但是他不知道Y应该怎么做

4)于是他去问别人Y应该怎么做

简而言之,没有去问怎么解决问题X,而是去问解决方案Y应该怎么去实现和操作。于是乎:

1)热心的人们帮助并告诉这个人Y应该怎么搞,但是大家都觉得Y这个方案有点怪异。

2)在经过大量地讨论和浪费了大量的时间后,热心的人终于明白了原始的问题X是怎么一回事。

3)于是大家都发现,Y根本就不是用来解决X的合适的方案,其实Z才是最好的解决办法。

X-Y Problem最严重的问题就是:在一个根本错误的方向上浪费他人大量的时间和精力!

这篇文章,不提马斯洛需求理论、不提贪嗔痴、不提七宗罪,只是单纯的来聊聊后台类需求这个东西,以及我过去踩过的坑和总结的一些教训。

Part 2:如何更高效地获取真实需求?

1、深谙业务背景

每个产品经理实际工作中必然会对接相应的业务线和业务方,即你需求的源头来自哪里?基于业务驱动的前提,势必需要你深谙当前的业务细节,上下游依赖的场景和团队,以及短期内业务的变化趋势。只有这样,当业务方提报需求时,才可以尽可能不在业务背景、需求上下文等基础信息同步上耗费太多精力。

1.1、实用的抽练工具:用户体验地图+转化漏斗

1.1.1、用户体验地图

当你初次接手某个业务,用户体验地图是最快速梳理业务现状的好工具,而不定期的更新变化,也能加深自己对于业务的理解。

关于用户体验地图的详细干货以及如何绘制用户体验地图,我将在后续的文章中分享,此处按住不表。

产品快速梳理业务背景最实用的方式就是基于当前的业务场景,把用户从进入流量池第一步开始,抽练出用户行为,整理成用户体验地图。

比如:途家的用户体验地图

1.1.2、转化漏斗

基于用户体验地图,可以进一步抽离出整个用户生命周期中的数据流转,每条流程里可以抽离出一个数据转化漏斗。漏斗模型是拉新业务中最常用的工具。而基于漏斗数据,我们也能知道影响ROI和获客成本的转化率中,哪些指标会成为里程碑式的指标(比如有效好友率),哪些指标会成为关键性的北极星指标(比如有效好友成本)。

单个业务场景往往对应单个数据流转的转化漏斗

在线教育行业的通用业务漏斗

基于以上工具,如果业务方提出的需求并不能很好地归类到用户体验地图和转化漏斗中的某个环节,那很有可能此需求并不能为业务带来有效提升,那么业务方也势必需要更有说服力的理由,去说服产品经理。

1.2、区分业务问题和业务方案

回到开头提到的X-Y Problem的场景,产品需求的生命周期有个共性的地方在于——业务方遇到业务问题X后,想要试图解决,于是想到了Y方案,并给产品提了Y方案的需求;产品基于业务的诉求,直接照搬输出Y方案的需求,好点的产品可能自己思考之后输出Z方案并给研发提了Z方案的需求。但是实际Z未必是X问题的最优解。

1.2.1、举个例子

这里分享个很典型的例子:

业务方曾给我提过一个需求,需求描述很复杂, Jira卡片里直接给出了产品需求需要提供的字段。乍一看需求,似乎是需要在粉丝进入公众号会话窗口时,获取微信上报地理位置时的XML数据包。但是拿来干嘛用?我在和他沟通后,不断灵魂拷问“为什么”,才知道核心的问题是什么?

X问题:

运营目前无法有效监控公众号粉丝的活跃度,因为运营人员不知道公众号的粉丝在关注后每天有多少人在什么时候会打开公众号?进一步,当用户打开公众号的时候,就发消息引导用户做转化。

业务方发现有个行业竞品公众号,粉丝关注后每次回到公众号会话窗口,都会自动触发客服消息推送,他们也希望能用这个能力实现个性化运营。

Y问题:

发现微信官方提供了一个接口,就把接口能力获取用户地理位置的需求实现提报过来,要求给业务具体的XML数据包。

而实际的需求:

利用微信服务号在粉丝进入公众号会话窗口时可以给开发者上报用户当前所在地理位置信息的能力,增加数据埋点,侧面监控公众号粉丝关注后的活跃度(即:存量粉丝中,每天会打开公众号的比例),如果数据可观,后续再策划,基于”上报地理位置信息“为触发事件的客服消息触达能力。

1.2.2、如何规避 X-Y Problem ?

这样的情况高频发生在产品和业务的沟通日常里,那么,如何解决此类问题?

每次业务方提报需求或者产品通过访谈沟通获取到用户/业务方反馈时,不要急于下结论,一定要把用户/业务方遇到的问题,和业务方自己想的解决方案,区分开。

产品经理做需求一定要有一个原则:产品迭代,要么基于数据,要么基于用户需求。

数据其实是用户需求的侧面体现,归根结底,还是要看用户的需求。

因此,实际沟通过程中,一定要问清楚2个问题:

1)业务遇到的问题是什么?有哪些阻碍?

2)业务希望什么用户在什么场景下做什么事情,目的是什么?

基于此,业务提报的需求一定会有对应的数据体现出来,特别是后台类需求。因为后台类产品一定是在既有稳定的业务场景和用户流程基础上抽离出来的效率工具。

挖掘用户需求,是一个体力活,需要不断跟“用户”去斗智斗勇,这里的“用户”,既包括业务方、真实的用户,也包括产品经理自己。人性都有个特点,就是喜欢自作聪明。当你询问“用户”有什么需求时,大部分“用户”会说我想要一个某某功能,而这个功能是“用户”对自己的原始需求提供的自作聪明的解决方案。

2、用业务目标来做决策

从业务背景基础上获取到的需求,往往只证明了需求的真伪,即是否真实存在的问题或需求,而判断一个需求是否需要推进或者排优先级,则需要用业务目标来做决策依据——这个需求能为业务目标的实现带来多少收益?

2.1、先抛弃与核心业务流程无关的需求

相比用户端的场景,后台类需求除了要考虑用户流程、还需要考虑运营使用此工具的操作流程,即:用户端的体验流程+后台的操作流程,都是属于核心业务流程。

基于用户体验地图和转化漏斗的梳理,我们很容易获取核心业务流程,以及在此流程上,当前的业务数据如何?转化率急需优化的瓶颈在哪里?这产品需求的重心也应该往这部分倾斜。因此,大多数情况下,需要抛弃与核心业务流程无关的需求。

如果某个需求上线后对核心业务流程并没有太多收益,那这个需求很可能并不是当前更迫切需要解决的问题。

用户、业务方会持续反馈大量的需求,特别是后台类产品,因为涉及的内部员工角色不同,反馈的问题会更多更细节。产品经理要做的就是从这些需求当中找出可实现的,有价值的需求,排除那些无意义,实现价值不大的需求。

或者是当前暂时先不实现,或者是这个产品不实现但可以利用在别的产品身上的,反正与当前产品核心业务流程无关的需求,都需要排除掉,这个过程就是在做减法。产品经理要捕捉到有价值的需求,围绕产品的核心业务功能推进。

2.2、优先做完善核心业务流程的需求

当收集到的需求无法满足核心主流程的设计时,一种方式是重新做一轮需求收集,一种方式是靠产品经理的能力去找出新的需求来完善产品的主流程设计,后一种方式就是做加法的过程。产品经理依靠自身的工作经验,和对业务、对产品设计理念的理解,可以提出新的需求,这些新的需求不一定就是最终的需求,但产品经理要有能力去总结发现。

2.3、发现新的功能价值点

当我们面对全新的产品设计任务时,没有任何现成的数据去提供给我们做参考,或者说收集回来的需求很少,这个时候就要去挖掘需求,也可以说是发现新需求。产品经理要锻炼挖掘需求的能力,经常关注一些事物的本质,多问为什么,经常去分解现有产品所提供的服务。