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步順當完成，第四步就是一個逐步積累的過程，沒有什么技巧可言。除此之外，比較依靠運營講方案/培訓的力量（我們以后再講怎么組織和做好一場客戶培訓）。

以上簡潔來說，就是向不同的客戶推舉共性化的解決方案內容（想想抖音勝利的關鍵就明白了）。

首先，我們要明確推廣的目標客戶。

目標客戶就是訪談過程提出此場景的一類客戶。

客戶的