如何輸出一份高質量PRD?

專業真的很重要!產品總監手把手教寫文檔,10天訓練營,系統學會產品經理必備7大文檔能力。了解一下>

筆者之前梳理過產品自查表,但是還是有很多小伙伴詢問關于PRD的模板和資料。所以本文特地梳理了PRD的內容,希望能給你帶來啟發與思考。

John之前梳理過產品自查表,但是還是有很多小伙伴經常問John關于PRD的模板和資料。所以我今天梳理下PRD的內容,看完這篇文章,如果還不清晰,直接來找John吧。

不知道大家在讀完《寫了30+產品需求文檔后,我對PRD有了新的認知》后,有沒有相關的思考:

  • 總覺得PRD是有規范的 ——其實沒有規范,但是需要讓團隊的小伙伴能看懂。
  • 可能你PRD寫了幾萬字,技術只花了10分鐘就看完了。剩下的時間都在找你問細節。
  • 在產品評審時,你發現寫的PRD忽然變得很陌生。
  • ……

可能很多小伙伴下載一個所謂的PRD模板,把其中的內容進行替換,最后發現只剩下“產品功能”這部分自己還看得懂。其它地方連自己都不能理解。導致產品要么沒有可讀性,要么需求不明晰,團隊溝通需求成本極高。

與其說是產品經理偷懶行為,不如說壓根不清楚PRD,不得其法。接下來John根據自己的經驗來聊下PRD文檔如何更清晰地闡述。

一、PRD的定位

在John梳理的產品經理工作流中,PRD承接的是產品經理把業務需求梳理成產品需求對接給項目組的其他小伙伴。所以重要性不言而喻。首先你明確兩個問題:

  1. 產品實現的過程中,誰會看PRD?——角色包括:產品伙伴、研發、UI、測試、運營和客服等團隊成員
  2. PRD是否能清晰的表達這個版本的需求?——這版本需要做什么?用戶路徑是怎么樣的?版本的整個功能架構,對應的原型和邏輯

產品經理需要清晰地知道PRD最重要的包含哪些內容,才能在評審會上不至于有分歧。

二、PRD的結構

在現階段一般是敏捷開發、注重的是項目管理和溝通高效。PRD最重要的是適合你的團隊配合。但是最基礎的PRD結構可以通過如下的腦圖來總結:

其中整體呈現出來如下圖所示(全部在Axure呈現出來):

1. 產品歷史版本規劃

主要是說清楚每個版本功能迭代的目的是什么。其中包括編輯的時間、上線版本號、具體的內容、功能架構和用戶路徑(方便點擊跳轉)、原型版本號和修訂人。如下圖展示:

2. PRD階段

經常有小伙伴問John,PRD是每個版本分開寫還是聚合寫在一起。其實你會發現,分開寫之后,查看對應的文章就很麻煩,且不容易管理。所以John最后就采用這種管理方式。

2.1 功能架構圖

首先建議輸出功能需求池,說清楚有哪些功能需求。如下圖:

然后針對需求池輸出對應的功能架構:

輸出功能需求池的目的是產品經理更好的存檔。功能架構方便項目組的伙伴更好的清晰每個版本所對應的模塊是什么?

2.2 用戶路徑流程圖

輸出用戶路徑是為了清晰每個模塊之間的跳轉關系和路徑。做到整體流程無遺漏無缺失(重點是一定要說清楚)。

單一用戶多模塊操作的泳道圖:

多用戶多模塊操作的泳道圖:

2.3 原型

John之前說過,原型是最不重要的,但是它是最基礎的。如果你原型都不能保障,那建議先去好好練習基本功吧。

其中仔細看會發現,初始的頁面,配套寫清楚邏輯,加上交互的點擊事件說明。只要會閱讀的技術,都能很清晰地看清楚內容。

附:如何輸出高質量的PPT

 

作者:John,產品狗一枚,微信公眾號:產品狗聚集地。歡迎一起溝通交流。

本文由@John 原創發布于人人都是產品經理,未經許可,禁止轉載。

題圖來自Unsplash, 基于CC0協議。

給作者打賞,鼓勵TA抓緊創作!
評論
歡迎留言討論~!
  1. 受教了,感謝作者

    回復
  2. 講道理,這篇文章真的可以?。?!就是有些圖片的內容看不清,遺憾T T :arrow:

    回復
  3. 受教了

    回復
    1. 可以去公眾號:產品狗聚集地,那邊有大座

      回復
  4. 什么叫CCO協議?

    回復
  5. 受教了大佬 ;-)

    回復
    1. 可以去公眾號:產品狗聚集地,那邊有大座

      回復
北京赛车投注