PRD（Product-Requirement-Document，產品需求文檔）

產品經理的整體思維體現在：

1、提煉核心需求

2、思考滿足核心需求的方式

3、評估方式優劣選定方案

4、思考功能概要

5、思考支撐功能和關聯功能

6、細化設計功能

7、子功能（功能間迭代）

PRD主要內容

1、文件命名（編號）

一般命名規則“公司名+產品名+PRD+D1.0”（以第一版為例）

2、修訂控制頁

一般有這么幾項：編號、文檔版本、修訂章節、修訂原因、修訂日期、修改人

3、目錄

4、請與以下部門討論PRD

PRD做為一個承接作用的“載體”，會與技術、運營、財務等人員的溝通，而與這些人員溝通的主題都將會出現在子功能或在細節細化的基本上。

5、概述

概念就是總結，它包括的點有：名詞說明、產品概述及目標、產品roadmap、產品風險。

名詞說明：名稱、說明。名稱就是對文檔中會出現的比較新的名稱，說明則是對這些名稱進行解釋。

產品概述及目標：產品概述及目標就是對產品核心功能講解，同時希望可以達到的期望。

產品roadmap：產品分期目標，階段描述，以及時間點的確定，產品是個不斷演進的過程，很多時間一期產品只完成了產品70%的功能，二期才會繼續去完善剩下的30%，同時有可能會推翻了重新推出第二版。產品roadmap并不及著全部規劃好所有的階段目標，而是更多的通過維護來保持產品的更新和迭代。

產品風險：描述產品可能存在的風險，比如商務談判的風險，外部合作的風險，不當使用的風險等等。風險級別為高中低。

6、使用者需求

使用者需求一般只有個需求描述。需求描述有以下幾項內容：目標客戶、需求描述、場景描述、優先級。

目標客戶即為產品的最終用戶，確定產品的最終使用者。

需求描述是對目標客戶的需求描述，表達用戶最需要的是什么，找到用戶的最根本需求。

場景描述，產品在哪種情況下會被用戶使用，就是用戶場景模擬。

優先級是指用戶對于當前產品功能需求的優先級，哪些是用戶最想要的功能優先級則排前。

7、可選方案

列出所有可以選擇的達到該產品目標的方案要點（主要思路），給各方案適當的評價，并推薦最優方案。你在做這個產品規劃時一定有很多的備選方案，別放棄這些方案，永遠沒有過時的idea，只有最適合時機的idea。所以可以寫出幾個可選方案，或許是你下期產品改版一個方向。

8、效益成本分析

產品經理是個全才，在這點上得到了體驗。產品經理得知道財務知識。很大一部分是產品的環境搭建成本和支持人員的成本。一般的效益成本分析包括三個方面：效益預測、產品技術中心成本、非產品技術中心支持成本。

效益預測是指提供在各種產品環境中的效益預測，并標明主要的變量及假設，最好能包含現在和過去的效益數據。如網站的PV值，軟件的使用數都是效益預測數據。

產品技術中心成本是指設計及部署此產品的產品技術中心所需的資源需求，包括人力成本，軟硬件支出等。很大時候這份成本需要由項目經理來協助，需要有什么樣的人才加入產品中需與人力協助。

非產品技術中心支持成本，產品不是只有產品組完成的，同樣需要其它部門的配合與協助。比如：需要客服部投入多少的資源用于該產品的服務，需要運營部投入多少的資源運營該產品。

9、功能需求

功能需求一般是由四部分組成，功能總覽、功能詳情、整合需求、BETA測試需求。

功能總覽一般包括二個部分，一個是流程圖，一個是功能表。流程圖是對產品的整體走向的流程的規劃，流程圖是用來對產品整體功能的梳理。所以在做產品前建議所有的產品經理先梳理一下產品流程。功能表是將流程圖文字化，同時將列出產品的功能點。

功能詳情，這是所有的產品功能的描述和規劃。包括以下內容：

簡要說明：告訴此功能主要干什么的。

業務規則：每上產品在使用時都有自己的規則，而產品的業務規則則是將產品的流程細化。個人建議將這個功能的業務規則，包括一些細節，如排版形式、日期顯示方式全定好，這樣方便其它人員的溝通和理解。

界面原型：產品經理在這時做的原型界面只是顯示的框架，別細化，這樣會給交互和UI造成錯覺。只需做一個簡單的界面即可，更多的時候只是個框架圖。

執行者：產品使用者。

前置條件：具體的操作。

后置條件：操作后的展示。在UC（user case）中后置條件又是另一種情況，所以對于建議在PRD中的前置條件和后置條件結果合起來。

主流程：把主流放在最后是有道理的，結合上面所說的，做出主流程說明。將此功能的流程走向做個分點說明。

10、整合需求

產品經理很重要的一個能力就是體現在產品整合能力上，利用公司現有的資源或外部資源（合作公司等）實現產品功能需求的整合。實現功能貫穿的同時，更多的如何在新產品上實現功能的拓展來輔助核心功能。

11、BETA測試需求

很多產品都有BETA版本放出，為了就是收求意見和一些性能測試。這部份內容不是必須的，但現在很多產品已經開始先推出BETA版本再推出正式版，當然也可以通過升級來解決。所以BETA測試需求并不是一定需要的。如果有BETA測試需求，則需寫出BETA版測試的要求和期望達到的目標要求。

12、非功能性需求

都說產品經理是全才，在這點上得到徹底的體現。很多產品經理在這點上忽視了，但很多方面是用到的，只是在產品過程中弱化了。

一般情況下非功能性需求包括以下幾個部分：產品營銷需求、規則變更需求、產品服務需求、法務需求、財務需求、幫助需求、安全性需求等。與其說是全方位的掌握技能，還不如說是溝通，如何與不同的部門人員之間的溝通，讓更多的人協助產品的正常使用與上線。

13、上、下線需求

上線時限需求：此產品預定上線日期？上線日期有無任何特殊依據或規定？

下線需求（活動類需求必須明確下線時間）：此產品預定下線日期？下線日期有無任何特殊依據或規定？

14、運營計劃

說明產品的后續運營計劃。包括與運營部的協作運營。更多的是給產品經理如何讓更多的產品功能展示給用戶，產品經理是核心需求的把握者，參與到產品整體運營計劃顯得特別的重要。

讀書筆記：老曹-【如何寫PRD】