實戰總結:如何將需求轉化為PRD?

本文較長，是工作實戰經驗與一些理論的結合。文章分為3部分：需求流程、需求流程名詞解釋、需求流程詳解。原本還想寫一個實際案例，但一方面字數已然很多，另一方面是本文介紹已相當詳細，詳解部分也舉了一些例子，實際案例略顯多餘，故免去不表。希望本文對你能有所幫助，當然我相信一定會的。

如何將需求轉化為PRD？

需求是產品的源頭，是產品經理天天接觸的概念，就像下圖這樣（之前看過的一個統計圖）。

將需求轉化為PRD，則是其中的關鍵，因為這是將產品從概念落實為實際的關鍵，下圖「畫原型」這一項為46.7%，也正是如此。所以，將需求轉化為PRD，是產品人必須掌握且反覆打磨的基本功。

1.需求流程

不囉嗦，一圖勝千言。

2.極簡名詞解釋

• 需求收集：通過各種方法儘量多地收集目標用戶的需求。
• 需求分析：明確用戶的本質需求，即挖掘表面需求背後更深層次的需求。
• 需求決策：根據用戶需求本質與產品目標，確定產品方向與核心需求。
• 需求擴展：基於產品方向與核心需求，大量尋找相關需求。
• 需求篩選：確定需求的優先級，明確此版本需要做的需求。
• 需求設計：將需求轉化為PRD。
• 需求開發：開發按照PRD開發，測試按照PRD測試。
• 需求上線：將完整的產品上線。

注意：上圖是一個循環，因為產品往往需要迭代。如果不需要迭代了，就說明產品已經狗die。哈哈，產品狗die……

3.詳細分解

3.1 需求收集

需求收集有很多方法，目的是收集儘量多用戶需求。將這些需求分門別類，可以歸納為這3類方法：直接從用戶處獲取、查閱資料獲取、通過自己的思考挖掘。

3.1.1 直接從用戶處獲取

用戶訪談（用戶深度訪談、電話、街頭狙擊、焦點小組等）、問卷調查（配合數據分析，成熟的方法）、意見反饋（參與感，常規方法）、可用性測試（卡片分類法、A/B測試、屏幕錄像、眼動跟蹤、專家評審等）、現場調查、任務分析。

 3.1.2 查閱資料獲取

查閱行業專家的言論、查閱相關網站資料（眾多數據網站、數據報告）、運營數據、競品分析等。

3.1.3 通過自己的思考挖掘

產品感覺（日積月累）、日記分析法（把自己當做用戶，詳細記錄自己的使用情況）、觀察思考（觀察思考生活，一切都來源於生活）、KANO模型分析、人性角度分析、用馬斯洛需求層次理論分析等。

3.2 需求分析

在產品圈，有一個流傳甚廣的故事：亨利·福特曾說：「如果我最初問消費者他們想要什麼，他們會告訴我『要一匹更快的馬！』」有人說：「如果真這樣，汽車大王就不會出現了。」

福特為什麼沒有給用戶一匹馬，而是給了用戶一輛車？因為在「一匹更快的馬」這個表面需求背後，是「更快更舒適的出行方式」這一更深層次的需求。要滿足「更快更舒適的出行方式」，福特汽車顯然是更好的產品。

這就是需求分析的關鍵：明確用戶的本質需求，即挖掘表面需求背後更深層次的需求。只有明確了本質需求，才能確定更好的產品方向，以更好地滿足用戶。

所以，收集來的用戶需求，往往不是用戶的本質需求，甚至可能不是用戶的真實需求。因此，需求分析是必不可少的步驟。需求分析主要有如下兩類方法：

3.2.1 定性分析

多問為什麼：打破砂鍋問到底，就是挖掘本質的重要方法之一，在質量管理領域，5why分析法是找到根本原因的有效方法，豐田汽車公司在發展完善其製造方法學的過程中也採用了這一方法。實際應用中，如果用戶提出一個需求，我們就可以問為什麼用戶會有這種需求。例如：用戶提出「增加發簡訊功能」的需求，我們就可以問為什麼？接著就會發現用戶想要的可能不是「發簡訊」，而是「文字通信」的需求，甚至乾脆就是「通信」。這時我們就能找到更多的解決方案，而不僅僅局限於「發簡訊」，例如可以提供文字聊天、語音聊天、視頻聊天，將來還能提供VR聊天等功能，或許未來還能直接用腦電波溝通……

魚骨圖：這也是質量管理領域的常用方法，由日本管理大師石川罄先生發明，故又名石川圖，是一種尋找問題根本原因的方法，Mindjet MindManager中就提供了多種魚骨圖的模板。雖然網際網路行業用得不多，但沒有思路時可以一試。

用戶+需求+場景（PSPS）：這是貫穿產品始終的重要方法，因為需求貫穿產品始終，而每一個需求都有根源——用戶+場景。因此，需求都是具體的而非抽象的，正如痛苦是剛失戀時躲在房間深陷回憶的每分每秒，而不僅僅只是「痛苦」二字。在挖掘用戶的本質需求時，當然也要結合具體的場景、具體的用戶，去分析其本質需求。

不同類型的用戶、不同場景下會產生不同需求。正如羅振宇常說的「碎片化」，就是因為現代白領足夠忙，通勤的頻率足夠高、時間足夠長，在洗漱時、公交上、地鐵上容易產生碎片化學習/娛樂的需求。再比如常見的鞋子，各種用戶、各種場景下，就會有各種不同需求，因此產生了各種各樣的細分市場——跑鞋（進一步還能根據腳的形狀、跑步強度等進行細分）、籃球鞋、羽毛球鞋、休閒鞋、皮鞋、高跟鞋、拖鞋、棉拖等等。

馬斯洛需求層次理論：這是一個著名的理論，而且，越是底層的需求，其規模往往越大，用戶需求的程度往往越高。例如「性需求」為第一層需求，這一需求催生了一系列長盛不衰的產業，這方面的網際網路產品也數不勝數。

其他角度：如人性角度，這是張小龍提過的「貪嗔痴」，當然還可以結合所謂「七宗罪」等說法進行分析。再比如自私的基因，這是《自私的基因》這本書的核心，一切需求可以說都源自於此。但是否要將需求分析到這種程度，值得商榷。個人認為將需求分析到可以找到多種解決方案的程度即可。例如福特汽車與馬的故事，將需求分析到「更快更舒適的出行方式」，就能找到很多解決方案，如馬、馬車、自行車、摩託、汽車等，從中擇優即可。若繼續分析，一直分析到自私的基因的程度，雖然可以得到更深層次的見解，但實際效果如何，就不得而知了。

3.2.2 定量分析

定性分析確保深入，定量分析提供依據。如今是以數據說話的時代，缺乏定量分析的定性分析，往往不夠可靠。

定量分析主要採用數據分析的方法，例如之前的問卷調查收集到了數據，就可以對這些數據進行分析；產品上線之後，可以收集用戶反饋、瀏覽數量、活躍數量等，還可以對某些關鍵路徑、功能等進行數據埋點，採集這些數據，並對這些數據進行分析。

數據分析步驟如下：

3.3 需求決策

結合產品目標與用戶的本質需求，就可以進行需求決策，即明確產品方向，也就是明確所謂的產品定位。在此基礎上，就能得出產品的核心需求。

大部分產品目標的關鍵很簡單——盈利。其實這也是眾多產品強調用戶價值的原因，沒有用戶價值，何來盈利？但是，不同企業/個人擅長的領域不同（如所謂的網際網路企業基因論），其希望參與的領域也不同，市場規模、競爭格局等也不同。所以，為了盈利，可以採取各種各樣的方式。就像為了滿足通信需求，移動聯通等運營商提供基礎設施等服務，手機廠商提供通訊設備，微信提供網絡聊天、語音、視頻等功能。

前面3步，其實就是《用戶體驗要素》中的戰略層——產品目標、用戶需求。這一層主要由產品總監等職級較高的人確定，咱普羅大眾接觸較少，接下來的則是咱們經常接觸的內容。當然，領導也可能只提供一個大致方向，這時就需要我們自己從第一步做起。

3.4 需求擴展

基於第三步確定的產品方向、核心需求，即可將需求進行擴展。

產品方向、核心需求往往很簡單，可能只有一句話。而最終產品需要實現的需求，則很多很多。對於微信，其定位可以用6個字概括：通信、社交、平臺。但微信已實現的需求，可以說多如牛毛，而且實現得非常好，以至於它已然成為月活8億的巨無霸APP。

具體方法上，可以進行頭腦風暴，可以按照不同用戶類型、不同用戶場景並結合」用戶+需求+場景「進行擴展，還可以使用之前收集的用戶需求。注意，有些需求往往不需要詢問用戶，例如註冊、設置、用戶信息管理等基本需求，一方面這是基礎的普遍性需求，自己容易判斷；另一方面這些功能有足夠的產品早已做得非常完善，可以參考；而且前人已總結了足夠多的互動設計原則供我們參考。

這一步顯得有些漫無邊際，仿佛從一個點迅速擴展成一張網，好像失去了核心。沒關係，下一步要做的，就是從這些漫無邊際中抽離出關鍵。

3.5 需求篩選

由上一步得到了足夠多的需求，但資源顯然有限，於是就有了需求的優先級問題，這就是需求篩選的作用。

3.5.1 重要、緊急二乘二矩陣分析法

關於需求的優先級，可以使用時間管理中著名的重要、緊急二乘二矩陣分析法。

這個方法是需求篩選的核心，其他方法都是此方法的補充。」緊急「很好理解，那麼」重要「呢？對此，我喜歡《高效能人士的七個習慣》中的解釋：

重要性與目標有關，凡有價值、有利於實現個人目標的就是要事。

對於產品，重要性則與產品目標正相關，越利於實現產品目標的，就越重要。所以說」以用戶為中心「、」顧客就是上帝「並非空穴來風。

3.5.2 設問法

設問法可以幫助我們識別用戶的真需求，也就是我們需要優先滿足的需求。

孫陶然在《創業的36條軍規》中說道：創業一定要解決真需求，不要做偽需求。怎麼區分真需求偽需求？用中文不太好區分，但用英文就很清晰：偽需求叫want，真需求叫need。Want的東西，用戶不一定會掏錢，need的東西，用戶一定會願意掏錢。所以need的東西，才應該是我們應該切入的事情。

可以提的問題大概有這些：對某個需求，用戶是否痛？多久痛一次？是否持續地痛？有多少人有類似的痛點？用戶為此痛點付費的意願如何？

以上問題包含了用戶需求的強度、頻次、持續時間、廣度、付費意願，其實也就是判斷是need還是want。

3.5.3 KANO模型

維基百科：The Kano model is a theory of product development and customer satisfaction developed in the 1980s by Professor Noriaki Kano, which classifies customer preferences into five categories.Kano模型是產品開發與客戶滿意度評估的一種理論，將顧客偏好劃分成了5類，該理論由Noriaki Kano教授在20世紀80年代提出。

KANO模型有一套比較成熟的分析方法，可以進行定量分析，也可以進行定性分析，將用戶需求分為3個層次（也可以分為5個層次），每個層次的重要性不同，具體如下圖。

3.5.4 用戶體驗層次

用戶體驗層次可以分為如下5個，優先滿足有用、能用，再追求可用，再追求用得爽，最後爭取形成品牌效應。

3.5.5 需求順序

需求之間如果有一定順序，其優先級也容易判定。例如：有3個需求，他們之間有這樣的關係：實現了A，才能實現B，實現了B，才能實現C。所以，這三者中，優先級最高的是A需求。

3.5.6 產品階段

根據產品階段（產品路線圖）劃分需求優先級，也是常用方法。不同階段需要實現的需求，往往不同。例如一個全新產品，最該實現的是用戶最迫切的需求，當產品逐漸成熟，需要實現的需求也越來越多，各種邊邊角角的體驗都需要提升。再比如微信小程序，剛開始對線上推廣有大量限制，但現在逐步釋放線上的能力，這當中可能有微信團隊內部線路調整的因素，也可能有其原先規劃的因素，但總的來看，都與產品的不同階段關係密切。

其中，比較明顯的一點在於：在產品的不同階段，我們關注的數據就有很大不同，下表是之前的一份總結：

3.5.7 公式計算

根據行業經驗或其他依據，確定一些公式，從而根據公式的計算結果判斷需求的重要程度。例如：用戶需求的重要性 = 權重 * 用戶總數 * 用戶平均使用次數 * 每次付費數額。

3.5.8 專家團隊決策

對於難以判斷優先級的需求，可以召開專家團隊評審會議進行決策。這其中，各部門發表各自看法，各個職級的人共同討論，可以進行投票、計算、根據經驗分析等等，最終確定需求的優先級。

到這可以發現：第四、五兩步，其實就是《用戶體驗要素》提到的範圍層：

3.6 需求設計

需求設計階段，是承上啟下的重要階段——將篩選之後的需求轉化為PRD的階段，也就是將所謂的」產品需求「轉化為」研發需求「。

這一步的完成，意味著實現了從最初的用戶需求到最終的研發需求的轉化，如下圖：

解釋一下：

• 用戶需求：用戶表達的需求。
• 產品需求：用戶的本質需求，即用戶需求背後的更深層次的需求，包括用戶的真實需求。
• 研發需求：研發人員可以理解並進行開發的需求，此需求由產品需求轉化而來。

上圖中，」產品需求「比較突出，因為這是關鍵。用戶需求–>產品需求–>研發需求，是分–>總–>分的關係，對產品需求把握的好壞，決定了整個產品的成敗。而研發人員的思維習慣是從總到分，所以和他們交流時，容易陷入很多技術細節。

下面介紹需求設計的具體方法。

3.6.1 需求設計整體流程

直接上圖。

這是產品人都很熟悉的三個步驟，先梳理處主線流程，進一步擴展為信息架構，再進一步細化為原型圖。

值得注意的是：進行需求設計時，最關鍵的不是一上來就擼起袖子畫原型，這樣容易陷入大量的細節而失去重點。流程圖是整體的重點，將流程圖梳理清楚、正確，才能保證原型圖的正確。上圖這三步，就是從上到下的思維模式，也即總分的思維模式；而若直接畫原型圖，就是從下到上的思維模式，也即分總的思維模式，這種思維模式容易讓人找不到主線，陷入繁雜的細節中，因小失大，效率很低。

當然，實際工作中，從上到下和從下到上的思考都會存在，因為有的地方是在做信息架構或者畫原型的過程中想清楚的，還可能會因為畫原型時得到的某些想法而更改流程圖，正如執行計劃的過程中還會修改計劃。所以，實際的工作流程更像下圖這樣。但上圖的方式是主要的方式。

上圖中，三者的大小與其重要性成正比。當然，這裡的重要性指的是前後置條件、效率上的，而非結果上的。僅從結果上看，最重要的當然是原型圖。

3.6.2 抓住重點：產品框架、關鍵路徑

之前火熱傳播的雕爺牛囊、黃太吉外賣如今已鮮有耳聞，為什麼？因為它們做的餐飲雖然極其好看，店面也極其時尚，包裝極其美觀，服務極其體貼，甚至還有情懷，但關鍵在於——並不好吃。下圖是黃太吉外賣的煎餅：

其實錘子手機的不斷掙扎，也體現了這一點。錘子手機上集中了大量美好但「無用」的功能，以至於直到現在還在生死線邊緣掙扎。

寫了這麼多，我想說的是：產品的關鍵不是所謂極致的用戶體驗，不是所謂完美的視覺感受，而是其產品框架、關鍵路徑——對用戶核心需求的實現。也就是說，產品的關鍵在於其滿足用戶核心需求的程度。這也是二八原則的體現。對於餐飲，除了安全，多數用戶最注重的往往是味道，而不是過度的服務；對於手機，多數用戶最注重的不是過於美麗卻易碎的外觀，炫酷卻不比其他手機實用太多的作業系統，他們往往更注重性價比、拍照、知名度。

名詞解釋：

• 產品框架：產品的功能模塊——圍繞一個或少數幾個核心功能打造的模塊。
• 關鍵路徑：用戶使用產品的關鍵路徑。

不論產品框架，還是關鍵路徑，其實都圍繞用戶的核心需求展開，這便是關鍵所在。在需求設計時，就要抓住這一重點，而不是全心撲向所謂用戶體驗。

具體應用產品框架與關鍵路徑這兩個概念時，應注意：

a.抓住核心功能：通過上述幾個步驟已基本確認產品框架，此處的重點之一是抓住重點，切勿因小失大。就像做餐飲，過於注重服務、包裝等等，而忽視味道，就是因小失大。

b.簡單：將產品的核心功能設計得足夠簡單。就像微信當時推出的搖一搖功能，沒有任何文字說明，卻結合了很多人性因素，讓人可以無師自通，還能樂在其中。而其操作僅需搖動即可，非常簡單。

c.簡短：將產品的關鍵路徑設計得足夠簡短。正如知乎將側邊欄改為底部標籤導航，微信從閱讀文章的同時無法聊天到如今可以置頂文章，從只能翻閱訂閱號歷史文章到如今可以搜索訂閱號的歷史文章，支付寶將支付碼調整到首頁最上方等等，這都在逐步縮短用戶的關鍵路徑。

3.6.3 用戶+需求+場景

就像前面提到的，這是貫穿產品始終的重要方法，每個用戶需求都是具體的，都是實實在在的。而在需求設計時，卻容易陷入「自我YY」的狀態——忽視用戶實際需求的狀態，腫麼辦？

為了防止這一點，可以將用戶按照不同類型細分，並描述出每一類用戶的場景，從而更具體地而非抽象地把握用戶需求。如何做到這一點？一個廣泛應用的方法就是構建用戶畫像，而且構建用戶畫像還有很多其他好處，例如利於團隊其他人員理解用戶需求等等。

值得注意的是：在構建用戶畫像時，應注意區分不同類型用戶的優先級，我們要滿足的不是所有用戶，而是滿足重點用戶，多數時候這個重點用戶是大多數用戶。有時嚴謹的研發同事會揪著一個非常低頻的需求不放，因為這可能會有漏洞，或者邏輯不夠嚴謹，這時就要評估其危害大小，一般來說可以按照二八原則執行。例如微信好友上限為5000，這對絕大多數用戶是足夠的，但對很多微商而言，這就是一種限制，那麼要不要增加上限呢？張小龍的想法是不增加。而之前出現的支付寶登陸漏洞，則是一個大漏洞，雖然這樣做的人很少很少，但一旦發生，危害極大。

在此基礎上，設計時還應時常想著「用戶+需求+場景」，就能更好地實現「以用戶為中心」。

3.6.4 增刪查改顯算傳

產品人常常自稱產品狗，挺寫實的，尤其在評審會上，被challenge也時有發生，有時這種challenge非常直接，當然比起用戶的吐槽，這都不算啥。為什麼會在評審會上被程序猿challenge？因為程序猿是邏輯嚴密且辛苦的物種，需求設計出現邏輯不嚴密、需求考慮不全、不利於技術實現等問題時，都會造成程序猿的工作量大大增加。也許一個功能看似簡單，但技術實現上卻可能很複雜。為了自己或者團隊，程序猿都有必要challenge。

作為產品人，當然希望少被challenge，那就要考慮一些技術實現問題。這其中，普遍存在的就是「增刪查改顯算傳」，其中最難的點在於「傳」，這需要了解一些資料庫知識。更詳細的內容之前寫過，此處不具體解釋了，直接上圖。

3.6.5 互動設計原則

需求設計的過程中，無疑會遇到互動設計。互動設計有很多現有的原則可以參考，對此，我總結了一些，放在下面：

多用用戶熟悉的東西

符合用戶心理模型、環境貼切原則、預設用途、席克定律、統一原則、一致性原則、映射。

簡便

菲茨定律、主次原則、易掃原則、簡潔原則、合併原則、神奇數字7±2法則、泰斯勒定律（複雜性守恆定律）、靈活高效原則、奧卡姆剃刀原理、少做原則、易取原則、基於用戶使用場景設計、結合行動裝置的特性設計。

反饋

狀態可見原則、可視化。

錯誤處理

新鄉重夫防錯原則、容錯原則、撤銷重做原則、人性化幫助原則。

其他

接近法則、三等分原則、對稱原則、界面先行原則、資源代替等。

3.6.6 注意點

a.多設計：多設計幾個方案，從中擇優。面對一個需求，尤其是核心需求，多想幾個實現方式，而不是剛想到一個實現方式就立馬上手。從這幾個方案中選擇最好的方案，往往更好。

b.多檢查：設計完了，往往還有問題，這時需要多檢查幾遍，最好能把上述5個步驟都過一遍，能避免一些不必要的漏洞。記得《賈伯斯傳》中提過，賈伯斯喜歡看實物而不是設計，我們也應儘量去體驗實際效果，在需求設計上尤其如此，多看幾遍最後的交互結果，往往能找出問題，所以高保真原型是更好的，但那也會消耗很多時間。

c.多總結：老生常談就不談了。

到此，我們便完成了《用戶體驗要素》所提的所有層次，如下圖。

當然，在需求設計過程中，也會有相關評審，有的公司會有很全面的評審流程，包括需求評審、設計評審、測試評審，有的公司則比較簡單，這都有各自的實際考慮，免去不表。

3.7 需求開發

需求開發，就是將PRD轉化為實際產品的階段，這時開發、測試同事就會忙碌起來。開發、測試過程中，也會出現問題，有時是再次確認需求，有時是技術可行性問題，有時是細節漏洞問題（有些細節在實際開發時才被發現），有時是產品經理設計不合理，有時是產品經理改需求……說到改需求，這是開發同事最深惡痛絕的，因為這往往會導致他們的工作量大幅上升，關於此，網上也有很多段子，比如下圖：

對於產品經理，此時需要做的就是盡力配合，保證產品及時落地。

3.8 需求上線

當產品完成，就可以上線了。上線之後會驗證產品經理對需求的把握是否準確，很多設計是否合理……接著，就會進入下一輪的循環。

到此，文章算是寫完了。看似挺多，其實主線比較簡單——主要從需求的角度描述產品經理的工作內容，即產品規劃、產品設計、產品執行，如下圖：

 

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