2023年B端策略类数据产品如何业务化

B端策略类数据产品，如何业务化？我们经常听到如下声音：

客户A说：看完你们的产品，我不知道能做什么，除了看看数据，还能解决我什么问题。我不想使用，更不想付费。客户B说：我在使用你们的产品时，想解决一个问题，产品操作起来特别麻烦，东拼西凑才能得到我想要的信息。运营说：PM缺少业务sense，没有理解透客户需求，做出来的东西没人用，再怎么推广也不行。PM说：运营没有好好收集业务需求，也没有做到精确     地理解和传达客户的真实想法，导致我做产品基本靠猜和抄。这是一款B端业务策略类数据产品在【从0到1】建设过程中经常发生的问题，信任许多做数据产品的同学都遇到过。

总结下来，核心是业务需求和产品实现之间存在断层，导致产品不够场景化、业务化。

我们认真想一下，是PM没有业务sense吗？是运营没有把客户声音理解和传达到位吗？是我们力量不行吗？

其实压根不是人的问题，是机制和流程的问题。

即，在业务-运营-产品这个合作体系中，往往会缺少一套行之有效的可拆解的标准机制。

来看一个产品例子：

以下是关心客户推断市场规模大小及趋势的一个产品功能，可以假设你是客户，再看这两个产品。

明显，产品优化后，再小白的客户也可以清晰地知道，当我要推断市场规模和趋势时，这个功能可以帮我看到市场体量的量级、排名和变化趋势。改动前，首先“市场占比top5”的含义就很宽泛，且假如我的目标市场不在top5，我是看不到的，其次“数据趋势”更是让人感觉很模糊，什么数据的趋势呢？要用来做什么呢？

看似简洁的改动，背后需要有一套科学的机制支撑。

依靠科学的机制，完全可以做出一款让客户看完就能get到价值并认可的数据产品。

下面，我以曾经做过的三款策略类数据产品为例，共享我是如何通过搭建一套标准机制，解决业务需求到产品实现之间的断层问题，实现产品场景化和业务化的。

这之前，可以先思索下面几个问题，带着问题来看这套标准机制。

为什么运营访谈客户得到的调研报告，PM只是拿来看看，并没有多大作用？为什么PM对于客户的需求和使用场景，总是比较模糊，不得已半猜半抄地做产品？为什么产品评审会上，技术常常一脸怀疑，质疑你的产品价值？为什么推广产品时，客户听完没有眼前一亮的感觉？整套机制共分四个环节，概览如下：

一、猎取有效信息

即，运营通过科学的调研访谈方法，猎取真正能关心产品建设的有效信息。

什么是有效信息？

完整复原客户的真实场景就是有效信息。

先看两个访谈的例子：

访谈信息1：客户需要定期查看在各个媒体的投放表现。

访谈信息2：【营销优化师】【每日早上9点半】，在【营销部门工位】上，【通过分析各大媒体的广告成效表现来看是否需要调整投放策略】。营销优化师会【先登录各大媒体后台以及网站后台拉取自身数据，包含消耗和转化指标（CPC/ROI/CPM…etc），再通过透视表、可视化图表等来分析广告成效近一周的消耗及转化指标的趋势，发觉ROI对比前一周过低，因此针对性地分析了消耗指标、Clicks、受众等关键数据，据此查找影响ROI的关键因子。】最终花了2-3小时分析出【受众类型为关键影响因子的可能性较大，然后去媒体后台调整投放受众类型】。

明显，后者是一条真正有效的访谈信息，很好地复原了客户的真实工作场景，PM拿到这个信息，可以做深化地分析拆解，甚至可能据此设计出一个很棒的功能。

所以，猎取有效信息是产品能否场景化和业务化的关键，这要求运营要有很强的调研访谈力量。

那么，怎样才能做好场景调研呢？

首先，我们要清晰，在策略类数据产品0-1建设的过程中，调研访谈应当紧紧围绕两件事绽开：

第一，了解业务全貌和业务场景全景图（如下图）。它可以帮我们了解业务并有全局把握，明白每次功能建设是在服务于全景图中的哪个环节哪个场景，同时便利初步了解各个场景建设的优先级。

其次，了解全景图中，每个场景的详细细节和有此场景需求的客户特征（如上文“访谈信息2”）。它可以帮我们复原客户真实场景，深化了解场景细节，为实际的产品建设供应弹药库和指南针。

详细落到访谈这个动作上，该怎么做呢？

为什么有时候访谈费时费劲还得不到什么有效信息？为什么我的问题和客户的回答完全不在一个频道？

没搞清晰访谈目的、没找对人、没问对方式，都是缘由。

1）业务全景图访谈流程

①期望得到什么？

一张或者多张业务场景全景图，囊括不同类型客户的业务特征、业务目标、生意的各个环节（最核心）及各个环节的目标。

②访谈谁？

内外部的业务专家/行业专家。他们拥有全局视角和剧烈的业务sense，可以帮我们梳理出业务全貌。视状况，一般5-8位专家即可帮我们理清晰。

要特殊留意受访人意愿度，不管是通过人情关系还是付费，肯定要保障受访人的协作度意愿度足够高（可以试着统计时间，受访人的讲话时长2倍于我们的讲话时长即可），一个只想快点完成任务的受访者，我们是猎取不到有价值的信息的，甚至会误导我们的推断，这个环节花点钱是肯定值得的。

另外，记得维护好与业务专家的关系，他们以后可能会变成你的智囊团。

③

问什么？

客户分类、不同客户的生意模式、生意阶段、关键业务目标。不同客户在生意的各个阶段主要做什么，有哪些环节，目的是什么，详细是谁在做。④如何问？

step1.答案预设

在提问前，自己要先做一次场景预设，有可能是自己的阅历，也有可能是猜的，都没关系，带着自己理解去访谈的效果会事半功倍，当专家的反馈和你的理解不全都时，你会恍然大悟，这个场景就深深印在了你的脑海里，通过不断地访谈和迭代，当专家们对你的场景图基本认可，就大功告成了。访谈其实就是一个不断修正你的想法的过程。

step2.问题和话术设计

尽可能具象化：看两个话术：

“您认为客户的整个生意链路是什么样的？”“您认为客户在筹备一场广告营销活动时，在选择商品层面上，最关注的问题是如何找爆品吗？”这两个问题的哪个更简单回答，哪个的答案更可能符合你的预期？不言而喻。

问题设计优先级：一般来说，推断题选择题填空题开放性回答题，不到万不得已，不要让受访人去回答你的开放性问题。当然，假如受访人兴致大好，滔滔不绝时，尽量引导他连续说下去，这个过程中他可能不经意间回答了你的好多问题，甚至有意想不到的惊喜。

小tips

能一对一不要一对多，多人访谈也许率等待你的不是百花齐放而是尴尬的缄默时刻。能见面不要线上，见面三分情，当面谈天，受访人的平安感会提升，猎取的信息会更丰富。2）场景细节访谈

①期望得到什么？

整理出一条条完整的场景。

标准模板：【人（角色）】，在××【时间/频次】，在××【地点】，由于××【缘由】，会做××事情【当前工作流程】（最重要），得到××结果【结果/结论】，盼望产品给到××支持【详细需要哪些产品力量支持（尽可能细化到详细功能点指标维度）】

②访谈谁

我们的业务场景全景图中，每个环节对应的实际执行的角色，可能是客户的人（数据分析师、投放人员、管理决策人、市场分析人员等），也可能是客户的代理人（比如三方代理）。基本上每个环节访谈2-3人即可。

受访人意愿度原则同上。

③问什么

首先，不要围绕当前产品使用体验来问，应当抛开产品，针对客户当前的场景和业务问题来问。这是最重要的一点，也是大部分人最简单踩的坑。

试想一下，假如你问：“这个功能使用下来感觉怎么样，有没有解决您的问题”，你得到的答案只能是针对现有产品的功能体验反馈，或许，一句礼貌性的“还不错”就把你打发了，而这些信息，批量的问卷就可以解决，并不能指导后续怎么做产品，也很难挖掘到新场景。

基础信息：尽量在正式访谈前，将如下信息搞清晰——

受访人角色、职能、客户的背景（做什么业务、属于全景图中哪种类型、规模、核心目标、当前生意阶段等）。

客户场景：尽最大可能复原客户场景六要素【人物、时间、地点、缘由、工作流程、结论、需要什么】。

【缘由】在当前业务阶段，核心的目标是什么/有哪些？【当前工作流程】在此目标下，目前主要是如何做的？【人物/时间/地点】主要是由哪个部门/角色来负责以上工作？也许是什么频次？【结果/结论】依据当前业务流程，盼望得到什么？【所需力量】针对此目标，在目前工作中，还有哪些数据/信息/力量是盼望猎取，但目前没有的？【竞品】（可有可无）是否接触过或者用过类似的数据类软件系统？是哪些？④如何问

step1.答案预设，同上。step2.问题和话术设计，同上。小tips：提前了解客户的敏感线在哪里，每个客户不同，避开问及敏感话题，否则我们的商务销售会翻脸。通过为期1-2个月的访谈，猎取大量有效信息，可以对业务全貌和重点场景有较深刻的理解和学问储备，在产品0-1阶段，访谈需要持续进行，不断深挖每个业务环节，补充和修正客户业务场景信息，直到产品真正完成从0到1的建设。

二、精确     翻译信息

即，产品和运营一起，将猎取到的客户场景精确     地翻译成客户在场景的每一步要解决的业务问题，通过深度剖析业务问题得到产品解决思路。

这个看似繁琐的翻译转化过程，实际是整个机制中最核心的一环，这一步直接影响到客户需求是否能完善地转化为产品功能，同时也保障了PM的思索深度，对PM的问题剖析理解和产品化力量是一个考验。

其中，最重要的是【B.提炼业务问题】和【D.思索产品解决方案】，即，“如何把调研猎取的业务流程，转化为背后的业务问题”，“如何针对业务问题，给出合理的产品解决方案”，这些问题完善解决后，产品的功能设计将水到渠成，特别简洁。

1）提炼业务问题

这个过程需要PM深度思索客户在业务流程中做这样的动作究竟是为了什么？可以试着去想：“假如这个步骤的这事儿做成了，假如这个业务问题客户得到了解答，他能得出哪些对自己的生意有用的结论”。

假如还是提炼不出来，可以试着把“是什么”问题，拆解为“是否”问题。

看2个例子：

例子1：

【业务流程】客户通过各种三方工具调研目标市场的规模。【错误的业务问题】客户盼望了解市场的体量大小？【正确的业务问题】这个市场规模，对于我而言，是否足够大，生意天花板在哪里？以上哪个业务问题，能关心客户推断自己是否应当进入这个市场呢？

例子2：

【业务流程】客户通过在后台拉取的广告数据，对比不同受众、广告类型、渠道、素材的表现。【错误的业务问题】客户盼望了解不同的广告配置的投放表现？【正确的业务问题】影响我投放好坏的因素是什么？是广告设置问题，还是人群定位问题，还是广告创意问题？假如是广告设置问题，那是国家问题还是广告目标问题？以上哪个业务问题，能关心客户直接找到问题并进行优化调整呢？

下图是针对例子2的错误业务问题理解和正确业务问题理解，做出的产品。

你的业务问题提炼的是否精准，打算了你的产品功能是直接解决客户问题，还是间接解决客户问题。

换个角度来讲，在策略类数据产品中，衡量一个产品功能是否足够业务化，可以看页面的操作简单度，假如客户需要不断地筛选、排列组合才能解决业务问题，那说明PM没有想的足够清晰。

肯定程度上，我们应当尽量朝着设计一个客户几乎不需要操作就可以解决问题的页面努力。

另外，值得一提的是，拆解出的这些业务问题，稍加调整话术，就可以作为功能页面的名称，客户一眼就看懂了。如例子2：产品页面可以命名为：“定位/诊断广告投放问题”

2）思索产品解决方案

在这一步，要求PM深度剖析每个业务问题，并思索最佳的最直白的产品解决方案。

首先，PM要先明确客户的业务问题需要用到哪些数据，这里一方面需要你的业务常识，一方面需要用到客户访谈中的信息细节。

比如“市场规模”，我们都知道，市场规模和市场销量强相关，但是我们猎取不到市场销量的数据源，那替代方案是什么？明显我们手里的广告消耗数据是最贴切的，广告主投放的广告越多，商品的销量普遍会更高。而真实的投放消耗是敏感信息，所以需要脱敏拟合成消耗指数。这时你就可以给你的算法同事提需求了。

接下来，要思索用什么样的方式展现广告消耗数据，能解决客户的业务问题：“市场规模是否足够大？”

你应当很快想到，一个根据广告消耗排序的各地市场的柱状分布图是最好的解决方案，既能看到消耗量级，又能横向对比其他市场，了解目标市场在全球大市场的位置。

思索产品解决方案的核心是把业务问题转化为产品语言，对于PM的产品化基本功是个考验。

既需要你熟识大部分常用的数据图表和交互方式，每个业务问题你都能快速匹配出最科学的功能设计方案。

也需要你对自己团队的数据力量有清楚的推断，哪些是数据源问题、哪些是数据加工问题、哪些需要数据拟合、脱敏，哪些可以直接用，你都要门儿清。

最终，我想说，衡量一个业务策略类数据产品经理的力量，不是你把握了多少种图表和呈现交互规律（这更应当让前端和设计去制定整个团队的统一标准），不是你的原型图和PRD写的有多好（这只是一种沟通方式），也不是你的数据力量和技术力量有多强（这更应当是数仓和开发该解决的问题）

上述当然需要，但最关键的，是你对业务流程和业务问题剖析是否深刻，你能否针对问题给到科学的解决方案，这将打算最终的产品功能是否足够“场景化”，客户是否一眼就能知道能干吗，怎么用。

一个不能通过场景化的方式解决业务问题的PM，很可能会把团队带到一个又一个坑里（技术的努力白费、运营又推广不出去）

三、产品落地实现

即，PM和运营依据上一步转化出的业务问题和产品解决方案思路，推动产品落地。

这一步其实是对产品思索的验收和落地，值得共享的是，这几个我们耳熟能详的评审会（尤其是产品预评审会），应当分别以什么内容作为核心议题，参会的开发、测试、设计、运营等人员，应当在各个会议中争论什么内容，要通过评审解决什么问题。

下面我会共享我们在产品评审环节做出的改革和变化。

1）产品评审会的现状和普遍问题

我见到的产品评审会，大致分几种状况：

A：预评审讲一遍PRD，研发针对细节提问和争论，PM再改一轮，正式评审再讲一遍PRD，最终敲定方案，开头技术评审和设计评审。B：预评审讲一遍产品建设思路框架，团队内部一起争论合理性和可落地性，PM再进一步产出PRD细节，正式评审跟研发讲一遍细节，最终敲定方案，开头技术评审和设计评审。站在开发的角度，信任许多技术同学的心路历程是这样的：“为什么要做这个功能？客户会用吗？埋头干一个月最终会不会白费了？算了，他也讲不清晰，让咋做就咋做吧，看看哪些点做起来比较麻烦，尽量砍掉得了，反正也不肯定有人用。”

为了解决这个问题，许多团队要求，产品评审时PM要讲清晰背景和为什么做？PM也照做了，但好像大家仍不怎么感爱好，渐渐沦为形式主义。

我们思索两个问题：

PRD为什么要过两遍？无非是有的地方没有想清晰，被challenge之后要修改。产品预评审会的主题应当是争论功能如何实现吗？假如是争论产品建设背景，那应当怎么争论？2）解决思路

不管评审分几个环节几个会议，首先要解决的是为什么要做的问题。

但绝不是一段话把背景描述完就能解决的。

好的背景阐述肯定是布满业务故事性和代入感的，最好是协作运营的业务解决方案，实操一遍demo图或者初步的功能设计，业务解决方案的每一步对应我的哪一个功能。这件事甚至可以由运营同学来做。

来看一个预评审片段：

运营：“首先，我站在客户角度，给大家讲一个故事：“我是一个业务阶段较为成熟跨境电商品牌，最近预备进军一个新市场，我有几个预设的目标市场，首先我要推断这个市场是否值得我投入精力进入，第一步我要看到这个市场的需求规模，这打算了我的生意天花板”。这是我们调研中了解的客户原声，相像的需求共有××条，占比××%，相像的潜在客户也许有××家，粗推断，假如解决这个问题，可以为我们的产品带来××个新客户。”

PM：“基于刚刚运营同学提到的客户场景和业务流程，我拆解出客户的业务问题为：“目标市场的需求量是否足够”，我们基于自己的数据力量，可以用市场的广告消耗等方式来衡量市场规模。所以产品解决方案是：【目标市场spend指数】+【spend指数和占比的排名榜单】。下面是我初步画的demo，由运营同学来实操产品功能解决刚刚提到的客户场景。

运营：“首先我依据自己的预设，选择目标市场，然后查看这个市场的spend指数，了解到市场的规模也许是××量级，同时我查看这个市场的spend占比及排名，我就知道这个市场在整个市场以及较我之前的老市场，处于什么位置。最终直观地了解到市场需求是否足够大。”

假如你是技术同学，你听完之后是什么感觉？

当背景阐述结束后，技术同学应当核心围绕客户场景、业务问题、解决思路绽开充分争论，直到充分认可整个场景和解决方案的合理性。若PM无法解释清晰，预评审则不予通过。

整个过程不用很长，15分钟就能讲清晰背景，再留15分钟充分争论，30分钟解决产品预评审。

我认为，预评审到这个程度就已经特别胜利了，后面再按部就班地开展功能细节评审、技术评审等。

另外，对于这套机制，整个产品评审和开发过程，更应当采纳灵敏迭代制度，而不是月度/双月度班车式迭代。哪个PM想清晰了，就可以随时申请预评审，通过后，根据排期进入待开发/开发环节。实行这样的方式，对PM的绩效考核也变得简洁了：做的好PM肯定是设计了更多功能、解决了更多业务问题的人；同时，对于开发人员的考核，也可以引入肯定的业务指标，可以保障开发人员在评审环节对PM起到监督作用。

这样，管理者想看到的良性循环就RUN起来了。让每个人成为机制的一部分，并供应科学的激励奖惩措施，才是一个科学的管理体系。

四、共性化方案推广

即，产品上线后，运营针对这个功能解决的场景、业务问题和目标客户，进行有的放矢地推广（当前3步完成，第4步就走的相对轻松）

这一步最核心的是【建立解决方案库和共性化推举】，有了它，信任我，每一次客户培训，每一次市场推广，客户肯定会觉得直击痛点，感同身受。假如前3步顺当完成，第四步就是一个逐步积累的过程，没有什么技巧可言。除此之外，比较依靠运营讲方案/培训的力量（我们以后再讲怎么组织和做好一场客户培训）。

以上简洁来说，就是向不同的客户推举共性化的解决方案内容（想想抖音胜利的关键就明白了）。

首先，我们要明确推广的目标客户。

目标客户就是访谈过程提出此场景的一类客户。

客户的