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

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 需求风险

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

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 效果跟踪

我们推出这样的功能服务，本质是为了提升业务的效率，继而提升商业价值。所以上线之后是需要对这个功能服务进行持续关注。

• 业务回访：比如与业务访谈，了解使用情况、对业务的帮助大不大等。
• 数据分析：又比如从数据角度去看，用量化的手段去观察是否带来业务价值的提升。

五、总结

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

 

作者：A.D，世界TOP50强公司产品一枚；公众号：吾某

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

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