在产品落地建设过程中，业务负责人要思考如何填补业务需求和产品实现之间的裂痕和断层，使产品进一步业务化、场景化，同时让用户清楚地看到产品价值的问题。
本篇文章里，作者便总结了4个帮助策略类数据产品业务化的有效步骤，一起来看。我们常常听到如下声音：
- 客户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步顺利完成，第四步就是一个逐步积累的过程，没有什么技巧可言。除此之外，比较依赖运营讲方案/培训的能力（我们以后再讲怎么组织和做好一场客户培训）。
以上简单来说，就是向不同的客户推荐个性化的解决方案内容（想想抖音成功的关键就明白了）。
首先，我们要明确推广的目标客户。
目标客户就是访谈过程提出此场景的一类客户。
客户的属性包括：行业、生意模式、业务阶段、使用角色等。试想，不同客户之间使用场景千差万别，即使同一个客户，管理人员和执行人员关注和使用的场景一定也是差异巨大的。
所以我们需要在【获取有效信息】环节，就对客户打上特征标签，具体用哪些标签，取决于产品定位的目标客户。这样我们在推广阶段就能轻松对应到这个场景的目标客户特征，进而找到这一批客户。
其次，建立业务场景解决方案库。
将每个业务问题对应的一套套解决方案以及方案对应的目标客户特征记录在一张表中，就形成了方案库。
当对外进行推广培训，或者客户问询产品时，都可以针对目标受众特征，自由组合，从库中提供个性化的解决方案（听起来就像一套人工推荐算法）。
类似下图：
最后，搭建一套北极星指标监测体系。
监测客户运营情况以及产品场景建设的好坏，并持续优化运营和产品动作（具体怎么搭建监测体系，以后再展开讲）。
剩下的事情，就是通过前三个环节【获取有效信息】、【准确翻译信息】、【产品落地实现】，不断积累和完善方案库。并通过北极星监测指标体系，不断修正客户运营思路及产品优化方向。
五、结语
我一直希望能通过一套科学的机制，将数据产品从0-1的建设变得不那么痛苦，最近结合3年来的实践终于把思路梳理清楚并在一家出海数字化公司跑通了。
这套机制并不能保证百分百不踩坑，也不能保证产品建设百分百成功，但我想，一定程度上是能避掉一些坑，尽量少走弯路，提升成功的概率的（毕竟互联网行业的耐心有限不是吗）。
值得一提的是，文中提到的方法论流程较复杂，不必完全copy。
一般来说，团队能力越强，人员素质越高，流程越可以做一些简化，反之，如果单兵作战素质较差，则需要不断地拆解流程中的细节，以保障机制能顺利落地。我们都希望看到，能通过完善的机制保障团队的长治久安，不强依赖于某一个人，任何新人加入，也都可以很快地融入到整个体系中。很可惜，国内互联网公司大多团队并没有达到这个要求。
不过我相信，未来会慢慢变好。
本文由 @阿飞 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。