以用户标签为例复盘端产品的需求挖掘方法论
⇨⇦
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端的需求产出，通常涉及多个业务的协助，所以极其考虑跨团队沟通能力和资源协调能力；
建立＂价值思维＂的思考方式，始终以为用户提升效率和效益出发；