編輯導語：各行業產品經理在經歷從0到1的項目時，需要的不只是個人的基本能力以及經驗，更多的需要產品經理的強大的領導能力，帶領團隊的協作，實現從0到1的過程；本文作者分享了關于產品新人如何做到從0到1的過程，我們一起來看一下。

筆者有過完整的幾次C端產品的0到1經驗，對c端產品的0-1總結出了不少的經驗。

同時，筆者也見識過不少產品經理在一開始就因為錯誤的選擇方向，可能是市場調研環節沒有挖掘出用戶的真實需求，亦可能是老板的想法本身就有偏差確沒有進行過市場驗證就按照老板的想法開發產品，而導致了產品的無限延期；最后迫于成本壓力，以拙劣的產品上市最終失敗。

筆者通過自身經驗的總結，及請教了不少同行業的朋友與大佬，總結了這么一篇干貨內容希望與您一起分享。

一、黃金圈法則

筆者認為，產品經理想要最大程度的避免產品在戰略層上的錯誤定位，必須要學會并運用黃金圈法則。

筆者所接觸過的產品經理在產品設計上的思維都與黃金圈法則相悖，因此很容易出現抓不住用戶真實需求的情況；即使最終的產品看著非常像樣，卻不被市場所接受。

我們在打造一個產品時，應由WHY（戰略層：確定最終產品所要達到的目的，企業的愿景）到HOW（范圍層，結構層：如何執行，怎樣設計，怎樣的流程）再到WHAT（框架層，表現層：輸出的內容，驗證和管理）。

二、戰略層

1. 開始階段：產生idear

產品的往往是由一個Idear開始的，它可能是你的BOSS或者公司的最上層管理層突然發掘某塊市場具有較大的市場潛力而產生的idear。

這一類人往往有對市場機會有更敏銳的嗅覺，但市場機會轉瞬即逝，任何人都不可能有十足的把握確定某一市場一定有待挖掘的潛力；因此我們產品人要做的便是驗證產品研發投入市場的可行性，通過各大數據網站，或者企業內部已有的相關調研數據，研究目標市場的容量及競爭力水平；同時還需要了解目標用戶群的容量、消費水平；分析頭部競品及相似度較高的競品；該市場的現有商業模式。

產品六要素：

在上述任務全部完成后，整理形成《產品六要素》：①產品定位、②產品目標、③需求背景、④用戶群體、⑤產品形態、⑥使用場景；綜合分析產品的可行性。

產品經理在撰寫產品六要素時應注意結合具體的數據：數據真實有效更能打動Boss或者Leader，產品的目標則最好分為用戶角度、市場角度和公司角度（商業）。

競品分析：

如果產品的可行性較高，下一步便是深度分析競品，形成規范化的《競品分析》，因為《競品分析》是研究一個市場和一類產品最有效的途徑。

了解對手的產品能達到知己知彼、百戰不殆的目的，而且分析競品也能為產品的設計提供建設性的意見，學習競品的精華能有效降低獲客成本，規避競品的糟粕則能有效的降低市場風險，同時還能根據對手的核心功能挖掘用戶的真實需求。

我們可以根據目標用戶、使用場景、用戶需求的趨同性將競品劃分為直接競品（同用戶、同場景、同需求），間接競品（目標用戶、場景、需求有一個不同），潛在競品（目標用戶、場景、需求不盡相同 ?但借鑒性強）。

在競品分析時，產品人要善于找茬，發現競品不擅長的維度/領域，降維打擊；分析自身的劣勢，提升自己的短板，升維思考；最后形成規范化的《競品分析》，留存備份。

注意事項：

• 競品分析時應站在中立視角分析雙方的優劣勢，切勿主觀評價。
• 聯系用戶的使用實際，結合場景，最好以全局的視角分析。
• 確保分析時產品都處于最新的版本。
• 所有的介紹都要有歸納總結或者說結論分析。
• 分析一定要以準確的數據作為支撐。
• 競品分析不是只研究競品，而是分析敵我雙方的差異性。

BRD：商業需求文檔

產品的開端一定要分析產品是否具有盈利性，或者是否具有長期盈利性，在未來的某一個時段實現盈利。

盡管產品處于未開發前的階段，產品團隊并不能撰寫出有效性較高的商業文檔，但boss或者投資人只有看到完整的商業報告才會評估確定產品是否值得投入成本進行開發。

對于不同類型的匯報對象，我們需要突出商業報告中不同的核心要點。對于管理層級，我們需要給出產品的投資價值，市場趨勢，和可能需要面臨的風險（產品的投入總成本及回收周期分析）；對于研發團隊，我們需要給出產品的主要價值，核心功能的方向；對于CFO，我們則要突出產品的研發經費。

總的來說，寫商業需求文檔的目的是為了說服團隊，得到人員、資源、資本的支持。

2. 匯報階段

第一階段的匯報將會決定產品是否投入開發，產品經理通過內部郵件的方式，將第一階段形成的所有文件傳達給開發團隊及上層管理層，確定會議時間、地點及匯報的主題；在此之前需要對之前整理的文檔內容進行更新（市場的變化轉瞬即逝）。

產品經理在匯報時應注意自己語調語氣，結合整理的數據，清晰果斷的發表自己的探索結果，注意細節內容的闡述；記錄匯報時討論出的問題及解決方案。產品開發通過后，第一時間制定甘特圖。

收集需求：

因為產品設計的核心邏輯就是以用戶為中心，圍繞用戶進行產品設計，所以在匯報完成后，就可以著手收集目標用戶的需求和問題了。

首先，我們要知道，用戶的需求是隱性的、模糊的、多變的；因此我們在收集用戶需求時，盡可能的保證用戶反饋的主觀性，不可通過問卷設計及訪談主題誤導用戶。

此外，我們對于收集來的調研數據需要進行深度分析，數據分析方法有：聚合分析，相關性分析，回歸分析，這里我就不一一列舉了。

我們的需求來源可以是產品團隊的想法（盡管產品經理并不能準確的抓住用戶的實際需求，但不少產品經理都具備挖掘用戶潛在需求的能力），也可能來自競品的功能設計，在后期的需求評審會中，往往也能得出不錯的點子。

在此，也為大家推薦幾種獲取需求的方法：

• 行業調研的分析報告，較為專業的行業報告具有指導意義。
• 業內專家與資深專業人士，這個時代是知識付費的時代，行業領先者往往具有更長遠的眼光，對市場的分析更加準確。
• 定性研究—用戶訪談，可以是焦點訪談、電話訪談、一對一訪談或者街頭狙擊訪談。
• 定量研究—用戶問卷，調研問卷的數量不應太多，避免影響用戶的主觀性。

三、范圍層、結構層

1. 用戶需求（問題）分析階段

當我們收集到足夠多的用戶需求后，我們就形成了一個需求池，這其中部分需求是假需求（即用戶自以為需要卻并非實際所需要的），還有部分需求不符合企業的價值或者說資源不匹配（可行性、盈利性、技術水平），因此我們需要對收集到的問題進行分析，提取需求，將用戶需求變為產品需求。我們對于需求的分析核心點在于將用戶需求轉化為可執行的產品需求的過程，它是產品設計、迭代的主要依據。

我們需要建立起用戶思維，即以用戶為中心去思考問題，了解目標用戶在何種場景會去怎么使用產品或者使用的過程是怎樣的，之后再總結用戶使用產品時會出現什么問題，提出最合理的解決方案并進一步驗證。在驗證需求時最好結合數據，通過頻數分析和交叉分析得出結論。最后整理出需求清單和功能清單（根據問題得出解決的功能設計），必要的功能設計可以優先設計用戶使用時的流程圖。并對所有確定要開發的功能進行梳理并輸出結構圖。

2. 需求評審階段

盡管產品團隊已經層層篩選，得出了產品的功能清單，但最終開發的產品還需要財務、開發團隊、上層BOSS的支持；因此，產品團隊必須第一時間確定需求評審會議的時間，將之前所有整理好的文檔信息和會議議程通過郵件的方式發布給公司的其他團隊，前期的準備必須要完美，規定好產品原則（確定產品設計的方向性，這一點必須統一，不然將大大降低會議的效率）；確定好參會人員，確定以何種形式記錄，需求討論的關鍵核心點。

在需求評議時，產品經理需要盡快的切入主題，調動大家的情緒（可以提前確定討論的方法：頭腦風暴和六頂帽子討論法）。

在進入正題后，介紹的優先級：項目背景，介紹本次主題的產品，產品的結構圖，流程圖，需求清單，原型圖（如果是敏捷開發，則可以優先進入原型圖開發），PRD文檔講解；最后記錄提問環節的問題及討論出的解決方案。

評審結束后，及時輸出更新后的BRD/MRD、PRD、流程圖、頁面清單、結構圖、原型圖等并整理會議內容通過郵件形式發給相關團隊；將達成的共識、待修改的地方、待解決的部分一一羅列，整理出反饋時間表；將任務的完成日期落實清楚并確定相關負責人，以及后續的評審日期的確定。

會議結束后的應保持長期跟蹤，推進產品的功能開發。

我們在整理最后得出的需求時，可以參考馬斯洛需求層次和KANO模型對需求的優先級進行排序，以此作為產品迭代路徑的參考。

四、框架層

1. 原型制作階段

在上述所有的工作完成后，便可以真正的開始原型圖的制作了。

筆者建議團隊或者企業最好能形成規范化的設計原則（統一的設計方法論），產品原則（產品的優先價值觀），企業價值（企業價值能讓團隊的目標趨于一致，減少摩擦）。

原型的交互設計一定要以用戶為中心，筆者見過不少產品經理在原型的交互設計上并不按常理出牌（這與不少企業的產品經理多為企業內部的開發人員有關），好的產品經理必須要分析產品的功能結構和用戶使用體驗，以此為基礎進行產品設計將大大改善用戶的粘性也有利于企業盈利。

設計的原則基本點：所有的APP頁面分兩種狀態，即初始狀態（初始頁面），變化后的狀態（隱藏頁面）；在交互說明中，不需要產品經理對跳轉頁面做具體的詳述，應著重關注于產品的隱藏頁面，下拉頁面、選項彈框等。

3個細分原則：

• 按鈕、圖標等模塊、操作以后的變化（可設置全局規則與頁面規則進行統一闡述，避免重復說明導致頁面雜亂，說清楚頁面變化的規則和邏輯有利于提升與UI、程序員間的工作交流效率）。
• 該頁面的文字顯示、時間顯示、刷新等頁面規則（應注意網絡延遲等情況制定刷新規則等，可將其詳細寫在全局規則頁面）。
• 操作后出現錯誤提醒（彈窗提醒），發現越多的異常流程將大大提升用戶的使用體驗。

此外，我們還應注意：

① 少就是多，分清功能的優先級，越重要的功能應詳細描述其交互規則及操作方法；學會做減法（減少約定俗成的說明，如：跳轉鍵等）詳略得當才能讓UI更清楚重點，讓程序員更能理解頁面的規則邏輯。

② 文字格式可直接表現在展示的原型內（注意格式規范，以免誤導UI設計師做出錯誤的設計，最終挨打）。

③ 頁面原型中的布局應規范，不要求具體到多少尺寸，大致能使UI設計師明白頁面設計的基本布局，布局以美觀簡潔為主，清晰的使用戶了解重要功能，提升用戶的使用體驗。

④ 設計的行為習慣應與企業的風格相協調，了解程序員、UI設計師的喜好作為設計交互的風格（如：布局風格、價格顯示格式、文字顯示格式等）。

⑤ 合理運用和設計全局規則頁面、頁面規則、頁面權限、使用場景，提升制作交互說明的效率；簡約明了為宗旨。

⑥ 多種場景可以用表格的形式進行描述。

2. 原型評審會議階段

原型評審時主要是對于原型設計的整體布局，功能設計的細節處理進行再一輪的頭腦風暴；此外，產品經理還需要結合BRD進行演講（此時的BRD較為詳實，效度較高），BRD涉及到市場、用戶、競品的分析，還包含了對于產品迭代、產品運營、產品的商業性的深度分析。即產品的長遠發展及競爭力水平的全方位分析。

產品的最終目標是實現企業的盈利性，所以在原型評審會議時應注重對于產品的盈利模式、玩法的深度討論，優化產品的盈利水平和可持續盈利能力；此外對于產品開發的成本還需要進一步的優化，對于產品的運營投入和成本可以試著在會議前做一些局部的測試，分析哪一類的運營模式或者渠道更具性價比，達到產品快速獲客和低成本獲客的目的。

在評審會議結束后，更新產品的原型設計，并將最終得出的所有文檔發布給相關團隊，開發團隊以此為基礎進行產品的開發。

產品經理應注重1-N的管理及風險管控，及時與開發團隊討論產品的設計；同時著手進入產品迭代的計劃，產品上線后短期內需要快速多次的微迭代。

五、總結

以上便是我對C端產品的0-1的總結，表現層并沒有放入在0-1的過程中是因為產品經理在表現層中的作用并不突出。

總的來說產品經理在產品開發過程中需要多結合真實的數據，并及時與其他相關團隊進行評審討論；及時更新產品文檔，了解市場的最新動向；最后還需要加強對各個子任務的跟蹤，0到1只是開始，更重要的在于1到N的過程。

本文由@曼巴PM 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。