2023年，我寫了一篇梳理prd的文章《 prd到底該怎麼寫？》，獲得3.5萬次閱讀，423次收藏。至今已過去5年，在這5年裡，我一直從事產品產品相關的工作，也經歷過一次完整的創業，對prd又有了一些新的思考。這篇文章是《prd怎麼寫》的公升級版，彌補了之前文章的不足，對怎麼寫prd，描述得更具體、更全面，是我思考的沉澱，也希望對大家有一定幫助。
01. 你是否遇到過這樣的問題
如果遇到以上乙個或多個問題，那麼你可能需要反思，自己寫prd的思路是不是有問題？寫prd是產品經理非常重要的基本功，寫好prd，可以提高團隊效率，減少無效的溝通。
02.什麼是prd?
prd是product requirement document的簡稱，其中文翻譯為：產品需求文件。該文件是產品專案由「概念化」階段進入到「圖紙化」階段的最重要的乙個文件。
prd的主要使用物件有：研發、測試、互動設計師及其他業務人員。
prd是專案啟動之前，必須經過評審達成共識的最重要文件。
產品經理的prd，就像建築設計師的設計圖紙，是設計和思考的文件化呈現。
《使用者體驗要素》作者在書中有一句很經典的話：「文件不能解決問題，但定義可以」，prd就是要定義需求。
03. 動手之前，先思考這幾個問題
1、解決什麼問題？
解決使用者什麼問題？發現問題比解決方案更重要。給公司能否帶來收益？相關干係人的需求是什麼？是不是老闆說這樣做的？是不是「他們」說這樣做的？他們是誰？真正的問題是他們說的那樣嗎？
產品經理正確的設計思路如下：
這叫rtpa設計框架，是一種逆向思維假設分析，我們要使用這樣一種思考技巧：假設初始需求都是錯誤的，即問題並不存在，你需要重新發現問題。
不要需求方一提需求，就開始著手設計，多問幾個為什麼並著手調查，以了解真正的問題。
下面是一次完整的設計思路示例：
2、怎麼衡量？
不同的干係人，通過什麼指標去衡量問題是否已解決？有沒有埋點？有沒有業務資料？誰來運營？
3、需要多少資源？
為了實現這個解決方案，需要多少資源、多少人？能大致評估嗎?
4、會不會太複雜？
這個解決方案會不會太複雜？複雜是產品的墳墓。有沒有價效比更高的解決方案？會不會影響現有的業務？會不會影響歷史資料？
5、有風險嗎？
這個方案會有風險嗎?有沒有違法？相關政策是什麼？尤其是金融、遊戲領域，國家監管比較嚴，有可能上不了應用市場，有可能三方服務商不會提供服務。
6、有創新嗎？
有更創新的解決方案嗎?競品怎麼做的，有沒有調研3個以上的競品方案。
7、使用者怎麼說？
需求真的是提交人說的那樣嗎?有親身體驗過場景嗎？有跟使用者面對面交流嗎？熟悉相關領域的基本知識嗎？有看不懂的名詞嗎？
動手寫文件或做設計方案之前，一定要問問自己以上幾個問題，想清楚了在動手，任何乙個問題沒想清楚，都不要進行下一步。
04. 寫prd的基本步驟
搭框架、定流程、扣細節，這是從一名產品前輩那了解到的產品設計流程，寫prd，也可以按照這個思路。
1、搭框架。首先遍歷出所有使用者角色，再針對每個角色，提供相應的系統/功能，然後按照某種維度進行結構劃分。這個步驟完成後，就可以輸出產品的系統架構圖及系統的功能結構圖。
產品架構圖，出自《電商產品設計全攻略》
更細化的功能結構圖
產品由乙個個功能組成，功能是邏輯結構，乙個完整的功能具備輸入、處理、輸出三大特性。從大到小的劃分是：系統》功能模組》功能，使用者+功能組成了用例，用例是prd文件裡描述佔比70%以上的內容，所以合理的功能結構，是寫好prd的前提。
2、定流程。每個產品都有乙個核心業務流程，這個核心業務流程涉及多個角色，這個步驟就是把各個角色和功能聯絡起來。通過核心業務流程，閱讀者可以了解產品全貌，對產品有個巨集觀的認識。
此外，每個系統也有各自的核心業務流程，全業務流程+子系統業務流程，可以概括產品的業務邏輯。
這個步驟輸出產品核心業務流程圖，子系統核心業務流程圖，活**，狀態機圖，與外部系統互動可能還有時序圖。
3、扣細節。這一步的核心的畫原型和功能設計，通過原型表達產品的介面和互動。功能設計主要是從輸入處理輸出三個方面去考慮，使用者執行輸入指令後，系統會進行邏輯處理，然後輸出結果。此外，還要考慮功能涉及到哪些資料，表結構怎樣設計，這些會涉及大量細節，prd大部分內容，都是在描述這些細節。
步驟1和步驟2沒有嚴格的順序，也可以先梳理業務流程，再根據流程中的具體場景梳理出實際功能或系統結構。
05. 文件的組成部分
1、修訂記錄
記錄每次文件更新的時間、作者、修訂內容，便於追溯歷史變動；
2、全域性說明
包括名詞解釋、統一異常處理、列表預設資料規則等。
3、專案背景
每個產品，都有一套價值模型。以信貸產品為例，針對使用者的價值指標有放款額、審批時長、是否上徵信等；針對後台業務人員，有審批時效、通過率、放款率、壞賬率等指標；針對老闆，有投資回報比、員工成本、淨利潤等價值指標，每乙個需求，應該都是圍繞某個價值指標展開。
背景從現狀、方案、目標3方面描述。
通過專案背景的描述，可以讓專案參與者感受到自己的工作價值。
4、專案範圍
專案範圍對應搭框架部分，將功能結構圖在此處羅列；
5、業務流程
業務流程對應定流程部分，將核心業務流程、子系統業務流程在此處羅列；
6、功能需求
這個部分在prd中佔比最大，搭框架部分，已經將產品功能點全部梳理出來了，這部分就是對功能點進行逐一描述。功能是從系統的角度來看，我們還要考慮使用者角度，所有我們採用使用者+功能的方式來描述需求，這就是用例。完整用例名稱一定是動賓結構，如新增文章、刪除文章、修改文章、檢視文章列表。乙個完整的用例包含：
描述功能的簡要描述。
前置條件
要操作此功能，需要具備什麼角色、許可權或狀態。
後置條件
執行完這個用例後，關聯的資料會有什麼變化，頁面怎麼跳轉。
介面表單的每個元素要描述是否可為空、是否有初始內容、是否預設選中、是否有字數限制等，還有對應的錯誤提示；
文字要考慮最大顯示長度，超過怎麼處理；
鏈結一定要指定點選後跳轉到哪個頁面；
要考慮顯示的比例，如果未載入出來該顯示什麼；
還要考慮介面的內容是寫死還是通過後台配置；
介面元素：
業務流程
當使用者完成輸入並提交時，後端應該做什麼校驗，不同輸入該怎麼處理，不同結果該返回什麼值，最好通過業務流程圖+文本來描述，確保邏輯完整。
示例：
文本版：
異常和分支流程
異常流程如網路錯誤、介面返回異常、伺服器內部錯誤等；
以登入為例，分支流程包括找回密碼、密碼登入等，分支流程非必須，簡單的分支流程可以直接通過主流程體現，具體可以視情況按照一定顆粒度進行拆分。
資料字典
產品經理一定要懂基本的資料庫知識，程式=資料結構+演算法。使用者使用產品時，本質上是在和資料進行互動，只是在使用者和資料之間，加了一些列演算法。
7、非功能需求
資料需求。常見的就是資料埋點，產品經理需要梳理出埋點事件表，告知開發，讓開發在編碼過程中進行埋點。
監控需求。需要監控某個介面或某些服務，當出現異常時，可以傳送報警資訊至相關人員。
效能需求。需要支撐多大的併發，運維人員可以提前準備部署方案。
06. 最後
一定要用正確的思路去寫prd，更要想清楚prd所呈現方案的價值。方向不對，努力白費。記住，找準問題比解決方案更重要。
參考；[prd文件範例，產品經理值得收藏的寫作手冊]( )
產品經理十四章 產品需求文件 PRD 二
一 prd的基本要求 乙個優秀的prd文件應該滿足五個方面的要求 完整 準確 清晰 簡潔 穩定。1 完整 1 必要內容無遺漏 專案中開發工程師應該了解的所有內容都應該在文件中有所體現。即使是一些還沒有確定的需求，也要有在文件中占個坑，標明 該部分內容待定 並說明該內容確定的最晚時間。2 功能描述完整...
PRD產品需求文件概要
prd概念 prm就是product requirements document的簡稱，也就是產品需求模型。一般來說乙個產品會伴隨有市場需求文件 market requirements document 產品需求文件 prd 有些公司會把mrd和prd兩個文件合併為prm文件。prd文件需要包含的內...
產品需求文件 PRD（上）
深刻理解三大文件的寫作目的與應用場景 理解並掌握prd文件的用途與作用 理解並掌握prd文件 寫作思路 寫作方法 寫作格式 prd文件向上是對mrd內容的繼承與發展，向下則是要把mrd文件裡面的各種理論要求 技術化，向研發部門與設計部門說明產品的功能和效能要求。prd文件是產品文件中最底層最細緻的文...