引言
對于B端產品經理而言，從0～1的產品設計考驗一個人的規劃能力、統籌能力與產品設計能力，與日常產品迭代的方法流程具備差異，如何進行從0～1的產品設計？我針對自身經驗梳理總結，希望下面的文章能夠對大家有一些思路方法上的幫助。
我們可以從戰略層、管理層、業務層、產品層如此四個緯度來思考。
01 戰略層
概述：戰略層思考的核心，在于理解該項目的始發點以及遠景規劃。
可以從以下幾個方面來進行項目理解：
- 這個項目為什么啟動？是利潤需要/風控需要/戰略需要？
- 這個項目為什么現在啟動？
- 這個項目關鍵目標是什么？公司要求的時間周期是什么？
- 這個項目公司配備了什么資源？這些資源范圍上充足還是遺漏？資源規模上充沛還是欠缺？
02 管理層（戰術層）
概述：管理層可以理解為項目管理層，在于對于項目目標的OKR方法拆解，針對于項目目標，設立關鍵路徑，并制定里程碑計劃。
戰術層是項目成功的關鍵，因為該層面進行如同一場戰爭的指揮部，達到指揮調度全場戰爭的作用。
03 業務層（戰役層）
概述：業務層指一線執行人員的階層，他們是這場戰爭的實際執行人員，其中很大一部分角色也是我們的產品的真實用戶，他們是與我們的產品功能設計息息相關的一群人。
對于此場景下的從0～1產品設計，業務層的人員是我們需求收集的來源，也是產品使用效果反饋的出口。但需要注意的是，我們以及不能僅根據業務層人員提出的需求進行產品設計，我們的判斷要來自于戰略、戰術、戰役三方面評估后的結果。
04 產品層（產品設計能力的體現）
對于從0～1的產品設計，互聯網上有很多資料將步驟講解的很清晰，但對于沒有實戰過的同學，往往需要“死記硬背”才能記住冗長的產品設計環節。本文的核心是通過形象的比喻，帶領同學們通過遷移聯想的形式，理解從0～1的產品設計流程。
首先，我們通過現狀-目標法，來理清楚我們的思路。
- 現狀：沒有一套支持新項目的系統，新項目無法運轉。
- 目標：搭建一套能支持新項目運轉的系統，系統要在最小成本的基礎上滿足核心功能完整性。
Step1：我們需要調研業務，了解業務涉及的各個角色，以及業務流程圖。
我將業務流程圖分為以下幾種：業務主流程、分支流程、逆向流程、兜底流程。各個流程定義如下：
（1）業務主流程：指業務的核心流程，該流程的穩定運行是項目盈利的關鍵。對于履約性業務，核心流程可能是訂單履約流程；對于平臺性業務，核心流程是供給端商品上架。
對于核心主流程，識別方法，我認為可以通過以下幾點：
- 該流程若流暢運行，是否對項目的北極星指標有貢獻？
- 該流程若出現異常，項目的北極星指標是否一定無法達成？
- 該流程若不存在，其他流程是否沒有存在的必要？
對于滿足以上3點的流程，我們可以考慮將其定義為業務主流程
（2）分支流程：指除主流程外有對應合理的業務場景的正向流程。分支流程不可忽視，因為業務場景的多樣性，代表了分支流程出現的概率。舉個例子：大眾用戶針對一個支付產品，綁定銀行卡后換綁幾率很小，但這就意味著我們可以不為用戶提供換綁功能了嗎？有些流程存在的必要，不是為了用戶時時刻刻能用，而是為了用戶想用時，就能隨時可用。
（3）逆向流程：指正向流程對應的反向流程。舉個例子，用戶按照正向流程操作產品時，難免有操作錯誤的步驟，這時產品提供操作撤回功能。在電商業務下，用戶的售后流程對于購貨來說，就屬于一個逆向流程。
（4）兜底流程：指當其他流程出現異常時，對于核心場景，系統自動化的問題補救流程，舉例：對于獎金設置系統，當用戶針對某一個訂單忘記設置履約獎勵金額時，我們的系統可以通過定期巡檢的形式，發送消息通知，提醒用戶及時補充。
Step2：針對業務流程，梳理系統模塊
每一個業務流程，都需要系統能力的支持。在這部分，產品經理可以進行頭腦風暴，將最全的產品模塊列出，先不區分產品建設優先級，能想出多少就列出多少。
對于產品模塊我們要達到以下幾個標準：
- 盡枚舉，不重不漏
- 合理耦合
為了達到“窮盡枚舉，不重不漏”的標準，我們可以采用業務流程-系統能力對應發，來督導我們思考的嚴謹性。舉個例子，下圖中，將業務流程先畫出，針對每一個環節節點以及環節關聯，思考需要的系統能力，依次列出。
這樣做有兩個好處：
- 好處1：能讓我們的輸出的功能模塊有嚴格的業務流程對應關系，對于日后功能模塊優先級的取舍有可以追溯判斷依據；
- 好處2：剛才我們已經判斷了各個業務流程的優先級，一般與業務主流程對應的系統能力往往更加重要，要優先建設；這對于我們后續版本規劃也提供了參考思路。
除此之外，系統模塊梳理環節，我們還要追求合理解耦，即：
首先，我們拆解出的模塊，可粗可細，但要保證在同一個層次，比如拆單、合單是在一個層次；司機管理、商品管理是在同一個層次；第二點，我們拆解出的模塊，要合理合并；比如訂拆單、合單合并在訂單操作類；訂單修改、訂單刪除合并在訂單管理類。
Step3：根據功能模塊，梳理產品架構
剛才梳理出了很多的功能模塊，下一步我們需要對功能模塊進行歸類整理，并組成產品架構，如下圖。系統架構的畫法沒有嚴格標準，但是具備主旨思想：首先自下而上，應從底層到表層的邏輯表達；可以分為基礎設施層、系統支持層、業務應用層、門戶層。
Step4：版本分期
在梳理完系統架構后，我們下一步是對系統進行版本分期，對于從0～1的產品，為了快速迭代進行可用性驗證，企業會選擇MVP的原則。采用MVP的原則好處是可以用最小的研發成本進行產品可行性驗證，根據驗證結果決定下一步功能走向以及資源投入，在節約成本的同時即時糾錯，提升產品成功率。
產品規劃的第一版本需要實現哪些功能，筆者認為可以從以下幾個角度考慮：
- 產品主流程上涉及哪些功能？這些功能中優先級排列是怎樣的？
- 除了主流程功能外，分支流程上涉及哪些功能？這些功能優先級排列是怎樣的？
針對于高優先級的功能，我們可以選擇第一批版本迭代；針對于低優先級但是影響第一版產品功能的需求，我們可以先通過開發側代碼寫死的方式臨時支持，在后續版本迭代中，將其作為頁面配置化。
Step5：輸出產品規劃文檔，與業務方達成一致
下面一步，是將我們的產品規劃輸出成文檔形式，以會議形式向業務方反講。我們在同步結論的同時，也要講述背后思考的邏輯，這一步是通過講述給業務方，使其根據我們的邏輯推導判斷是否有不符合業務實情的方面，讓業務方作為我們的“軍師”進一步的糾錯。除此之外，各個版本的時間規劃也需要向業務方講清楚。在會議達成共識后，形成文字佐證，便于后續有反水時，留下論述依據。
Step6：針對版本分期結果，依次產品交付
最后，就是按照版本分期結果進行產品交付了，至此，我們講一個系統的搭建拆分成了各類更細致的需求，產品經理可以按照日常需求自承接至交付的完整流程進行產品迭代，在此不再贅述。需要注意的是，在日常迭代中，我們難免會發現當初系統架構或版本規劃不合理的地方；第一版的規劃不可能是完美無缺的，我們可以根據實際情況靈活調整，達到日后兼容。
05 結語
總結來看，從0～1的產品設計，與日常需求不同點在于，沒有了系統架構，沒有了模塊規劃，需要產品經理從頭開始進行系統規劃；但相同點在于，一旦系統規劃確定后，后續產品交付的工作流是一致的。
產品經理的工作自始至終伴隨著“分析”和“拆解”，無論是從0～1的產品規劃，還是小的優化迭代，都是對問題的理解、分析、拆解、依次解決這些步驟，底層思維是一樣的。或許有些工作是第一次經歷，但背后的底層思維我們已經磨練了千遍萬遍，不需要恐懼。
作者：Vicky 來源：人人都是產品經理
本站文章收集整理于網絡，原文出處：人人都是產品經理 ，本站僅提供信息存儲空間服務。如若轉載，請注明出處。
