今天給各位分享產(chǎn)品經(jīng)理prd文檔模板的知識，其中也會對產(chǎn)品經(jīng)理mrd范本進(jìn)行解釋，如果能碰巧解決你現(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)鍵，因?yàn)楫a(chǎn)品迭代過程會有不同的文件版本，一般命名規(guī)則“公司名+產(chǎn)品名+PRD+D1.0”（以第一版為例），這樣命名有利用版本號的迭代。

2、修訂控制頁

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

3、目錄

4、請與以下部門討論P(yáng)RD

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

5、概述

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

6、使用者需求

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

7、可選方案

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

8、效益成本分析

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

9、功能需求

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

10、整合需求

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

11、BETA測試需求

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

12、非功能性需求

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

13、上、下線需求

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

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

14、運(yùn)營計(jì)劃

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

……

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

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

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

一、商業(yè)價(jià)值

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

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

二、歷史回顧

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

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

3、之前的實(shí)際運(yùn)營效果和計(jì)劃的差異是什么？為什么？

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

2、 通過哪些功能來實(shí)現(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)品文檔中最底層最細(xì)致的文檔。文檔側(cè)重對產(chǎn)品功能和性能的說明，主要是把產(chǎn)品規(guī)劃與設(shè)計(jì)中的產(chǎn)品流程，界面，功能等定義向研發(fā)、設(shè)計(jì)、測試等團(tuán)隊(duì)做清晰的描述說明。

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

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

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

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

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

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

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

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

還有老板、項(xiàng)目經(jīng)理、運(yùn)營、市場、客戶、財(cái)務(wù)……

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

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

原型圖模式 ：Axure。追求時(shí)間效率靈活性的團(tuán)隊(duì)，建議選擇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ǔ)上對局部功能進(jìn)行了升級或調(diào)整。

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

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

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

修訂記錄的作用：

對修改前后進(jìn)行比較

有利于維護(hù)和管理PRD

記錄修訂人和修訂日期

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

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

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

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

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

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

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

......

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

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

3、功能清單：清單包括功能模塊、功能點(diǎn)、功能描述等。

4、功能詳情：原型設(shè)計(jì)、功能說明和用例。

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

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

注意：

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

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

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

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

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

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

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

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

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

閱讀原文

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

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

PRD是什么？

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

什么是PRD？

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

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

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

PRD是給誰看的？

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

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

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

你知道PRD有多重要嗎？

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

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

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

PRD閉環(huán)

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

你的目的是什么？

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

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

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

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

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

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

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

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

完成功能需要的邏輯？

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

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

異常邏輯、危機(jī)處理？

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

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

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

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

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

…………

爭取需要的資源

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

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

硬件資源 ：服務(wù)器，宣傳物品等

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

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

訪問量

轉(zhuǎn)化率

留存率

用戶活躍天

產(chǎn)品收入

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

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

注意事項(xiàng)：坑，還是很多的

這部分說明一下具體寫PRD時(shí)，需要注意的事項(xiàng)。

換位思考

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

不要求大求全

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

所見即所得

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

實(shí)現(xiàn)進(jìn)度如何？

在PRD之外，最好再做一個項(xiàng)目進(jìn)度表，這份表格要做到及時(shí)更新，讓整個團(tuán)隊(duì)知道項(xiàng)目的進(jìn)度。

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

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

排版標(biāo)準(zhǔn)

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

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

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

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