MRD和PRD的寫作真的是仁者見仁智者見智，沒有固定的格式，只要能說明清楚問題就行。

我本人是不想講這部分內(nèi)容的，但是為了體系的完整，暫且簡要講一下，本文的內(nèi)容基本是我以前學(xué)習(xí)時記錄的，沒有太多的修改。

本文結(jié)構(gòu)如下：

No.006 如何寫出好的MRD和PRD.png

一、MRD

MRD（Market requirements document，市場需求文檔）。

獲得老板們的支持后，產(chǎn)品進(jìn)入實施階段，需要寫出MRD，要有更細(xì)致的市場與競爭對手分析，包括可通過哪些功能來實現(xiàn)商業(yè)目的，功能、非功能需求分哪幾塊，功能的優(yōu)先級等等。實際工作中，PM在這個階段常見的產(chǎn)出物有產(chǎn)品的feature list、業(yè)務(wù)邏輯圖，這是從商業(yè)目標(biāo)到技術(shù)實現(xiàn)的關(guān)鍵轉(zhuǎn)化文檔。

MRD到底要干什么?

用繞口的方法來說：如果說BRD是你拋出的論題，那么MRD就是要你用論點來支撐你的BRD，同時通過論證來得出你采取什么方式獲得BRD里面的商業(yè)目標(biāo)（講究邏輯性）。

用大白話來說：MRD就是經(jīng)過一系列的分析后，拿出一套你認(rèn)為最合理的干某個事情的方法與指導(dǎo)實施的文檔。

1、匯報對象

未來參與產(chǎn)品的各個層級的同事，都有可能要閱讀MRD，包括產(chǎn)品經(jīng)理自己。

MRD是最完善的產(chǎn)品誕生分析描述文檔，以后的一段時間，產(chǎn)品的各種衍伸文檔、產(chǎn)品依據(jù)、團隊判斷，都可能參考MRD文檔。

產(chǎn)品參與成員需要了解產(chǎn)品的各種背景、數(shù)據(jù)、方法依據(jù)。

2、MRD內(nèi)容結(jié)構(gòu)

1.文檔說明

1.1 文檔基本信息

公司名稱；產(chǎn)品名稱；文檔創(chuàng)建日期；創(chuàng)建人；創(chuàng)建人聯(lián)系方式；部門；職務(wù)。

1.2 文檔修改記錄

日期；版本；修改人；修改內(nèi)容；審核人。

1.3 文檔目的

用于說明相關(guān)市場，用戶，產(chǎn)品規(guī)劃，核心目標(biāo)，產(chǎn)品路線圖，項目規(guī)劃等。

1.4 文檔概要

文檔說明；市場說明；用戶說明；產(chǎn)品說明。

2.市場分析

2.1摘要（可選）

2.2現(xiàn)有市場存在的問題與機會

就互聯(lián)網(wǎng)而言，可以從以下（但不限于）幾方面來選擇性表述：

• 產(chǎn)品方面（例如：產(chǎn)品形態(tài)復(fù)雜，用戶體驗差）
• 技術(shù)方面（語音壓縮技術(shù)不成熟，外資搜索引擎對中文理解不夠深刻）
• 運營方面（產(chǎn)業(yè)鏈偏下游，重實體，輕線上，造成瓜分線下旅行社利潤，形成對立）
• 用戶方面（用戶需要可替代產(chǎn)品尚未出現(xiàn)，需求明顯）
• 商業(yè)模式方面（金山毒霸和360安全衛(wèi)士的商業(yè)模式對比）

由于在以上的分析說明中，可能會涉及到用戶分析相關(guān)的內(nèi)容，可以先提用戶分析的結(jié)果并說明詳見用戶分析章節(jié)即可，這樣可以保證文檔的完整連續(xù)性，也能簡明扼要。

2.3目標(biāo)市場分析（基于該機會點下的市場分析說明）

• 市場規(guī)模：多少錢，成功可能大不大，往往是正比，但不絕對是，具體問題具體分析
• 市場特征：現(xiàn)有市場表現(xiàn)出的典型特征
• 發(fā)展趨勢：未來2-5年的發(fā)展評測，搜索市場的語音搜索，蘋果的Siri，體感便攜設(shè)備：谷歌眼鏡，蘋果iwatch）
• 時間邊界：這個市場的持續(xù)時間預(yù)估

2.4 市場分析結(jié)論

一般來說，這里會得到一個比較有市場商業(yè)價值的結(jié)論，否則，這個文檔就沒有存在的意義了

3.用戶分析

3.1 目標(biāo)用戶群體（找準(zhǔn)）

一般劃分維度：年齡段，收入，學(xué)歷，地區(qū)

3.2 目標(biāo)用戶特征

所謂特征，及時在這個群體下面的共性特點與非共性特點（分析）

3.3建立虛擬用戶角色（形象化）

• 常用用戶特征（年齡；性別；出生日期； 收入；職業(yè)； 居住地；興趣愛好；性格特征）
• 用戶名稱(張三，李四，王麻子)
• 用戶技能（熟練使用電腦辦公，對常用的智能手機應(yīng)用諳熟于心）
• 與產(chǎn)品相關(guān)特征
  • 電子商務(wù)產(chǎn)品：購物習(xí)慣，年度消費預(yù)算等
  • 交友類：是否單身，擇偶標(biāo)準(zhǔn)
  • 游戲類：是否喜愛3D游戲，是否有同類型游戲經(jīng)驗等

3.4用戶角色卡片

針對目標(biāo)用戶群體進(jìn)行歸類劃分，抽取典型樣本，數(shù)量不限，帶需要能代表目標(biāo)用戶。

3.5 用戶使用場景

建立了用戶卡片以后，把這些典型用戶放到實際的使用場景中去。

此處的用戶使用場景更多是產(chǎn)品經(jīng)理在分析完成用戶使用場景后的演示性場景。

注意分析場景與演示場景的區(qū)別：

用戶使用場景就是描述用戶在某個環(huán)境中完成某個了某個任務(wù)的故事。類似小學(xué)學(xué)習(xí)的八股文中的記敘文三要素：時間，地點，人物+干了什么事情+干事情的步驟。

3.6 用戶動機總結(jié)（讀懂表象）

線下的在線商品比較與查詢渠道等

3.7 用戶目標(biāo)總結(jié)（明確實質(zhì)）

獲得性價比最高的購物體驗，完美主義者會因此很得瑟，哪怕是便宜了1元錢也很得意

3.8 影響用戶使用的主要因素（重要，分析）

• 是否隨身攜帶接入設(shè)備
• 網(wǎng)絡(luò)是否通暢
• 查詢速度
• 設(shè)備對商品信息的獲取是否會對用戶造成不便

4.產(chǎn)品說明

4.1 產(chǎn)品定位

產(chǎn)品有越做越復(fù)雜的可能，但在一定時間內(nèi)，定位決定了產(chǎn)品的一切。

產(chǎn)品定位與市場定位是有區(qū)別的，但經(jīng)常容易混淆:：

• 市場定位：我們對用戶或者用戶市場的選擇，例如:手機發(fā)燒友，白領(lǐng)，或者移動通訊設(shè)備市場
• 產(chǎn)品定位：我們用什么樣的產(chǎn)品滿足用戶或用戶市場，例如：
  • 陌陌：一款基于地理位置的移動社交工具
  • 飛聊：興趣社交APP

用戶定位的描述：針對什么目標(biāo)群體，做什么事情，用最本質(zhì)的，無修飾的語言表述。

4.2 產(chǎn)品核心目標(biāo)（產(chǎn)品本身要達(dá)到什么一個目標(biāo)）

互聯(lián)網(wǎng)產(chǎn)品的核心目標(biāo)，往往表現(xiàn)為要解決目標(biāo)市場（目標(biāo)用戶）一個什么問題。這個問題分析的越透徹，產(chǎn)品的核心目標(biāo)也就越準(zhǔn)確 ，確立好核心目標(biāo)，不會使我們產(chǎn)品推進(jìn)的過程中迷失。

例如：

• 360安全衛(wèi)士：解決用戶使用電腦的安全問題

• 微信：在最早的階段，微信的核心目標(biāo)是工具類的，為用戶提供流暢語音溝通的移動應(yīng)用

通常來說，解決核心目標(biāo)的工作優(yōu)先級是最高的。產(chǎn)品任務(wù)，很多應(yīng)該是圍繞核心目標(biāo)來開展的。所以，產(chǎn)品經(jīng)理對于用戶需求與產(chǎn)品核心目標(biāo)關(guān)系的拿捏是個很重要的工作。

4.3 產(chǎn)品結(jié)構(gòu)（注意，不是功能結(jié)構(gòu)，是產(chǎn)品的整體結(jié)構(gòu)）

產(chǎn)品的市場定位，產(chǎn)品定位，核心目標(biāo)的直接表現(xiàn)。

4.4產(chǎn)品路線圖

產(chǎn)品路線圖是產(chǎn)品成長中的每個任務(wù)節(jié)點組合而成，是以任務(wù)為導(dǎo)向的時間節(jié)點圖。

應(yīng)注意一下，任務(wù)一定是和產(chǎn)品定位，核心目標(biāo)等相符合的，是達(dá)到這些目標(biāo)的任務(wù)分解。

產(chǎn)品規(guī)劃路線圖.png

4.5產(chǎn)品功能性需求

在線留言板舉例：

• 注冊與登陸（直接注冊，第三方注冊，直接登陸，第三方登陸）
• 交流（留言，回復(fù)，圖片上傳，文字發(fā)布）
• 管理（查看，刪除，修改）

4.6產(chǎn)品非功能性需求

• 埋點需求：為了便于數(shù)據(jù)分析需要做相應(yīng)的埋點
• 性能需求：產(chǎn)品流暢、不卡頓等
• 擴展性需求：產(chǎn)品與技術(shù)架構(gòu)都要可擴展
• 安全性需求：做好各種攻擊、爬蟲的防范
• 健壯性需求：產(chǎn)品要足夠健壯，不崩潰、不宕機，可以算入性能需求
• 兼容性需求：要兼容各主流瀏覽器、手機系統(tǒng)、屏幕尺寸等
• 可用性需求：產(chǎn)品的基本需求要滿足可用性原則
• 運營需求：運營的一些數(shù)據(jù)統(tǒng)計、活動運營等需求
• 用戶體驗需求：好的產(chǎn)品一定用戶體驗好

3、產(chǎn)品結(jié)構(gòu)與功能結(jié)構(gòu)的區(qū)別

這里我們把整個產(chǎn)品看成是一桌菜。

產(chǎn)品結(jié)構(gòu)講的為了讓客人吃的舒服同時又要完成我們的核心目標(biāo)，我們需要哪些菜品，而這些菜品與菜類需要我們事先規(guī)劃出來：

• 涼菜：涼拌則耳根，夫妻肺片等
• 熱菜：佛跳墻，麻辣雞絲等
• 主菜：宮保雞丁 蒜蓉蝦 烤扇貝
• 甜點：地動山搖，巧克力布丁
• 飲料：酸奶，玉米汁

功能結(jié)構(gòu)：我們?nèi)绾螌崿F(xiàn)上述的各種菜品？

• 加熱：熱菜
• 爆炒：主菜，熱菜
• 材料：則耳根，肺片
• 人員：廚師，墩子

產(chǎn)品結(jié)構(gòu)說明的注意事項：

這里不是扣細(xì)節(jié)的時候，主要產(chǎn)品結(jié)構(gòu)表述到位即可。

因為你之后肯定會非?？啾频淖龇浅＜?xì)的產(chǎn)品說明與線框圖、流程等。

• 一些無法歸類的，放到其它里面
• 如果能配合流程圖與簡單的主要頁面線框圖就更好了，更清楚，更明了

4、優(yōu)秀MRD的特點

• 邏輯性強：有論點，有論據(jù)，有論證
• 把抽象的東西形象化的講出來
• 數(shù)據(jù)可靠，分析有理
• 有把握的主觀，無把握的客觀
• 惜字如金，能把問題表述清楚，絕不多寫一個字
• 合理的產(chǎn)品進(jìn)度分配更有利于研發(fā)人員工作（人有九等，不是所有人的人都是打了雞血的產(chǎn)品經(jīng)理）
• 重視非功能需求
• 如果方案中出現(xiàn)很多專業(yè)名詞，記得在文章的開通呈現(xiàn)給閱讀者一個名字解釋表

5、小結(jié)

MRD內(nèi)容結(jié)構(gòu).png

二、PRD

1、匯報對象

匯報對象：老板、開發(fā)、設(shè)計、測試、運營等。一般我們在做出比較大粒度的PRD之后就會做一次評審，以便盡早發(fā)現(xiàn)問題。

我這里還是特意把匯報對象單獨提出來，因為你的匯報對象決定了你應(yīng)該把文檔寫成什么樣，評審的時候你該怎么講。

你要匯報的對象涉及到多個部門，這些部門的人員素質(zhì)都不一樣，怎樣有效的把PRD描述出來，讓各方都能夠聽懂，是一個很考驗產(chǎn)品經(jīng)理功力的事情。

2、PRD內(nèi)容結(jié)構(gòu)

PRD包括但不限于以下這些內(nèi)容：

1. 文檔說明

1.1 產(chǎn)品說明

• 背景描述：為什么要做這個產(chǎn)品、市場行情
• 業(yè)務(wù)目標(biāo)
• 產(chǎn)品定位
• 用戶群體及其特征

1.2 更新記錄

序號、文檔版本、修訂日期、修訂人、修訂章節(jié)即內(nèi)容、修訂原因、審核人

產(chǎn)品版本的命名：

以產(chǎn)品版本1.2.6為例，1為主版本號，2為子版本號，6為修正版本號。

• 主版本號通常是重大調(diào)整升級、產(chǎn)品結(jié)構(gòu)功能等都有調(diào)整時，進(jìn)行修改。

• 子版本號通常是在原有基礎(chǔ)上對局部功能進(jìn)行了升級或調(diào)整時，進(jìn)行修改。

• 修正版本號通常是局部小范圍優(yōu)化與bug修復(fù)時，進(jìn)行修改。

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

1.3 溝通意見

主要記錄與各部門溝通的歷史，包括溝通部門、溝通人員、溝通內(nèi)容描述、溝通結(jié)果、溝通日期

1.4 名詞術(shù)語表

對于文檔內(nèi)的各個名詞術(shù)語進(jìn)行解釋，包括詞匯名、對應(yīng)的別名、具體的說明。

1.5 數(shù)據(jù)字典

數(shù)據(jù)字典就是數(shù)據(jù)庫各個表結(jié)構(gòu)的描述，用于文檔內(nèi)需求的精準(zhǔn)描述。

1.6 開發(fā)排期

產(chǎn)品經(jīng)理需要把控開發(fā)進(jìn)度，直接在PRD里記錄是其中一個方法。以下是一個示例。

開發(fā)排期.png

1.7 交互自查表

交互自查表是產(chǎn)品經(jīng)理用戶檢查自己產(chǎn)品設(shè)計的工具。

交互自查表.png

2. 產(chǎn)品概念設(shè)計

2.1 產(chǎn)品概念圖

產(chǎn)品概念圖描述產(chǎn)品的大致思路。以下是一個簡單的產(chǎn)品概念圖示例：

產(chǎn)品概念圖.png

2.2 功能結(jié)構(gòu)圖

功能結(jié)構(gòu)圖描述產(chǎn)品有哪些功能。

功能結(jié)構(gòu)圖.png

2.3 信息結(jié)構(gòu)圖

也稱信息架構(gòu)圖，我的理解是產(chǎn)品內(nèi)字段的分類整合，這些信息是研發(fā)人員建立數(shù)據(jù)庫的參考。

我推薦先思考功能結(jié)構(gòu)圖，在做信息結(jié)構(gòu)圖。

信息結(jié)構(gòu)圖.png

2.4 產(chǎn)品結(jié)構(gòu)圖

產(chǎn)品結(jié)構(gòu)圖是按照產(chǎn)品的邏輯與表現(xiàn)方式，結(jié)構(gòu)化的表現(xiàn)產(chǎn)品構(gòu)造的一種示意圖，可以說是產(chǎn)品的頁面功能與信息拆解。

產(chǎn)品結(jié)構(gòu)圖.png

2.5 Feature List

即需求列表。以下是一個簡單的示例：

Feature List.png

2.6 業(yè)務(wù)流程圖

根據(jù)上述各種結(jié)構(gòu)圖，畫出產(chǎn)品內(nèi)業(yè)務(wù)的流轉(zhuǎn)過程，是從產(chǎn)品角度來講的。

畫流程圖的技巧：

• 從主線，到支線

• 從正常流，到異常流

• 不要把整個流程畫到一個頁面里面，可以使用分頁來進(jìn)行調(diào)整，這樣更清晰更易于講解和使用與傳遞。

• 有自己的圖示，表明清楚每個圖示的意思。

業(yè)務(wù)流程圖.png

2.7 任務(wù)流程圖

任務(wù)流程圖就是產(chǎn)品內(nèi)完成各項任務(wù)的流程圖，是從用戶角度來講的，通過用戶行為串聯(lián)信息結(jié)構(gòu)與產(chǎn)品結(jié)構(gòu)，閱讀者通過閱讀用戶使用流程，能更好的理解產(chǎn)品經(jīng)理設(shè)計的用戶行為。。以下是一個小程序登錄的流程圖：

登錄注冊流程圖.png

2.8 頁面流程圖

主要是頁面之間的跳轉(zhuǎn)關(guān)系。

頁面流程圖.png

3. 全局說明

3.1 功能權(quán)限

后臺/B端產(chǎn)品和部分用戶端產(chǎn)品會設(shè)計到用戶使用權(quán)限的管理，此時需要在這里進(jìn)行全局性的說明。

對于復(fù)雜的權(quán)限，也要在相應(yīng)原型旁邊注明權(quán)限。

3.2 全局交互

全局交互.png

3.3 鍵盤說明

輸入特定的內(nèi)容時，彈出特定的鍵盤面板。如輸入銀行卡密碼時，彈出亂序的數(shù)字鍵盤等。

3.4 toast提示

一般設(shè)置1-3秒后消失。

toast提示.png

3.5 dialog彈層

涉及到需要用戶確認(rèn)的場景，屬于強制中斷用戶操作的行為。

dialog彈層對話.png

3.6 加載方式

全屏加載

對整個頁面進(jìn)行加載，可以保證內(nèi)容的完整性，但會讓用戶產(chǎn)生強烈的等待感，3s以上會有焦躁情緒。

所以全屏加載最好要配合上有明確進(jìn)度表示的進(jìn)度條。

上拉加載

常用于信息流、長列表形式的產(chǎn)品，用戶可以一直沉浸在內(nèi)容里。

下拉刷新加載

更多的是承載刷新的功能，比如新聞APP里下拉可獲取更新的信息。

優(yōu)先加載

對于重要內(nèi)容進(jìn)行有限加載。

占位加載

如果網(wǎng)速狀況不好的話，先進(jìn)行占位性的展示。

加載都是需要一定的時間的，為了減少用戶的等待感，我們可以使用非模態(tài)的加載方式，適當(dāng)?shù)慕o一個取消的選項；也可以使用情趣化的加載動畫；或者提前預(yù)加載，對內(nèi)容進(jìn)行緩存；還有就是告知加載進(jìn)度。

更詳細(xì)的加載方式，可以參考這篇文章《常見的七種app加載樣式設(shè)計》

3.7 啟動頁

啟動頁是展示我們產(chǎn)品的信息，還是展示產(chǎn)品的初步引導(dǎo)，又或者是展示廣告，是需要我們綜合考慮產(chǎn)品目標(biāo)、產(chǎn)品生命周期等因素的。

3.8 異常

異常有很多種，網(wǎng)絡(luò)異常、服務(wù)器異常、加載超時等等，但通常我們都把它們當(dāng)做網(wǎng)絡(luò)異常來展示給用戶，并提供說明引導(dǎo)和解決方案。

展示的方式可以使用toast提示、全屏提示、dialog提示等。

3.9 常用字段說明

這些和數(shù)據(jù)字典和信息結(jié)構(gòu)圖息息相關(guān)，我們需要對產(chǎn)品中相關(guān)模塊（如表單填寫、信息展示等）內(nèi)的元素定義格式，比如字段的長度、數(shù)據(jù)類型、是否必填等。這個東西非常重要，是開發(fā)設(shè)計表結(jié)構(gòu)的重要參考。

常用字段.png

4. 詳細(xì)功能說明

詳細(xì)功能說明是整個PRD文檔里占比最大也最核心的部分，我們之后講的內(nèi)容也基本都是這里的東西，現(xiàn)在大家只要了解PRD的內(nèi)容結(jié)構(gòu)是什么樣的就行了。

PRD如果是直接寫在Axure文檔里的話，詳細(xì)功能說明基本就是原型+標(biāo)注了。

標(biāo)注一般就是在原型旁邊寫上視覺說明、交互說明（給開發(fā)看到，最重要）、運營說明等一系列說明。

以前很多人說用Axure寫PRD不方便進(jìn)行版本管理，其實是不對的。我們有三種方式對版本修改進(jìn)行管理：

• 直接在相關(guān)頁面記錄歷史的修改：好處是能看到自己每次修改的演變過程，壞處是文檔會越來越龐大。
• 每次修改都存成一個文件：更好的存檔，但不方面查看。
• 使用Git/SVN等版本管理工具：可以看到查看之前的版本，Axure自帶有SVN。

事實上，我會三個方法同時用。

現(xiàn)在小一些的公司有時是不會做在原型上做完整的交互的，一般會在原型上標(biāo)注交互的規(guī)則。

如果是用Word來寫的話，就要復(fù)雜一些。我就一開始的時候用過Word等文本型的文檔寫PRD，但現(xiàn)在發(fā)現(xiàn)用Axure寫真的很爽。當(dāng)然還有一些產(chǎn)品會用墨刀這樣的快速設(shè)計原型的工具，也是不錯的選擇。我沒怎么用過這種方法，在這里也就不分享了。

5. 非功能性需求說明

在MRD中，非功能性需求是不用詳細(xì)說明的，但在PRD里就需要產(chǎn)品經(jīng)理根據(jù)具體的產(chǎn)品設(shè)計，詳細(xì)說明非功能性需求。這部分內(nèi)容是開發(fā)、運維、測試的重要參考。

6. 上線核查表

這里主要寫明上線需要的各種東西，如：申請App Store賬號、宣傳物料的準(zhǔn)備。

這些都是固定性的東西，我們把它當(dāng)成每次上線前的產(chǎn)品核查表。

7. 運營計劃

產(chǎn)品上線后的運營方案。產(chǎn)品可以先列出一個簡要計劃，然后和運營討論出一個完善的方案。

8. 效果審核表

我們的每一次改版上線，都是基于業(yè)務(wù)目標(biāo)的，所以產(chǎn)品上線后，我們需要追蹤產(chǎn)品是否達(dá)到既定業(yè)務(wù)目標(biāo)。這里會提供上線效果的審核表，包括產(chǎn)品版本、上線日期、預(yù)期結(jié)果、實際結(jié)果等。

3、優(yōu)秀PRD的特點

• 正確 ：確保文檔中的表述與產(chǎn)品經(jīng)理的思路是對應(yīng)且正確的
• 無歧義 ：文檔的表述方便閱讀理解，不會產(chǎn)生歧義
• 完備 ：MECE原則盡量保證對產(chǎn)品功能需求表述的系統(tǒng)完整
• 一致 ：文檔中用詞用語一致，對于同一事物的表述應(yīng)該一樣，避免混用同義詞
• 具有優(yōu)先級 ：產(chǎn)品的功能性需求是有先后主次的，對于一次性規(guī)劃叫多功能的PRD，應(yīng)該注明功能性需求的先后主次
• 可驗證 ：對于功能性的描述，是可以進(jìn)行測試的，而不是不發(fā)測試，無法定性的東西，例如：效率高，交互完美等詞語，都是無法驗證的
• 可修改 ：PRD文檔利于后期的修改與升級
• 可追蹤 ：每個功能性需求的來源應(yīng)該是清楚明白的

4、小結(jié)

我這里提供的僅僅只是模板，大家要根據(jù)實際情況進(jìn)行增減。

PRD內(nèi)容結(jié)構(gòu).png

三大文檔總結(jié)

回顧我們所講的3個文檔（BRD、MRD、PRD），可以發(fā)現(xiàn)三者是一個層層遞進(jìn)的關(guān)系。

MRD可以說是BRD的進(jìn)一步細(xì)化文檔，BRD更多是以PPT的形式呈現(xiàn)，MRD可能就需要用文檔形式呈現(xiàn)了。PRD可以說是對MRD的進(jìn)一步進(jìn)化，PRD可以用Word、Axure等各種形式呈現(xiàn)。

上面的PRD我真的只是在列一個模板，很多細(xì)節(jié)不好講述，如果大家有不明白的可以在評論區(qū)提出來，我會進(jìn)行一一解答。

產(chǎn)品經(jīng)理平時工作中涉及到的文檔還有很多，但都沒有固定性的標(biāo)準(zhǔn)。如果之后我無聊的話，會進(jìn)行一個匯總。

預(yù)告：下一篇將會講《交互設(shè)計與用戶體驗》