B端产品需求分析与挖掘
在做需求收集之前,要确认需求的来源,一般包括产品规划类、业务类、用户反馈类、市场及竞品需求四个内容。接下来,我们看看作者的分享。
在这里总结了几种进行需求分析的方法,有5W1H分析法、用户故事地图、马斯洛需求层次、KANO模型、四象限法则、RICE原则等,由于B端产品涉及到的角色管理流程复杂,需求大多来源于业务方,针对于B端需求分析最常用的方法为5W1H法和RICE原则。
在进行需求分析之前,首先需要收集需求,调研需求的方法有用户访谈、问卷调查、焦点小组、业务轮岗实习、数据分析、行业研究、竞品分析等。
在进行需求收集之前,先确定需求的来源有哪些,一般需求的来源分为产品规划类需求、业务类需求、用户反馈类需求、市场及竞品需求。
一、产品规划类需求
根据公司的战略方向、产品定位来制定产品规划类需求,从市场大框架来梳理产品架构,知道这个产品的目标是什么,产品边界在哪里。
在整个规划过程中,会不断完善和调整产品架构图,可按三个层级梳理,以客服即时聊天系统为例:
- 第一层,按照角色来判断梳理,客服即时聊天系统可以分为客户端、客服端以及运营端,主要解决客户能及时找到客服人员解决问题。
- 第二层,梳理各角色涉及到的模块,客服即时聊天系统包括了与客户对话的H5聊天页面,客户信息管理、对话管理、基本设置等。
- 第三层,针对各模块梳理大致点,如对话管理可以分为在线对话、等待接入、传送对话、响应传送、结束对话、等待评估、客户评估、历史对话、常用语管理等,逐层级拆分需求把产品架构图整理绘制出来。
二、业务类需求
接触到一个新业务时,在梳理业务流程中,收集业务类需求,先要理清最基本的业务组织架构图,通过组织架构图理解管理体系和职能单元的设计,以及后续规划,然后通过用户调研,梳理出目前的业务运作流程。
在业务流程里的第一个基本元素就是角色,有了角色才会有分工、有协助,才能完成特的价值目标,其次是活动,即每个角色都会有具体需要做的事情,当每个角色有了具体的活动,就会有产出,最后达成一定的目标。
对于业务类需求,最好的方法是轮岗参与业务环节和用户调研。对于用户调研,运用需求调研五步法:
- 先明确调研目标,了解业务模式和业务特点,了解业务目标和业务规划,了解当前业务运转方式,然后挖掘当前问题与痛点
- 选取调研对象,根据业务组织架构,选择每一个节点的干系人
- 设计调研大纲,根据调研目标和调研对象,针对每个干系人设计不同的问题
- 执行调研计划,提前将调研大纲发给被访者,以便被访者先大概了解访谈内容,提前做准备,在访谈过程中还应该循序渐进,在调研结束后,与被访者保持联系
- 总结归纳输出,对访谈内容进行整理,输出用户访谈记录表
在此过程中,进行全场景分析,即谁在什么情况下,在什么时候,带着什么目标,通过什么途径,采取了什么样的动作,完成什么样的目标,具体拆分:
- 场景要素
- 梳理出尽可能详尽的业务流程
- 基于业务流程找到对应的全场景
- 基于全场景找到对应的用户需求
- 确定边界,也就是确定哪部分场景需要系统支持,哪部分场景需求不需要系统支持,哪部分是手工+系统支持
综上,业务类需求基本就能提取出来了。
三、用户反馈类需求
根据用户反馈的需求优先级整理成用户需求池,我们的用户提需求的时候,经常会按照他们平时的工作习惯,直接给出解决方案,让你按照他们提的方案进行修改,那这个需求到底该不该做呢?
我们不能只做需求的传递者,俗话说的传话筒,要做一个需求解决者,利用13要素5步法深挖需求。
1)是谁?
提出人是谁,使用人是谁?受影响人是谁?
2)想要做什么?
基本场景是什么:是谁想要解决谁的,什么问题?这个问题中有需要进一步细化和明确的概念吗?发生频率是多大?
3)了解需求背景,为什么?
多问为什么,核心问题(痛点)是什么?强烈程度如何?实际的价值是怎样的?
4)是否更多的可能性?
横向替代场景是什么?纵向互补场景是什么?把该有的功能点都列出来,看是否有更多的细分场景?
5)如何解决?
要解决这些问题有哪些可行的解决方案?这些方案实现的成本有多大?你觉得哪种方案最适合?该解决方案对用户而言有什么优缺点?有没有其他需要挖掘的需求点?
把这些问题进行场景化描述出来,问题一一确认完毕,那么这个需求就能确认并纳入到需求池中了。
四、市场及竞品需求
首先深度体验竞品功能,梳理出功能清单列表,体验竞品模块的功能流程和用户路径,再看该模块和其他模块产生的交互点,了解完竞品模块后,再根据自己产品的实际使用场景来梳理可以借鉴的点,对于竞品分析,重点还是要做产品的重度使用者,挖掘出更多的用户痛点。
将需求收集完毕后,接下来会进行需求管理,会将需求分为功能性需求和非功能性需求,而功能性需求包括了业务需求和用户需求。然后对于需求优先级排序,一般会运用RICE原则和价值成本模型,制定需求版本迭代计划。
RICE原则:
- Reach(触达):多少用户提出来的
- Impact(影响力):对用户的价值有多少
- Confidence(信心度):产品经理的信心
- Effort(努力):标准化的难度和研发成本
对于B端产品,需求排期都是在综合分析后进行的决策,并不是单一的分析,看的还是产品经理本身的经验和能力。
本文由 @Fiona 原创发布于人人都是产品经理。未经许可,禁止转载。
题图来自Unsplash,基于 CC0 协议
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。
这些工作偏向于需求分析师的多吧
受教了
哈哈哈哈,希望对你有用
写需求多问问为什么,不错
是的,尽量避免需求频繁变更
一学就会,一用就废
主要还是在实战中摸索运用
是的,方法论放之四海皆通用,或者说方法论就没有错,实战更重要