起点学院课程

2B产品的需求调研,还真不是人人都是产品经理

2 评论 5455 浏览 19 收藏 13 分钟
15天0基础极速入门数据分析,掌握一套数据分析流程和方法,学完就能写一份数据报告!了解一下>>

2B产品经理要深入了解、挖掘出客户/用户的真实需求,需要先具备一定的企业业务常识+良好的沟通引导技巧。本文作者给大家提供了三个步骤,来做用户访谈,希望能够对你有所帮助。

当你打开一款2B产品的工作台时,是不是会有个困惑:

  • 工作台上一堆的功能列表,到底是从哪来的?
  • 哪个产品大神能突发奇想,设计出这么一大堆功能?
  • 这些功能到底解决了用户的哪些需求?

上一篇文章《2B产品经理如何快速准确了解一家企业业务》,我们讲了如何对一家企业有个基本的了解,现在我们就可以开始对客户(买单的人)、用户(实际操作系统的人)做需求调研了。

小白可能会问,为什么要大费周章地先对企业业务做一番了解?直接做需求调研不就好了吗?

如果一名2B产品经理真的这么做,大概率会在调研过程中,被调研对象在心中贴上:外行领导内行的标签。

一个2B产品经理不懂业务,却要去做一款2B产品,如果你是用户,是不是会心里发毛?

所以,2B产品经理在需求调研前,一定要对调研内容做到心中有数。这完全不同于2C产品是为了满足个人日常生活相关的需求,只要你有点生活常识,人人都是产品经理,张口就能和用户聊需求。

今天我们继续2B产品设计的第二个环节:需求调研。

2B产品的需求调研方式,我个人首推通过用户访谈。就像之前我们说的2B产品注重流程,2B产品经理要了解企业业务需求,最好的方式就是通过客户/用户访谈,面对面地和用户沟通、倾听、交流。

魔鬼藏在细节里。2B产品经理要深入了解、挖掘出客户/用户的真实需求,需要先具备一定的企业业务常识+良好的沟通引导技巧。

你可以参考下面的步骤来做客户/用户访谈:

1. 向客户(买单人)了解产品定位?

为什么特意把客户和用户分开来说?

2B产品的选型过程更长、更复杂,往往是先在企业内部有过多番讨论的结果。2B产品的客户和用户常常不是同一类人(这里说的客户指为产品买单的人,用户指未来产品的使用人)。客户的需求一般侧重企业战略如何落地,管理制度如何落地,产品能带来哪些额外价值?

因此,2B产品经理在与客户沟通时,要有CEO思维,多从商业(通俗点就是:做生意,你关注什么)的视角去理解对方的意图。

与客户访谈,有利于产品经理站在更宏观视角去理解未来产品的定位。

郝志忠在《用户力》一书中提出,产品设计要先回答产品定位的问题,而产品定位从通俗上来说,要回答:做什么?做给哪些人用?做成啥样?这3个问题。

2. 向用户了解应用需求

与客户(买单人)了解清楚产品定义后,就可以带上准备好的调研问卷,结合上一个环节了解的企业业务信息,找到企业通讯录上的核心用户,来和用户沟通具体的应用需求了。

注意:事先准备好调研问卷,能让你更从容、有针对性地进行用户访谈。

调研问卷,可参照下面的思维导图作为框架:

调研对象、业务角色:相当于我们在招聘网站上看到的招聘岗位、岗位职责。

背景说明:让调研对象先热热身,可以让TA先比较宽泛地聊聊自己当前工作中遇到了什么问题?哪些问题希望通过产品来解决?之前是不是有使用其他产品?对新产品有什么期望?

需求描述、业务过程:引导调研对象结合自己的实际工作场景,描述具体工作细节。产品经理可以初步判断哪些是产品能解决的问题?一般来说,现有单据(如在用的出差申请单)、审批流程(如根据申请人岗位判断需哪些领导审批)、业务规则(如根据申请人岗位对应差旅标准)这类可明确、有逻辑、可结构化的的内容都是产品要解决的范畴。这些都属于功能性需求。

非功能性需求:2B产品用于企业生产经营活动,那么产品经理就需要多一步考虑:除了满足用户的功能性需求,是不是有哪些非功能性需求同样非常重要?

上图我提到了几个常见的:

(1)安全性:有的2B产品的数据就是企业的血液。对于数据泄露、丢失等问题,有的企业是零容忍。产品经理就要重视数据安全的相关方案。

(2)易用性:可参考之前写的2B产品经理的用户体验,都值得再做一遍

(3)稳定性:2B产品在设计时一定要尽量做到全面规划。前面说到产品定位要回答产品做什么?做给哪些人用?做成啥样?回答清楚这3个问题,2B产品的设计就不会随波逐流。

这里插一句:我们日常的2C产品比较喜欢刷存在感,时不时喜欢更新个版本,很多改版只是做些小调整,比如做个页面改版。目的是让用户有新鲜感。相反,2B产品因更注重用户的操作习惯,所以应更注重稳定性,能不改则不改。

白鸦之前在内部分享会上说,有赞的产品自从推出第一个版本后,就没对导航、页面布局、交互做过调整。

个人认同:2B产品的每一个设计都要想清楚,不要来来回回不断调整。每一个大调整,都增加了用户的学习成本,稳定性是衡量一款2B产品设计好坏的关键指标。

(4)性能:这个对一般用户比较抽象,用户一般直观感受是操作时,产品反应速度怎么样(比如打开一个页面不能超过3秒)?翻译成专业术语就是响应时间、吞吐量、并发数这些指标。

(5)可扩展性:这个可理解为产品的灵活性。比如,产品是否需要为管理员提供参数配置、业务建模等高阶功能,满足业务变动、发展的需求,而不需要额外增加开发工作量。

需求优先级:访谈到最后,用户可能洋洋洒洒和产品经理讲了一大堆需求,这时产品经理应要先对用户的需求做一轮概括复述(目的是确认自己是不是有抓住用户需求的核心),然后可以适当引导用户说出其中哪些需求的优先级最高(这是在为后续的产品需求优先级做准备),适当地收敛、聚焦核心需求。

3. 提供、确认需求调研报告

前面我们和客户/用户斗智斗勇地展开了一场场的用户访谈,最终还要通过一个产出物-需求调研报告,让客户/用户了解我们对其需求的理解程度。大家互相做到知己知彼,才能在未来的产品设计、开发中不会出现需求理解错误的尴尬局面。

需求调研报告的内容需包含前面的2类需求调研内容,需求调研报告的模板可以参照上面的思维导图。

需求调研报告这类动则几十、上百页的文档,如果直接发给客户确认,往往会石沉大海。

这有两方面原因:

  • 一方面,需求调研报告主要就是复述客户的实际业务和期望解决的问题,并无多少新意,难以引起客户仔细阅读的兴趣。
  • 另一方面,人们对这种几十页的正式文本,往往拿起来就有恐惧感,文字阅读本身是反人性。

建议解决方案:

3.1 向调研对象现场讲解主业务流程

尽量用一幅流程图讲清楚被调用对象的主业务流程,个别需要特别说明的子流程,可以补充说明。

建议通过会议的方式,现场向用户演示、确认,因为这个过程可能会有不少思想碰撞,现场的效果最好。

主业务流程图如下:

主业务流程是后续产品设计的主轴,我们可以把它视为未来产品的框架,一旦理解有误,直接影响后续的产品设计、开发。

3.2 将报告化整为零地确认。

在工作中,我们会遇到一个棘手问题:文档到底应该按用户为对象来划分,还是应该按业务流程为对象来划分。我的看法是:按业务流程来划分。

因为任何一个用户在一条业务流程中,都只参与其中一部分。以业务流程为对象来划分,一方面可保持业务流程完整性。所有与该业务流程相关的人,可看到整条业务流程的完整信息,不会出现疏漏。

另一方面可减少文档内容的冗余。如果以用户为对象,不同用户在一条业务流程中存在上、下游关系,描述业务时既得先说明TA的上游用户需做完什么(类似前置条件),又得说明TA做完后的后续流程是什么?导致描述不同用户的流程内容时,会出现很多重复内容。

举例,一条业务流程有A,B 2个用户按顺序来一起完成。在描述A用户负责的业务内容时,需要说明A用户的后续流程内容。这个刚好就是B用户负责内容的前置条件。

通过分开确认不同的业务流程,可以降低确认难度。

做完上面的3步,2B产品的需求调研就算完成了。到这里,我们已经理解了调研对象的详细需求,接下来,我们就可以进入需求分析环节了。

小结

今天我们讲了需求调研时,要做的3件事:

  1. 向客户(买单人)了解产品定位?
  2. 向用户了解应用需求;
  3. 提供、确认需求调研报告。

你也可以上手去试试,希望可以帮到你。

 

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

题图来自 Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
起点学院课程
评论
评论请登录
  1. 2B是业务大于体验,特别是对业务边界要有把控。往往员工个人需求和公司整体需求是相背的(在CRM系统中体现的淋漓尽致),其次以为部分业务出现于跨部门对接中。同一个业务场景需求也是相背的,所以涉及跨部门需求时也需要跨部门评审。

    回复
  2. 2b产品超难搞,特别是一些业务流程上面处理其来,比2c的难多了。

    回复