數字化轉型諮詢顧問的B端產品覆盤

在做產品之前，我做過一段時間的諮詢顧問，參與了一個比較典型的諮詢項目，幫一家傳統制造業龍頭做數字化轉型諮詢。

整個項目是端到端的幫助客户梳理各環節流程。在幫助客户梳理好流程之後，形成產品需求書，指導客户招標發包，幫助客户篩選供應商，並且全程參與發包之後的項目實施。

對於產品經理來説，設計產品，和研發溝通，確保產品按時按需落地，這幾件事情會佔到產品經理日常工作的80%以上的時間。而需求在商業上的來源，可能很多小夥伴會接觸的少一些。

而諮詢顧問的經歷，可以覆蓋住產品經理工作中不涉足的部分，以一個第三方視角看待甲方客户和產品經理所在的乙方公司。

回過頭覆盤當時的諮詢項目，對如今的產品工作也有很多啓發。今天想從諮詢顧問的視角覆盤一下，一個產品從構思到落地，再到變現的整個過程和思考。

01 正確理解需求才是好的起跑開始

對於一個大型的企業，在C端紅利逐漸吃盡的時代，在大家開始琢磨增長，開始注重留存的後互聯網時期，提質增效降本減存又一次的出現在企業老闆的面前。其實從早幾年，我們就能感受的到，國內的一部分企業需要開始精耕細作了。

當企業決定自我革命，開始想要在內部用數字工具管理自己的數字資產的時候，B端的機會悄悄到來，而需求也在其中。

B端的需求來源會有很多，可能是老闆拍腦袋，可能是產品經理從競品中有所體悟，也可能是外在商業環境的壓力。我們今天先不聊公司內部的需求，從B端客户的視角看看，需求是怎麼產生的。

在B端的用户世界裏，用户是知道他們想要的是什麼的，但是他們知道的是最終狀態，不知道的是實現方法，所以往往他們表達不好他們的需求。這種情況下，往往會涉及到無限的需求變更。產品經理需要有能力幫客户理清他們的根本訴求，設計對應的產品。

在諮詢項目期間，我們幫用户梳理他們企業內部可能涉及到的數字化產品，大家可以參考下面這張圖。

企業內部數字化產品示意圖

可以看到在這張圖裏，有非常多的B端產品線。當然成熟一點的企業，在用B端產品的時候，ERP、CRM這些肯定用的比較早；這也是當下用友、金蝶，salesforce和銷售易、紛享銷客這類產品為什麼目前佔據着頭部地位。

在深入企業調研的過程中，我們為客户梳理了業務流程。梳理流程在B端非常重要，正是因為不同企業流程的不同，才會導致B端產品標準化困難。

而往往用户身在其中，可能知道結果有問題，但是不能找到問題在哪裏。

比如倉庫裏的庫存週轉天數高，做過WMS產品的人一定懂這個指標，庫存週轉天數高就説明倉庫裏經常積壓，週轉時間長，造成了大量了倉儲成本。

在供應鏈這塊，行業有幾個龍頭：寶潔、GE、蘋果。近幾年蘋果在失去了設計之神喬布斯之後，卻迎來了供應鏈之神庫克。

今年5.2號巴菲特股東大會，巴菲特老爺子公開表示雖然庫克創意比不上喬布斯，但卻是最棒的管理人。

最近蘋果發了一季報，庫存週轉天數指標長期在10天以內：

蘋果一季報（圖源：同花順）

但是大部分廠商的週轉天數高居不下，指標是直觀現象的結果反饋，但是倉庫管理員可能並不知道是哪個環節出了問題。當用户發現問題但是不知道如何解決的時候，他的業務改進需求書就肯定寫不明白，業務改進需求書寫不明白，在引入解決方案的供應商的時候就會面臨很多阻礙。

我們深度參與了指導用户梳理流程，幫用户一起起草業務改進需求書，形成了後期招標書的初稿。而後期招標書，其實基本就是企業裏的需求源頭。

02 商業競標就是一場產品路演

需求以招標書的形態出現了，那麼自然也會有供應商打標的環節，在整個B端產品的商業生命週期中，B端的產品經理在這個階段正式介入需求。

這個環節流程是：

1. 入選的各個供應商先研讀招標書；
2. 基於自家產品輸出解決方案；
3. 帶着自家的方案在甲方現場首輪私下溝通需求內容；
4. 正式供應商評審會；
5. 發包會，確定供應商。

這個環節裏，供應商帶着方案去甲方溝通，本質就是一個路演環節，和創業者見投資人類似，只是一個拿着商業計劃書（BP）去向投資人要錢，一個是帶着方案，向關鍵客户（KA）要錢。

路演環節的關鍵在於，準確的理解用户的需求，並能針對性的輸出產品功能cover住用户需求。這裏非常考驗產品經理和售前對需求的理解能力，以及產品經理將需求轉換成功能的抽象能力。

當然B端發包會，水也是深似海，產品在功能上的硬實力和銷售在客情關係上的軟實力需要齊頭並進。

銷售工作沒做到位，項目經理或產品經理熬夜趕出的方案真的就收效甚微了，這樣也非常可惜，還有一些標的就是需要銷售提前識別是否自己競標就是陪標去的這種情況。

03 產品化是B端利器

產品開發是產品經理最熟悉的環節。這裏想要説的是，項目標準化的問題；這個也取決於公司的性質，你是在一家產品型公司做產品經理，還是在一家解決方案型公司做產品經理。通常在解決方案型公司，產品經理和項目經理是一個人。

解決方案型公司輸出的產品，是完全為需求定製化開發的產品，這種和用户的訴求往往能更好地匹配；但是付出大量的人天，得到的是產品的不可複用。

產品型的公司會輸出一個相對標準的產品，加上少量的定製化開發，快速的迭代響應用户的需求，這種方式當然對自己公司來説最有利，但是往往和客户的需求匹配的沒那麼好。

兩類公司對比

在企業諮詢服務裏，我們幫客户規劃很多數字化的B端項目，參與項目實施的過程中，看了很多家中標企業的工作模式，真的感受到解決方案型公司會過的比較累。他們做過很多項目，對行業會有比較深的積累，但在沒有形成產品之前，每次接標都要定製化開發，按項目人天賺錢。

而一旦完成了產品化的公司，中標之後做起來進展就非常快，但是也確實會無法滿足一些客户的需求。

產品化本身確實非常困難，B端的流程複雜，行業複雜，關鍵角色的偏好多元等等。這些都給項目產品化帶來非常大的挑戰。

但是，可以看到的是，很多公司是一步一步從項目中，形成了自己的組織過程資產，並開發出了相對標準化的產品，以此去更好地應對不同的客户。

04 在驗收階段不要放棄學習的機會

通常B端產品的交付是分階段的，比如完成了設計部分需要甲方驗收一下設計風格，完成了軟件產品功能部分，需要甲方驗收一下產品功能；而每一階段的驗收，對應的是每一階段的款項。畢竟一直墊錢做生意，很多公司都吃不消。

分階段交付是保護雙方的一種方式，可以有助於雙方及時糾偏，對待突發的變更情況，也可以及時的響應。

然而真正到了項目結尾，B端項目的最終驗收一般來説並不容易，所以會有很多回款困難的現象。

客户投入了一大筆錢，創新性地想要在數字化轉型上向前邁一步，但是也很忐忑這筆錢花得有沒有價值。客户的尾款付掉，如果產品使用的不好，客户企業裏主導這個產品採購的負責人會有很大壓力，所以驗收往往並沒有那麼容易。

作為B端產品經理，甚至可能會在最終驗收的時候，突然收到用户很多無理的需求。

面對這些需求，我的想法是：

1. 讓商務團隊出馬，根據項目邊界和客户討論。
2. 弄清客户不滿意的根本原因，安撫化解客户的焦慮。
3. 努力積極的收集用户的需求。

B端產品拿到一線用户需求的難度是遠大於C端的，所以在B端企業裏馬太效應也是很明顯。有更多的項目，就有更多的反饋，就有更多的機會去調整產品，而一直沒有客户，甚至收集不到客户的真實需求，產品就一直得不到驗證。

通常，到了項目最終驗收的階段，很多公司不會再投入過多人力去一個一個滿足用户所有的需求了。這個階段，商務也會介入去推動項目結束。

然而，在整個項目實施的過程中，即使到了要收尾驗收交付的時候，都要一直盡力的收集客户的需求，即使並不能全部滿足。我們是可以利用用户的需求，為自己內部產品的功能設計添磚加瓦的。

一線用户的需求本身是有價值的，當然也需要產品經理透過這個需求，看到需求背後本質的核心訴求，因為用户是永遠沒辦法準確表達的。

05 最後

B端產品，還是很多依賴項目存在的。有一次和某位阿里的高P交流的時候知道，即使在阿里雲、騰訊雲這些大廠的內部，也會面臨很多項目產品化的問題。

企業數字化轉型裏會提到，提質、增效、降本、減存。感覺已經是口號式的目標了。然而你會發現沒有一套打法是完完全全可以打穿一個行業，甚至僅打穿一個企業的。

B端的複雜在於業務複雜和流程複雜，差異化太大。一套標準的增效降本，換了個公司就不好用了，甚至同公司換個部門就不好用了。

這也是行業裏説的產品化，標準化的價值。

我想，需要B端產品多思考和多覆盤，從項目裏吸收更多的經驗，抽象出不同企業共性的部分，找到一些核心流程進行產品化，同時加以部分定製化開發工作，進而形成自己的護城河。

本文由 @格林不童話 原創發佈於人人都是產品經理。未經許可，禁止轉載。

題圖來自Unsplash，基於CC0協議