PM 文件指南 - 產品經理一定要掌握的 PRD/SPEC 心法與撰寫教學

作者 Ian Wu,產品經理。科技人。互聯網 | 熱衷社群、熱愛挑戰、享受生活,以持續提升自己為目標 | 保持好奇心與行動力,探索跨領域新事物。As Product Manager, Rich Our Life, Change Our World. Email。
原文刊登於 medium,INSIDE 經授權轉載。
做為一個產品經理,撰寫需求文檔可說是產品經理 PM 無可避免的任務,同時要思考如何將產品規劃內容清楚表達給利害關係人 (Stakeholder) 了解並獲得支持。
在探討該問題時,我們回歸到人與人之間如何進行有效的資訊傳遞?口說與文字(文件)。
面對面溝通是最有效率傳遞資訊的方式,但隨著每天資訊爆炸與時間過去,我們 99% 已經忘記當時做某件事的時空背景與思緒;然而文字則是替我們保留了關鍵節點與脈絡,讓我們能夠回頭檢視與探討。
撰寫文件可說是產品經理最基本的工作。每個產業中,無論是產品經理、專案經理、產品負責人往往會被各式各樣的「會議溝通」填滿,為了有所考察與依據,許多文件需求與撰寫因此誕生了。舉個例子,軟體業常撰寫 PRD(Product Requirement Document),硬體業常寫 SPEC 文件(Product specifications),每個領域有不同的說詞,但其屬性與功用其實大同小異。
2019 年我在 #PM361° — PM 知識社群與大家分享過這個主題,這篇就回顧一下,來聊聊軟體領域常用的 PRD 以及概述他的兄弟好友們,BRD 與 MRD。
說到這裡,大概有不少人對「PRD」是抱持各種疑問與是否有必要存在的眼神?常被討論的問題不外乎如下:
BRD 在告訴利害關係人目前要進行的專案的商業價值與商業策略,短小精簡,沒有太多產品細節,主要溝通對象是高階管理者 C-Level(eg:CEO、CTO、COO)。
為什麼要做這件事?商業價值是什麼?向 C-Level 闡明值得投入時間與金錢進行這項投資。
我將 BRD 文檔中主要項目概括整理如下:
MRD 在告訴我們市場概況,我們要前進的戰場的情報概覽與分析,強調市場各種現況以及趨勢,屬於承上啟下的文檔,承接 BRD 開啟 PRD 方向,主要溝通對象主管、產品、運營、研發等團隊。
市場現況是什麼?存在機會是什麼?產品價值定位與主張在市場的哪裡?向產品、運營、研發等團隊以及主管說明產品模式、業務模式、運營模式、市場模式等,明確客戶及市場方向!
我將 MRD 文檔中主要項目整理概括如下:
PRD 著重於產品實作方法與流程,涉及交互、文案、頁面邏輯等,具體將產品各個細節解釋清楚,向研發團隊、設計團隊、測試團隊、UX 團隊等說明產品規格
產品功能是什麼?邏輯流程是什麼?交互流程是什麼?use case 有哪些?錯誤態如何處理以及時間、人力、資源等配置,向開發團隊說明清楚。
我將 PRD 文檔中主要項目整理概括如下:
💡BRD — MRD — PRD是一個從高層次到低層次的關係,BRD從策略高度告訴我們做什麼產品,MRD從戰術的觀點告訴我們怎麼突圍,PRD非常細化的告訴我們產品做成什麼樣。
溝通,對象是誰?為了什麼目的?什麼時候進行?如何進行?
先歸納 PRD 要面對的利害關係人,如工程師、設計師、UX 等,決定要對他們表明什麼目的,每個角色重視的點都不同;是分別說明或是集中說明;文件撰寫方式是協作或是單一人撰寫。別忘記我們的目的是推動產品開發,如何藉由這份文件跟各角色溝通,讓他們「清楚知道」目標(Goal),如何拆解進行任務(Task),產出產品才是最核心價值的地方。
文件本身格式是有彈性,需多方向的理解與更新,不會有最完美的文件範本,不斷嘗試找出適合團隊的文化,就是最有效的方式。
💡Tips:
歷史紀錄,過去做了什麼?原因是什麼?邏輯方法是什麼?
紀錄是用來復盤與釐清走過的道路,產品會不斷的堆疊上去,債務會不斷的累積,良好的紀錄是幫助我們遇到問題時,可以知道從什麼地方切入與檢驗,同時可以檢視產品開發的過程脈絡,減少猜測與不確定性。另一個面向就是當產品交接給下一任產品經理時,該產品經理會比較容易上手,增加 onboarding 效率。保持善念,不要留黑盒子(屎)給接手的人。
自我保護,白紙黑字留底,別讓口說無憑困住你。
遇到這樣的對話,大概悔恨自己當初怎麼不寫文件,然後被迫吃下去,同時還要扛下產品責任,在老闆面前丟失 credit。
💡Tips:
溝通、歷史紀錄、自我保護,利大於弊,花點時間投資,長遠來看是有助益個人與組織發展。
換位思考,站在閱讀者、實作者的角度來思考。
複習一下,PRD 有溝通、歷史紀錄、自我保護等主要三價值。先確認你的目標是什麼,探究問題,定義問題後再去嘗試解決。例如,是要拿來跟工程師溝通產品流程,但是寫完了他們都不看,一直跑來問我,那不如不要寫?
Step 1:確立目標,「工程師,產品流程闡述」
確立溝通對象是工程師,目的是讓他們清楚了解產品流程設計
Step 2:定義問題,他們不看文件,跑來問我!
那他們不看的理由是什麼?動機是什麼?分析一下可能原因
Step 3:可能解決方法
針對定義好的問題,站在對方角度來思考嘗試提出解決方案。
文件只是一個溝通的工具 ,跟自己溝通(釐清思緒)、跟團隊溝通(闡明任務)、跟未來交接同事溝通(Onboarding)。
文字,具有保存性與可傳遞性,在時間與空間轉換的情況下,能夠讓所有人得到一致的訊息,確保大家都在同一個溝通平面。從公司角度來看,文件也是提供知識資產的保存,員工來來去去,如何將公司特有知識傳遞下去,文件就是其中一種方式。
產品開發大概會經過,Understand、Define、Sketch、Prototype、Development、Validation 等,把 PRD 作為產品來展開,思路其實差不多。
Step 1: 建立目錄、索引
涵蓋的欄位有版本號、項目、優先序、負責人、發布日期,相關文件連結等等,主要目的是幫助在看文件前可以清楚知道這份文件的基本資訊,幫助查找。
Step 2:需求闡述
涵蓋內容有目標、背景資訊、價值、方案、驗證指標、附件
Step 3:佐證需求
提供支持該需求的佐證,可能是數據、市調、競品分析等,強化需求可行性,同時是展現分析能力與洞察力的地方,提高團隊對我們的信任度。
Step 4:審查(優化內容)
Step 5:回饋與疊代(訂模板,非第一次可跳過該步驟)
Step 6:更新(資訊補充或是補齊)
There is no perfect standard for PRD.
Think about what PRD does and deliver it with empathy.
網路上其實有很多 PRD 的範本資源與其他產品經理如何應用撰寫,可多搜尋,其中個人認為中國網路這部分很多大佬分享與分析,可多多參考培養自己的方式。
關鍵字:PRD、Product Requirement Document、Product SPEC、產品規格書、產品規格文件、產品開發文件、需求文檔、規格說明書、產品設計文件、PRD 撰寫、PRD 範本、PRD 範例等等。
責任編輯:Mia
核稿編輯:Chris