今天給各位分享產(chǎn)品經(jīng)理prd文檔模板的知識，其中也會對產(chǎn)品經(jīng)理mrd范本進行解釋，如果能碰巧解決你現(xiàn)在面臨的問題，別忘了關(guān)注本站，現(xiàn)在開始吧！

本文目錄一覽：

• 1、產(chǎn)品經(jīng)理的PRD到底該怎么寫
• 2、產(chǎn)品經(jīng)理需要寫什么文檔？
• 3、產(chǎn)品經(jīng)理文檔之PRD
• 4、產(chǎn)品經(jīng)理PRD寫作

產(chǎn)品經(jīng)理的PRD到底該怎么寫

PRD（Product-Requirement-Document，產(chǎn)品需求文檔），寫作目錄如下：

1、文件命名（編號）

文件的編號很關(guān)鍵，因為產(chǎn)品迭代過程會有不同的文件版本，一般命名規(guī)則“公司名+產(chǎn)品名+PRD+D1.0”（以第一版為例），這樣命名有利用版本號的迭代。

2、修訂控制頁

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

3、目錄

4、請與以下部門討論PRD

PRD作為一個承接作用的“載體”，會與技術(shù)、運營、財務等人員的溝通，而與這些人員溝通的主題都將會出現(xiàn)在子功能或在細節(jié)細化的基本上，需要與相關(guān)人員確定“溝通內(nèi)容”，這對于產(chǎn)品整體流程將是很重要的。

5、概述

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

6、使用者需求

使用者需求一般只有個需求描述。需求描述有以下幾項內(nèi)容：目標客戶、需求描述、場景描述、優(yōu)先級。

7、可選方案

列出所有可以選擇的達到該產(chǎn)品目標的方案要點（主要思路），給各方案適當?shù)脑u價，并推薦最優(yōu)方案。

8、效益成本分析

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

9、功能需求

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

10、整合需求

產(chǎn)品經(jīng)理很重要的一個能力就是體現(xiàn)在產(chǎn)品整合能力上，利用公司現(xiàn)有的資源或外部資源（合作公司等）實現(xiàn)產(chǎn)品功能需求的整合。

11、BETA測試需求

很多產(chǎn)品都有BETA版本放出，為了就是收求意見和一些性能測試。

12、非功能性需求

都說產(chǎn)品經(jīng)理是全才，在這點上得到徹底的體現(xiàn)。很多產(chǎn)品經(jīng)理在這點上忽視了，但很多方面使用到的，只是在產(chǎn)品過程中弱化了。

13、上、下線需求

上線時限需求：此產(chǎn)品預定上線日期？上線日期有無任何特殊依據(jù)或規(guī)定？

下線需求（活動類需求必須明確下線時間）：此產(chǎn)品預定下線日期？下線日期有無任何特殊依據(jù)或規(guī)定？

14、運營計劃

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

……

寫PRD并不是產(chǎn)品經(jīng)理的全部工作，但卻是不可少的一部分，很大程度上反應了產(chǎn)品經(jīng)理的思維和產(chǎn)品核心功能把握上，同時對產(chǎn)品經(jīng)理溝通、協(xié)調(diào)、規(guī)劃等

想學習更多PRD文檔寫作方式，可以來官網(wǎng)學習

產(chǎn)品經(jīng)理需要寫什么文檔？

一、商業(yè)價值

1、我可以為企業(yè)創(chuàng)造什么樣的價值？

2、這些價值是否符合企業(yè)的整體戰(zhàn)略目標？

二、歷史回顧

1、客戶價值和商業(yè)價值是否發(fā)生了變化？

2、二期產(chǎn)品的路線規(guī)劃和原規(guī)劃是否一致，（如有調(diào)整）調(diào)整原因是什么？

3、之前的實際運營效果和計劃的差異是什么？為什么？

1、 更細致的市場與競爭對手分析；

2、 通過哪些功能來實現(xiàn)商業(yè)目的；

3、 功能/非功能需求分哪幾塊；

4、 功能的優(yōu)先級；——可能產(chǎn)出物有Mind Manager的思維圖，Excel的Feature Lis。

產(chǎn)品經(jīng)理文檔之PRD

PRD：產(chǎn)品需求文檔，全稱是Product Requirement Document，是產(chǎn)品文檔中最底層最細致的文檔。文檔側(cè)重對產(chǎn)品功能和性能的說明，主要是把產(chǎn)品規(guī)劃與設計中的產(chǎn)品流程，界面，功能等定義向研發(fā)、設計、測試等團隊做清晰的描述說明。

1、幫助團隊存檔產(chǎn)品信息

產(chǎn)品實現(xiàn)過程中，有很多的邏輯、算法需求，沒有文檔的記錄，容易在團隊變更、交接班的時候出現(xiàn)較大風險。通過產(chǎn)品需求文檔記錄產(chǎn)品的各種需求與實現(xiàn)方式，能有效降低團隊的風險，同時也能提高交接效率。

2、提升內(nèi)部信息溝通的效率

雖然需求可以口述，但是不代表說一次全員就都能記得，會遇到開發(fā)、設計或測試記不清楚的地方，可以直接查看文檔。結(jié)構(gòu)明確、表達清晰的文檔仍然有不可取代的作用。

3、產(chǎn)品工作有據(jù)可查

各方需求理解不一致，或延期產(chǎn)品工作的時候，通過產(chǎn)品需求文檔都可以有效的找到問題根源。

研發(fā)人員：由于研發(fā)人員本身專注于功能的實現(xiàn)與性能，所以他們相對于其他崗位比如運營，時長，設計等，表現(xiàn)相對不太關(guān)系，對于產(chǎn)品更多地了解來自于產(chǎn)品經(jīng)理的產(chǎn)品宣講。

設計人員：設計人員本身更多的會關(guān)注產(chǎn)品的表現(xiàn)形式與原型，所以對PRD的需求是相對較弱的。

還有老板、項目經(jīng)理、運營、市場、客戶、財務……

所以，PRD文檔，根據(jù)閱讀對象，可以用最平鋪直敘的話，把產(chǎn)品描述清楚就行。

文字模式 ：Word。時間較為充裕的或崗位責任制分明，有文檔要求規(guī)范的團隊，建議選擇Word撰寫文檔。

原型圖模式 ：Axure。追求時間效率靈活性的團隊，建議選擇Axure撰寫文檔，原型搭配產(chǎn)品說明，無需切換，只用一個文件就可，方便快捷。

無論哪種方式，都是大同小異，本質(zhì)上并不影響PRD文檔的使用效果。

1、修訂記錄：版本號、修訂日期、修訂章節(jié)、修訂內(nèi)容、修訂人等。

版本號說明，以1.25舉例：

版本號（ 1 .25）：重大調(diào)整升級，一般是產(chǎn)品結(jié)構(gòu)功能等有調(diào)度。

子版本號（1. 2 5）：在原有基礎(chǔ)上對局部功能進行了升級或調(diào)整。

修正版本號（1.2 5 ）：局部小范圍優(yōu)化與Bug修復，一般是不動功能性的東西。

版本號的命名規(guī)則：

歸零原則：前一個數(shù)字增加一位，后面的數(shù)字都歸零。

修訂記錄的作用：

對修改前后進行比較

有利于維護和管理PRD

記錄修訂人和修訂日期

方便查詢，可以只看修訂部分，快速查找變更之處

2、名詞術(shù)語：將一些產(chǎn)品里面不易理解，容易混淆，或者縮寫的詞匯在開篇進行統(tǒng)一的列表說明，有利于閱讀。

全局說明包括：權(quán)限說明、授權(quán)說明、異常情況、鍵盤說明等。

權(quán)限說明：對角色權(quán)限進行劃分，例如登錄和未登錄狀態(tài)下可訪問的功能權(quán)限。

授權(quán)說明：手機號授權(quán)、地理位置授權(quán)、相冊授權(quán)等。

異常情況：加載失敗、網(wǎng)絡異常等。

鍵盤說明：數(shù)字鍵盤、字母鍵盤。

......

1、產(chǎn)品結(jié)構(gòu)：包括產(chǎn)品功能結(jié)構(gòu)圖、信息結(jié)構(gòu)圖。

2、業(yè)務流程圖：通過用戶行為串聯(lián)信息結(jié)構(gòu)和產(chǎn)品結(jié)構(gòu)，可以更好的理解產(chǎn)品經(jīng)理設計的用戶行為。

3、功能清單：清單包括功能模塊、功能點、功能描述等。

4、功能詳情：原型設計、功能說明和用例。

功能詳情的表述順序可以按照功能的邏輯來表述，或按照產(chǎn)品結(jié)構(gòu)來表述，具體可以看個人習慣和團隊要求。

用例：用例圖和用例說明。用例圖表述的是系統(tǒng)的外部參與者與系統(tǒng)之間的關(guān)系，是由參與者與用例組成的示意圖。

注意：

撰寫前要保證思考到位，產(chǎn)品結(jié)構(gòu)本身短期內(nèi)不會有重大改動。這樣即便是在交付后，出現(xiàn)調(diào)整或需要優(yōu)化的地方，也不會出現(xiàn)重構(gòu)的情況。

文檔中用詞用語一致，對于同一事物的表述應該一樣，避免混用。

非功能性需求是對產(chǎn)品非功能性需求的說明，包括性能需求、技術(shù)組件需求、安全性需求、可用性需求、質(zhì)量需求等。

性能需求：系統(tǒng)滿足多用戶同時工作，保障同時在線用戶五千人，并發(fā)操作一千人的使用需求。

技術(shù)組件需求：數(shù)據(jù)存儲及計算使用星環(huán)大數(shù)據(jù)平臺等。

安全性需求：涉及外網(wǎng)環(huán)境的需保證數(shù)據(jù)網(wǎng)絡架構(gòu)上保證數(shù)據(jù)的傳輸安全、具備良好的跨平臺部署能力等。

可用性需求：系統(tǒng)支持IE11并向下兼容，支持Chrome等主流瀏覽器。

質(zhì)量需求 ......

上面的文檔結(jié)構(gòu)只是PRD的基本結(jié)構(gòu)，并沒有成為固定的可以供套用的東西，文章只是一種思路的分享，具體還是要根據(jù)自己公司及團隊的習慣和達到你的目的為依據(jù)來進行調(diào)整，切勿生搬硬套。

閱讀原文

對產(chǎn)品經(jīng)理感興趣的朋友，可以移步“ 行業(yè)與市場分析 ”，期待共同交流。

產(chǎn)品經(jīng)理PRD寫作

PRD是什么？

可以說，產(chǎn)品經(jīng)理最重要的工作就是跟團隊說清楚需求，只有說明白了需求是什么，才能讓開發(fā)、設計、測試等去進行后續(xù)的工作。PRD是產(chǎn)品經(jīng)理說明需求的不二選擇。

什么是PRD？

PRD，產(chǎn)品需求文檔(Product Requirement Document，PRD)的英文簡稱，這是一個產(chǎn)品經(jīng)理為了跟其他項目成員說明需求的重要文檔，也是PM參加需求評審會時，你的成果作品。

你可能還不知道需求評審會是什么，那我就簡單講一講。需求評審會就是產(chǎn)品經(jīng)理提出需求跟大家PK，讓大家評估產(chǎn)品經(jīng)理提出的需求，然后決定后續(xù)工作的會議。幾乎所有的開發(fā)、設計、測試都會有忙不完的活，你憑什么讓他們把你的需求優(yōu)先開發(fā)，這將嚴重考驗你和你的PRD。如果搞不好，你會被開發(fā)、設計、測試從頭到腳批一遍，那個場面，就像在直播吃翔。

至于為什么會搞不好，很大程度就是產(chǎn)品經(jīng)理沒有把需求的各方面思考清楚，哪怕有一個邏輯沒有思考清楚，或者漏掉了某個步驟，團隊的其他人就會向你投來懷疑的眼光。如果一次評審會議中你被多次懷疑，那么不用想了，你就是在直播吃翔。

PRD是給誰看的？

首先，PRD是給產(chǎn)品經(jīng)理自己看的。產(chǎn)品經(jīng)理提出一個需求，那么實現(xiàn)這個需求的功能、邏輯，通過書寫PRD的過程，能夠慢慢梳理出邏輯。有人說：”我做高數(shù)微積分題全用心算完成，你那些功能、邏輯，我都能想得清清楚楚”。

其次，PRD是給團隊的其他人看的。一個產(chǎn)品經(jīng)理，即便能夠在腦海里想清楚所有的功能、邏輯，但是他不能保證團隊的其他人也能在頭腦里想清楚一切邏輯。所以，產(chǎn)品經(jīng)理需要通過輸出PRD，讓團隊其他人員理解需求的邏輯。

再次，PRD也是給老板看的。產(chǎn)品經(jīng)理需要做某一個產(chǎn)品，在跟老板申請資源的時候，給出一份清晰的PRD能夠讓老板看明白你到底要做什么。

你知道PRD有多重要嗎？

PRD的重要性，怎么夸大都不過分。

首先，PRD有證明需求的作用。你口頭跟開發(fā)、設計、測試說一個需求，他們可能也口頭上答應幫你做。然后，可能就真的沒有然后了。。。接近項目上線，你突然發(fā)現(xiàn)他們沒有做你的需求，這時你再去找他們，他們完全可以說你沒有提出過需求，那場面，直接就是在吃翔。所以，產(chǎn)品經(jīng)理需要認真寫一份PRD，通過需求評審后，郵件群發(fā)給開發(fā)、設計、測試等大爺，有文件留底，到時候他們就賴不掉了。

其次，PRD有證明PM的作用。很多公司將PRD的修改次數(shù)作為作為評判PM水平的標準，還可能作為PM升級評定的參考因素。如果一個產(chǎn)品經(jīng)理寫的PRD平均修改次數(shù)過多，那將嚴重影響升級評定。

PRD閉環(huán)

做產(chǎn)品無時無刻都需要思考產(chǎn)品閉環(huán)的問題。PRD作為需求的說明書，更是需要體現(xiàn)產(chǎn)品閉環(huán)。完成下面的步驟，你就能夠?qū)懗鲆环輧?yōu)質(zhì)的PRD了。

你的目的是什么？

這個是一份PRD最重要的地方，其實做一個產(chǎn)品，或者實現(xiàn)一個功能/邏輯，都不是困難的事，但是你得想好為什么要做這件事，或者說，你要確定做這件事所獲得的東西是不是你自己想要的。這個問題想不清楚，后面的都是白搭。比如，你準備做一個游戲活動頁，本來目的是為了拉新，但是目的沒有把握好，后面做成了留存，那么你的KPI很可能就“呵呵”了。

實現(xiàn)目的所需要的功能？

在目的已經(jīng)清晰、明確的前提下，PM得好好思考實現(xiàn)該目的所需要的功能，這些功能是實現(xiàn)目的的必經(jīng)之路。最好給出功能列表，一個功能點都可以單列一條，并且和測試用例一一對應。

還可給出功能的應用場景，方便團隊其他人理解該功能的作用。比如，一個簡單的用戶在某活動頁兌獎的情景：

用戶在購買某服務后，得到兌獎網(wǎng)址

用戶輸入該網(wǎng)址后，彈出活動頁

用戶點擊“領(lǐng)取獎勵”按鈕，頁面彈出注冊/登錄框，用戶輸入賬號密碼，登錄成功，領(lǐng)取獎勵

列出了功能點后，還需要對功能列表里的功能進行排序，得出 優(yōu)先級 。暫時不做的需求，也要事先提出，放入需求池。

完成功能需要的邏輯？

這部分其實就是將功能分成很多小的功能點，比如一個兌獎的功能，可以分拆成注冊、登錄、第三方登錄等小功能點。實現(xiàn)了每個功能點的邏輯，就組成了整個兌獎功能。

這部分，我感覺是 實現(xiàn)產(chǎn)品體驗的最重要階段 。實現(xiàn)一個功能的邏輯，如何做到讓用戶使用起來不復雜，同時能夠讓開發(fā)工作量不要太大，同時還能讓大部分情景能夠正常觸達正確的結(jié)果，這不是一件簡單的事。

異常邏輯、危機處理？

大部分用戶能夠正常使用功能后，就需要思考一些異常邏輯和危機情況了。這一部分非?？简灝a(chǎn)品經(jīng)理的邏輯思維，從深度、廣度兩個方面全面考驗。這一部分也最容易被團隊其他人發(fā)現(xiàn)邏輯漏洞，分分鐘讓你感覺在直播吃翔。所以，這一塊大家要加把勁，爭取想出每一種異常邏輯，做好危機處理。

還是以兌獎活動為例子說明，一個兌獎活動頁，目的是為了讓某客戶端裝機量上升，那么必須設定該活動頁必須在該客戶端中輸入，才能跳出兌獎網(wǎng)址（該客戶端帶瀏覽器功能）。那么異常邏輯可能就有：

用戶不在客戶端里輸入網(wǎng)址

用戶在斷網(wǎng)情況下在客戶端/其他瀏覽器輸入網(wǎng)址

用戶超過活動時間后才輸入活動網(wǎng)址

…………

爭取需要的資源

完成上面的步驟后，就需要跟項目組要資源了。

項目成員 ：完成產(chǎn)品開發(fā)工作所需的程序員（前端、后臺、運維等），設計師（交互、視覺），測試，運營，商務等。

硬件資源 ：服務器，宣傳物品等

數(shù)據(jù)反饋

這部分也是非常重要的，你做出了一個產(chǎn)品，肯定是需要知道它的市場反饋如何，得到反饋后，才能決定下一步該怎么走。這里就需要設計數(shù)據(jù)反饋系統(tǒng)，訂立考核指標。

訪問量

轉(zhuǎn)化率

留存率

用戶活躍天

產(chǎn)品收入

任務、活動完成量、質(zhì)量

完成以上步驟，一個完整的PRD閉環(huán)就做好了，這下子，可以去找其他人PK了，做得足夠認真的話，應該就不用直播吃翔了，可以挺直腰板當大爺了。這個世界就是一個“ 要么你是大爺，要么我是大爺 ”的世界，各位還是爭取自己當大爺吧。

注意事項：坑，還是很多的

這部分說明一下具體寫PRD時，需要注意的事項。

換位思考

寫PRD一定要時刻想著換位思考，你得想著你的文檔是給開發(fā)、設計、測試等看的，語言上盡量好理解，盡量不要用形容詞，描述功能時，可以嘗試用開發(fā)的邏輯去思考書寫方式。

不要求大求全

這部分是我踩的一個深坑，我之前總想著把所有的邏輯都整理在一個流程圖上，然而這在很多情況下是不可能的，除非你做的這個產(chǎn)品比較簡單。即便你真能夠?qū)⑺羞壿嬚碓谝粋€流程圖上，那么這個流程圖也會很復雜，不容易讓團隊其他人看懂。 功能最好分點說明，正常邏輯和異常邏輯分開說明 。

所見即所得

這是一個讀圖的時代，圖片展現(xiàn)是最清晰明白的。有的功能點，邏輯比較復雜，這時可以考慮用原型圖展現(xiàn)，原型圖可以做到所見即所得。

實現(xiàn)進度如何？

在PRD之外，最好再做一個項目進度表，這份表格要做到及時更新，讓整個團隊知道項目的進度。

關(guān)于語病和錯別字

一份優(yōu)質(zhì)的PRD，最好達到新聞稿的校驗程度，基本不要有語病和錯別字。語病和錯別字太多的話，容易讓大家覺得你很不嚴謹。

排版標準

排版一定要有一套標準，保證你的每一份PRD都按照同一份標準。排版力求美觀大方，字體、顏色、字號、行間距等方面都需要有一定的選擇。

好了，以上基本將PRD的理論知識介紹了一下， 我所說的，可能都是錯的 。說了那么多，其實PRD的作用就是讓其他人幫你干活。一個極致的情況，模仿全棧工程師，我提出一個“全棧產(chǎn)品經(jīng)理”的概念。當一個產(chǎn)品經(jīng)理強悍到精通策劃、前端開發(fā)、后臺開發(fā)、設計、測試、運營、商務等，那么這種人我稱Ta為“全棧產(chǎn)品經(jīng)理”。

如果你是全棧產(chǎn)品經(jīng)理，那么上面我說的關(guān)于PRD的東西可能對你來說都是垃圾，你自己就能做完所有的事情，請你務必要加我微信，讓我膜拜你一圈。但即便你是全棧產(chǎn)品經(jīng)理，能一個人完成所有工作，但是完成時間肯定會很長，效率肯定會下降。所以，廣大PM兄弟姐妹們，咱們還是老老實實寫PRD吧！

產(chǎn)品經(jīng)理prd文檔模板的介紹就聊到這里吧，感謝你花時間閱讀本站內(nèi)容，更多關(guān)于產(chǎn)品經(jīng)理mrd范本、產(chǎn)品經(jīng)理prd文檔模板的信息別忘了在本站進行查找喔。