• QQ空间
  • 回复
  • 收藏

以用户标签为例,复盘B端产品的需求挖掘方法论

东方头条 2020-01-13 18:18:01 科技

B端产品核心的工作在于如何把业务流程产品化,从而提升效率。但有时候面对看似毫无关联的业务,或完全没接触过的业务,又该如何进行前期的需求挖掘?近期负责一个关于“用户标签”的需求,这样的需求涉及的业务内容与我此前工作没有太大的交集。这期就简单review一下,如何从需求挖掘到产品方案输出。

阅读指南

受众人群:B端初级产品经理

阅读收获:B端产品需求挖掘的一些技巧;了解用户标签/画像的一些业务知识。

手上负责一个和数据方面有关的B端系统,在日常的产品规划当中,没有关于“用户标签”方面的规划,突然接到一个需求:需要考虑如何在现有的平台中,新增用户标签的业务,让用户在分析当中使用这部分数据(得,又是一句话需求,是多少有点懵逼的)。

Fine,那就开始梳理吧。下文将从“前期调研”、“需求分析”、“产品策划”及“效果追踪“等关键步骤进行说明。

一、前期调研1.1 概念定义

首先,我们先明确一下,这次的需求涉及的概念有哪些。为什么要了解呢?因为对于需求的挖掘是建立在对任何事物的认知保持清晰和统一。如果对于需求涉及的理念不熟悉且认知有偏差,那么后续的任何分析都有问题的。(敲重点!!)

很明显这次需求要在现有的数据分析平台中,引入用户标签的数据,并以功能化的方式,辅助业务用户使用。而这里有几个关键概念:

(1)数据分析平台:此次需求的载体是基于这样的产品系统去思考。

(2)用户标签:需要了解“标签”到底是什么,业务流程是什么。在此之前因为兴趣了解过“标签”的一些知识,但要真说出来它到底是什么,我还真说不出所以然。那么我应该怎么先去确定概念呢?行业分享:通过网上获取,初步对“标签”有了一定的认知。调研访谈:行业有行业的说法,但真正了解的,就是应该从原来提供这个业务的同事去了解。所以采用了访谈的形式,分别从技术、产品及业务类型的同事去了解。用户标签:就是用户某一特征的具象描述,比如性别、学历等。而标签因子就是基于这些特征标签建立的判断要素,又比如“是否为男”、“是否为大学生”等等。

(3)功能化:意思就是要产品策划输出功能方案

(4)业务用户:明确此次需求的目标业务对象是谁,他们怎么用。

1.2 业务调研

确定了概念,接下来就需要先了解一下业务的一些基本状况,包括业务的流程及原有工具的能力。

(1)业务流程

显然我们最核心的,就是要去还原业务在使用“用户标签”过程中的每个流程,知道他们是基于什么原因去使用,期间是怎么操作的,最终的效果又是怎样,以及整个链路涉及了哪些环节,都需要一清二楚。动因:了解客户的标签属性,进行精准营销或推荐。操作:预先基于业务加工标签规则,然后客户的关键信息传到后台,通过调用接口实时判断当前客户是否符合标签规则,并给出“得分”,符合条件则反馈给业务,告知该客户属于什么类型,接下来业务就可以基于这个结果进行下一步的策略执行(比如广告投放、客服营销等等)。

(2)业务对象业务人员:提供业务诉求,对目标负责;产品人员:对接服务,并基于诉求整理标签加工规则;程序员:根据既定规则进行数据清洗、加工标签;广告人员:基于标签结果数据对客户进行广告营销,实现业务诉求。

(3)业务平台状况

由于是协调团队外部资源来实现需求,所以业务的资源能力(即天花板),确定了可以实现需求的上限。经过一系列访谈,我拿到了这些关键信息:标签数据量:涉及10几大类、20几个细分类别、以及接近上万的标签因子;标签准确度:每个标签因子都提供了不同客户类型的饱和度;标签用户:目前现有的标签库是用多个数据来存储客户的信息,比如客户ID、交易ID等等。

1.3 竞品调研

了解竞品,是需求分析当中不可缺少的一个环节,这里可以从3点出发:一个是目前常观察的竞品对手,是否也做过类似业务;第二个就是单独了解“用户标签”在市场上的产品表现状况;业务平台:此前一直提供此服务的业务平台,本质上也是竞品对象之一,只是作为参考对象进行了解。

1.4 调研结论

经过一系列的调研分析,已经有了一些初步结论,对“用户标签”具备足够的信息储备,那么来看看目前的需求已经“丰富”到什么情况。

“OK,一些调研内容已经差不多了,是时候整理并进行下一步的需求挖掘。”

二、需求分析2.1 需求定义核心需求:为日常数据分析提供更多维度的分析能力,形成小中台的能力。提高对客户的精准识别和对运营手段的优化,比如提高留存、转化效果。核心用户:业务、运营和市场人员。业务目标:主要在于提升客户留存、转化,提高营收。

2.2 需求痛点跨平台使用服务,操作体验不便;跨平台服务导致数据跟踪中断,无法持续分析。

2.3 需求价值点

(1)优点对接多个平台,提供更多增值服务;最大程度上保持数据在一个平台的流转,减少失真。

(2)缺点从功能的全面性而言,无法匹配任何一个独立系统的核心服务;各个环节的服务类型相对单一,且没那么灵活、自定义。

2.4 需求风险如何确保数据口径的统一性?用户为什么要使用这个服务(这也是作为产品常常思考的问题)?原本已有这样并且成熟的服务,根本上无法可以完全替代的,所以更多的思考如何在平台上提供这样的一些增值服务。

2.5 需求结论拟建立画像、推送等功能模块,完成目标用户识别、精准营销;仅作为功能辅助之一,短期内无法建立成一个平台化的全服务(也就是我这边资源有限,要想完整多个服务使用还是用老通道吧,我尽力了)。

三、产品策划3.1 产品目标

B端产品和C端产品的最大差别在于,目标思维不一。B端产品注重价值思维,其功能服务能提升业务效率,继而增加效益。而C端注重流量思维,吸引广大用户使用。所以,在确定此次需求的产品目标时,也是基于“价值思维”的立场,也就是切身地站在业务角度。针对客户分群,筛选更有价值的标签用户提供标签分布的可视化,整体了解分群的特征表现连接多个服务平台,提供基础的闭环服务。

3.2 产品规划

因为这样的需求不是短期内完成的,通常情况就是策划一个产品全景图方式,有步骤、计划地完成。至于如何完成,初步可以在第1、2个版本完成基础功能和闭环服务,后续版本在此基础上引入更多的增值服务。

比如:1、2期进行标签数据引入、基础功能规划,3期进行一到两个服务平台的接入等等。

3.3 产品设计

(1)系统设计

广义的B端产品设计,其实是一个线上线下全流程的设计,所以“系统性”的业务设计至关重要。在B端产品设计过程中,需要了解涉及哪些环节、需要提供什么样的基础服务和增值服务,简单的说,就是业务每使用一个服务的时候,接下来都会做什么,一环扣一环,最终满足全链路的服务体验。

(2)设计思量数据统一:由于“标签数据”对现有系统而言,属于外部数据,我们需要思考的是如何实现兼容,只有两者做到真正的唯一对应,这个需求才是真正成立的。那么需要如何实现兼容呢,可以从2个地方入手,一个是内部团队是否有这个资源,可以打通两者数据的关联。第二个就是通过业务入手,沟通是否业务本身就存储这样的关系表。使用价值:一定程度上降低了使用跨平台带来的不便性;提供了基础的全链路服务,能在一个平台以“数据”的方式持续跟踪不同服务的表现;批量处理目标客群数据;

四、效果评估4.1 产品宣导

这样复杂的业务功能,初次上线时用户很大概率是比较懵逼的,因为B端产品在使用中都有一定的学习成本。不同于C端比较易学和上手。所以通常情况下,都是需要对业务用户进行一些产品宣导,具体可以2方面:

(1)新手引导&使用手册

一般新功能上线,不管是B端还是C端,都会有新手引导,所以这本身是一种产品宣导的有效方式。另外,使用手册在B端产品当中也十分重要。使用手册具体就是一个“操作文档中心”,通常B端产品网址都会专门提供这样的入口,供用户查阅。目的是提供相关功能的定义、实现原理、操作步骤等,便于用户能够掌握使用。

(2)线下培训

由于B端产品服务的用户是十分垂直且明确的,不像C端那么庞大复杂,所以通常情况下我们是可以很快找到目标用户(也即核心用户),所以针对这些用户,如果有必要也可以开展专门的上门线下培训,对这一功能服务进行简单的宣讲。可以从功能原理、使用步骤以及支持场景的案例去阐述。

4.2 效果跟踪

我们推出这样的功能服务,本质是为了提升业务的效率,继而提升商业价值。所以上线之后是需要对这个功能服务进行持续关注。业务回访:比如与业务访谈,了解使用情况、对业务的帮助大不大等。数据分析:又比如从数据角度去看,用量化的手段去观察是否带来业务价值的提升。

五、总结B端的需求挖掘到产品输出,需要从系统性角度出发,并完整还原业务的核心场景;需求调研是需求分析中的重中之重,关乎对需求的理解和产出;B端的需求产出,通常涉及多个业务的协助,所以极其考虑跨团队沟通能力和资源协调能力;建立“价值思维”的思考方式,始终以为用户提升效率和效益出发;

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

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