在産品的落地建設過程中，業務人員會需要思考一個問題，即如何彌合業務需求與産品實作之間的裂縫與斷層，讓産品更加業務化、場景化，同時也讓使用者可以清晰地看見産品價值所在。本篇文章裡，作者便總結了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 協定。
該文觀點僅代表作者本人，人人都是産品經理平台僅提供資訊存儲空間服務。