Hi，歡迎來到知果的知果日記。

---

關鍵詞：我的經歷、打造產品“九步法”

想寫這篇文章挺久了，但一直不知道從哪個角度切入去寫，感覺自己想表達地挺多，可因太零碎不夠體系，因此遲遲沒有動筆。

直到上次我在公眾號發表了“我對B端產品MVP的5點感悟與3點總結（實戰版）”一文后（下有鏈接，可直接點擊查看），收到了一些讀者的咨詢，以及一些讀者表達受益匪淺之事，讓我決定還是打算寫寫我從0-1打造B端產品的經歷與一些感悟。

我對B端產品MVP的5點感悟與3點總結（實戰版）

說來很奇妙，從我開始接觸B端，就一直與基建類、中臺類B端產品纏繞在一起。如知識圖譜、監控運維、大數據平臺、資源管理系統、LowCode、D2C、企業級基礎組件、企業級設計體系等，它們均是屬于底層形態的產品，而非業務應用側的產品。

通過與這些產品打交道，我逐漸建立起了自己的抽象思維能力——從復雜關系中抽取共性的能力。而對于這些共性的抽取、應用、迭代、再構建（如此往復循環），我也是樂此不疲。每當從繁雜中梳理出來線頭的時候，那種感覺別提有多高興與舒暢了。

當然，以上產品并非都我主導，一部分我以主設計師+半個產品經理的身份參與，另一部分我以產品經理的身份主導展開。不論是作為設計師，還是作為產品經理，我都在思考如何做出一款被客戶認可的產品，而不是一款自嗨的產品。記得前些日子有一位企業管理者和我聊起產品，他問我，說：“知果，我最近在思考一個問題，想聽聽你的意見？你認為一個好的B端產品，具備哪些特點？”我說：“第一，第二……”（你可以看下圖）

隨著經歷越多，我也越來越發現，大家都想要能從自己手中培養出一款好的產品，可「好」怎么理解，每個人卻不盡相同?！负谩巩a品要怎么來，大家也處于迷茫階段。對此，我也想趁今天的文章，對自己從0-1做B端產品的經歷進行簡單梳理（選擇一些我印象相對深刻的），與你進行簡單分享?；蛟S不和你想的完全一致，但期望能拋磚引玉，互相多多交流。

我已經有些記不得，到底自己是如何從一名純設計師慢慢進入產品經理行列的。我坐在自己的木椅子上，聽著窗外淅淅瀝瀝的雨聲，看著天花板一點點往前回憶。慢慢地，以往參與與負責過的B端產品逐漸在腦海中清晰，記得我以主設計師身份參與的第一個B端產品是運維監控平臺，直到現在，它還在穩穩地運行著，服務著包括招商證券這么大級別的客戶?，F在也有一個專門的產品與研發團隊，對其在進行迭代與運營。

很謝謝運維監控平臺，是它領我進了B端大門，讓我開始逐漸了解什么是B端，什么是B端產品。不過因為我參與設計運維監控平臺其實不算從0-1，因此，我將它跳過了。我的思緒定格在了知識圖譜系統。

知識圖譜系統算是我以主設計師+半個產品經理身份參與的系統，其讓我漸漸有了自己思考構建產品的意識。由于當時團隊人手緊缺，并且該領域較為新興（現在知識圖譜已經耳熟能詳），因此我被推上前線，承擔起兩個職責：一個是設計產品形態與信息架構，一個是設計產品界面交互與視覺風格。

對那時的我來說，我連知識圖譜是啥都不知道，更別說界面要怎么構建了，完全毫無頭緒。于是和產品團隊負責人高頻交流、分析競品、學習圖譜基礎知識，其實當時整個團隊都對知識譜圖不太了解，都在各自學習中，幾乎誰也不比誰更懂。但我們都互相打氣、加油、互相解答疑問。

后來，我以大約每兩天一版產品原型的迭代速度，通過“畫-評審-修改”的循環，在大約兩周內完成了最終方案的敲定，接著再開始進行交互設計與視覺設計。從知識圖譜項目中，我學習到了很多，總結起來有5點：

1.1、接手一個不懂的產品后，不要慌，先與產品總負責人溝通基本情況，再對業務進行學習和了解；

1.2、不要急急忙忙開始設計解決方案，而是要先搞清楚一些核心問題，比如產品解決什么問題、客戶是誰、他們會怎么使用產品等；

1.3、雖然主要身份是設計師，但想要將產品設計好，需要有意識思考設計以外的東西；

1.4、沒有比原型更好的表達想法與團隊共識的東西了，“快速繪制、快速評審、快速迭代”是產品設計的秘密武器；

1.5、直到現在，核心界面信息架構和交互依然沒變，團隊主要在技術上進行探索與深耕。所以我想，不要害怕一開始想不明白產品該如何設計，最怕想不清楚直接投入大量資源研發，這才令人頭疼。

先說說這款產品的現狀吧，目前已經正式投入運營與接入客戶使用，解決了很多企業想要快速構建系統的訴求。我問了創始人，他說現在正有條不紊地展開，雖然辛苦，但整體趨勢尚可。

好了，我說說這款產品當時我參與設計的情況吧。在我接手這款產品設計的時候，已經有了一些初步的原型，原本我的角色是根據原型進行交互優化與視覺設計。由于我的職業習慣，我通常先要將產品相關的七七八八搞清楚，捋順才會著手設計界面，因此，當我發現界面信息架構和流程不通暢時，我與創始人進行了溝通。之后他告訴我原型其實并不準確，我可以進行調整與優化。

好嘛，與是我往前再走了一步，我將該產品的整體情況進行了了解。我發現，這哪里是一個產品，這明明是一個生態，而且很多問題在之前給的原型上并沒有體現出來。在確定還有富余的時間可調整原型后，我主動以產品經理的身份對產品生態進行了梳理，并且與創始人一起明確了產品演進的步驟與節奏，逐步將LowCode梳理出來。

由于有了之前知識圖譜的經驗，我依然通過對原型數次評審與迭代來敲定最終的MVP，然后著手開始界面交互與視覺設計。這次項目，可以說是重構了我對B端產品的認識。并且我發現，在面對復雜問題時，我竟然不知道該如何切入去解決問題。也因為這次項目，我對產品的熱愛更深了，我喜歡琢磨產品，將它們當做有血有肉的人一樣去塑造和思考。由于此次項目的A計劃是一個生態，超越了我原來接觸的單一產品維度，因此可以說，學到了不少。如果要說有什么特別的感悟，我也總結了5點：

2.1、把做產品像培養孩子一樣對待，時刻思考合不合理，有沒有辦法可以做的更好，使盡全力出方案；

2.2、永遠不要將自己鎖定在某種身份，只要能把事情做好，就去嘗試和突破；

2.3、理清思路后，線框圖、低保證原型永遠是最有效的驗證方式，直到團隊內部明確最終可行的方案后，再著手開始高保真原型創作；

2.4、如果它是一個生態，那么需要把這個生態的方方面面一同搞清楚，而不是一上來就開始陷入細節設計，觀全局才能控細節。了解全局后，你了解點就更加容易了。

2.5、產品是誰用，他會怎么用，能解決他什么問題…也就是說客戶群體決定了產品的最終形態。

嚴格意義上來說，很多人并不認為這是一個產品，因為它與一般的B端產品完全不相同。而我卻不這么認為，在我眼里，任何為用戶提供價值的均可以稱為產品，一本書、一套付費課程、一個演唱會等，你會發現，它們的設計邏輯是相似的。

企業級一體化框架嚴格來說是一種基建型產品，其是為了解決不同B端產品在集成時具備一致體驗而誕生的。可能很多同學會覺得，這不很簡單，找個功能強大的框架抄一個就可以用了，可事實卻不是如此。

每個客戶都有自己的訴求，除了功能要滿足，在視覺層面也需要一些定制化（如位置、色彩、樣式等）。這個項目我是以產品經理+設計師的身份全程主導的，可以說，在這個項目上，我無法依賴任何人（所有人在此均沒有經驗），必須自己做出決策和推動落地。

以終為始，我進行倒推，完成客戶調研、定位問題、競品分析、原型設計與評審、風格定義與設計、推動研發落地與產品推廣。可以說，扎扎實實走完了產品建設與推廣的全流程。不得不說，我特別享受這個的過程：思考與解決問題。

這套框架目前已經落地幾十個產品，并且已經進入客戶現場，得到了客戶的驗證與認可。同時，我還將框架申請了專利。當然，在這套框架的設計與推廣中，我依然覺得還存在些許遺憾。譬如，由于經驗不足，一些情況我沒有提前考慮到，導致框架拓展性受限；再譬如，由于對前端實現方式不熟悉，有些研發要求沒有交代清楚；還有，在產品推廣前，我沒有意識到一些B端產品的歷史原因，導致推廣中受阻。等等，這些都需要在今后設計產品時優化與規避。我依然總結了5點感悟分享給你：

3.1、一個新的產品即便客戶認可，但若需要其付出較大的代價才能獲得的，那么他很有可能放棄；

3.2、不要默默告訴客戶你有了什么驚艷的神器，他們很可能覺得你瞎搞，應該在某些適當的時刻反復露一下臉；

3.3、完成一款產品的設計與研發，僅僅只是產品的開始，后面還有很長的路要走，包括驗證產品與市場的匹配度、提升客戶數、優化與強化產品競爭力等，真的是一堆事情；

3.4、假如你喜歡做產品，那么，做任何事情都可以采用做產品的方式去思考和執行。而不只是在接手一款擁有千萬級用戶的產品時才這么做；

3.5、自己思考一款產品如何做出來并推廣下去，獲得的感悟遠遠比別人手把手教你一步步該怎么做，來的深刻。

慢慢地，我開始學習獨自思考它們，然后再和小伙伴們、領導、客戶溝通，看看自己的想法有沒有什么需要修正和改進的。比如在自己近幾年負責的企業級設計體系上，其是一種在企業級層面提升數字產品界面體驗設計的能力。

我把產品中零碎的信息、功能、需求等當成是一串珍珠項鏈中的一顆顆珍珠，我思考如何將它們逐一串起來，成為一串用戶喜歡、并愿意付費購買的項鏈。

產品就如珍珠項鏈，產品經理就如打造珍珠項鏈的匠人。

不同的人群對珍珠項鏈的喜好是不同的，我們需要針對性的打造。

關于一些其他的B端產品設計感悟，我會在后續的公眾號文章中慢慢與你分享。

做B端也有很多年了，一直覺得自己還挺幸運，有機會和優秀的小伙伴們一起從0-1構建一些產品。一些是我作為主要角色參與的，一些是我作為負責人主導的，不論是哪種角色，我都力求盡量把每個環節做到位，防止產品推翻重來。

在這些年，我也總結出了一些從0-1做產品的方法，我將其稱為“九步法”（如下圖）。當然，我會根據不同的產品，略微對以下步驟做刪減或者調整。

第一步：找出問題

沒有問題的解決方案是不值得去做的。你想，如果問題和痛點都不存在，那這個產品為什么要做呢？因此，正如Ash Maurya Spark59創始人說過：“必須先確定手頭有沒有值得解決的問題，不能在沒有確定之前就花上數月甚至數年時間來推出解決方案。”

在我做D2C時，我就從自己目前擅長的領域出發，去找出需要解決的問題。我發現的這些問題一方面來自于我日常的觀察，另一方面來自于一些同事的反饋。

第二步：客戶調研

我們需要通過小范圍的目標客戶調研來明確問題是否真的存在，而不是自己臆想出來的。邀約一些客戶，對你發現的問題進行溝通，看看他們都是怎么想的。你會通過訪談發現一些新的問題點，當然也會被客戶否定你發現的一些問題（在他們看來并沒有那么重要）。

在我做D2C時，通過客戶訪談，就發現了一些我之前未曾考慮到的一些問題，這些問題對他們來說很重要。通常我隨身帶筆和紙，我在訪談中就隨手記錄關鍵詞，回去后進行整理。一些屬于我盲區的問題，我會帶給我的團隊小伙伴，一起來看。

第三步：梳理解決方案

當你發現你提出的問題，確實也是客戶目前頭疼的問題時，你就可以著手梳理解決方案了。如果有可能，你可以多梳理一些，去和客戶交流，哪些方案是他們認為不錯的，愿意在你開發出來后嘗試或者付費的。

在我做D2C時，我將解決方案大致畫了流程圖與線框圖（沒有交互細節），然后與客戶再次溝通，在他們大致認可后，我才開始著手第四步。

第四步：完成原型（MVP）

完成解決方案的原型時，我們要融入MVP思想，切不可一上來就想做個功能大而全的產品，這有可能翻船。

在我做D2C時，我對MVP運用的也不是很嫻熟，抓不住重點。但在設計D2C中，由于需要在一定時間內看到產品形態以及驗證其可行性，必須在僅有的人力條件下快速輸出產品，因此我就不停地思考與取舍，慢慢有了自己對MVP的認識。在原型中，盡可能去掉對當下階段來說不重要、不需要的需求。

我有一點影響比較深刻的是，即便我們知道目前是MVP階段，也不要隨意寫代碼，畢竟如果后期獲得市場認可，代碼要重新優化一遍，那是幾乎不可能的。所以在MVP階段，盡可能把代碼寫好。更多我對MVP的感悟，可以看這篇文章：我對B端產品MVP的5點感悟與3點總結（實戰版）

第五步：團隊評審

MVP原型完成后，我們要先進行團隊評審，切不可直接扔給設計師出視覺稿。通過幾輪評審和原型完善后，就可以進入第六步了。

在我做D2C時，原型評審分為組內和組外兩部分，組內是研發小組內部評審，組外是找了后期會使用該產品的客戶進行評審，這期間大家都提出了很寶貴的意見。我非常建議產品經理要經常進行原型研發前的評審，避免研發階段再提出原型不合理的問題，導致之前的時間浪費了。

有產品經理會問，每次開會，人人都成了批評家，實在不想評審（可以說是害怕）。其實我們不要把評審看的太恐怖，我們要把評審也看做是一次小型輕量的驗證會。最終做決策的人還是你，你可以最終決定哪些建議采納，哪些建議暫時收進建議池。

第六步：視覺設計

視覺設計就是視覺設計師要將原型進行美化，讓用戶用起來更舒服。

在我做D2C時，沒有過多在視覺上下功夫，主要運用了企業級設計規范來做，又快又省力。一些強業務部分，有針對性地輸出設計稿即可。

第七步：研發與測試

這個步驟我就不再多贅述了，就是研發按照設計稿還原，并完成前后端數據對接什么的，提交測試的過程。

該階段有一個點我覺得需要注意，就是研發過程中研發工程師忽然告訴你功能實現不了了，要么實現它需要繼續增加時間，這會打亂整個研發節奏。我當時也遇到了此情況。于是后面我每周五開會，確定下周需要研發的事項，然后在會議上讓研發工程師評估實現難度和方案，盡量在前期控制。對于一些非常重要的方案，我們會提前幾周開始準備和預研。

第八步：小范圍驗證產品與市場匹配度

完成MVP，就要推廣出去讓客戶使用了。我這里講了要小范圍，也是因為我之前吃過幾次虧，發現一下子大面積推出去會有兩個問題：第一，咨詢的客戶會一下子涌進來，而團隊現有能力及資源壓根接不住，導致亂套了，團隊一下子沒了方向；第二，客戶太多后，會導致對產品的評價各異，一旦出現一些負面評價，會導致團隊沒有精力處理，從而導致你會懷疑自己的產品是不是真的有問題。

因此，在我做D2C時，我是一個個客戶去聯系的，等用上了，我開始找第二個客戶，然后跟蹤使用反饋。小范圍先驗證，并且同步優化與更新產品的目標客群，逐步擴大客戶范圍。

第九步：迭代、擴張

要是你發現你的產品與市場是匹配的時候，那真的太好了。你就可以進入第二階段了，也就是根據客戶與市場的需求，不斷迭代你的產品，然后逐步擴張你的客戶群體。

這里我們要注意，切記不要在迭代的時候，就毫無顧慮地在產品中瘋狂添加功能，來彌補MVP階段克制的心理。Ash Maurya Spark59創始人說過：“不要預先制作產品或者提供服務，等客戶要求了再做。你應該把八成的精力都用來改進現有功能，而不是增加新功能。”

D2C小結：

由于D2C是一款內部基建類產品，因此我順帶帶著團隊參加了比賽，最終從數款產品中沖出重圍，獲得了優勝獎（即一等獎）。不論是評委還是現場觀眾，都對此款產品給出了好評。

很幸運，自己不僅參與過小模塊、小功能的精細化設計，也參與過大產品的整體設計與思考。這兩種狀態我都很享受，不過最最最享受的還是從0-1做產品。

但到目前，因為各種原因，我認為還有很多我沒有接觸到、以及做深的，這些都是推動我不斷向前的力量。期待在學習、思考與實踐中，不斷迭代自己的認知，然后分享給你們。

期望我的經歷與打造產品“九步法”能給你帶去一些啟發。

本文來自微信公眾號“知果日記”（ID：gh_690a8b6479cb），36氪經授權發布。