Mr.T

Nov 23, 2019

8 min read

產品思維:身為產品經理PM必懂的基礎文件撰寫 — PRD? Proposal? Spec?

什麼? PRD是什麼?能吃嗎? 那不是軟體產業PM才有的東西?

PRD可謂是產品經理最基礎的工作「文件」之一,每個產業只要是身為產品規劃者的必經之路,只是名詞的不同。說到「文書處理」很多人嗤之以鼻,畢竟可是吃力不討好的工作,那…還有存在的必要性嗎?

無論是產品經理、專案經理、產品負責人往往會被排山倒海的「溝通」淹沒,為了不被淹沒或是假性失憶,那只好白紙黑字寫下來,畫押!?但文件的畫押又充滿各種妖魔鬼怪的名詞,每個圈子的不同造就名詞的不一,但其實本質都相同。

你可能聽過這些名詞:Roadmap、Proposal、Release Plan、PRD/MRD/BRD、SRS。之所以寫這篇文,也是常被詢問幾個類似問題

本篇文章取自個人經驗,與PM361社群的分享者Ian。歡迎彼此交流。
(O)會描述的內容
一、Product Roadmap 與 PRD 的基本要素與異同
二、在使用前後,需要知道的原則
三、個人撰寫經驗
四、神秘連結
(X)不會描述的內容
* PRD 涵蓋內容
* PRD 最佳工具介紹

每個文件要落地生成都很不簡單,每個產出過程都是血與淚的故事

此圖作者為當時PM361交流會的講者 Ian Wu

Product Roadmap 與 PRD (Product Requirement Document) 的基本要素與異同

Product Roadmap 產品路線圖,描述的是產品策略的時間路徑。

描述1年到5年的產品策略方向,基本上以「粗略時間」為區間,規劃的「產品願景的策略方向」。再詳細的內容與時程就會成為「Release Plan」而非「Product Roadmap」。若欲知詳情可以看參考下列文章。

PRD 產品需求文件,描述的是產品功能規格與實現方式。

規格文件!那就是產品誕生出來的組成要素與緣由。千萬別問要寫得多細節或多粗略,摸摸你的良心,拿捏你的時間,這真沒有標準答案。

太抽象了嗎?想像你要跟朋友描述一杯咖啡製作內容。你可以說

(等等…這不是廢話嗎,於是你又補充了)

(嗯,好像又多瞭解點,所以呢,於是你又多補充)

此圖作者為當時PM361交流會的講者 Ian Wu

在使用前後,需要知道的原則 — 溝通、歷史紀錄、自我保護

溝通、溝通、溝通。認清楚誰是Stakeholder (利害關係人),他們需要什麼,為何需要,以及想要達到什麼目的

設計人員、測試人員、開發人員,每個角色在乎的重點不一樣,而組織中的分工怎麼進行,大家如何推動產品往前進,才是重點!如果為了寫文件造成開發失焦、產品延後上市、錯估使用者需求,那才是本末倒置。

但真的是這樣嗎?

始於溝通,終於溝通。文件是多方向的理解與更新,不會有最詳細的文件,也不會有最完美的文件。

使用、使用、使用。用什麼呈現方式不是重點,重點是真的有被派上用場

到底該用WORD? PPT? EXCEL? 還是用線上工具? 又或是不同文件怎麼整合?

我們該重視的是什麼?應該是內容與協作吧!既然如此,應該朝向大家都看得懂、啃得下去、願意去看的方向。格式固然重要,但有時當所有內容都定義完成,要全部翻新「格式」與「文件呈現方式」時,那可是大工程,中間的時間不但不能去做日常產品開發,更有可能最後成效不如預期。除非…找新人做或是加班製作。

精細規劃寫的多麽完美,沒人看,或是敷衍地看有什麼用?即使再怎麼道德勸說,不是每個人都願意說出「不願意使用的原因」。

視優先程度更新文件格式與呈現方式,有人看、省時間的協作,比自以為的完美呈現有有用。

歷史紀錄與自我保護:何時撰寫,誰該撰寫,該如何分工比較好

最常遇到的問題:「不是啊!這干我什麼事情,我負責開發/設計就好,PM不就是為了產生文件而存在的嗎」、「你開的規格你最瞭解,不是你寫那會是誰寫啊」。

有的PM甚至要寫技術文件,但有的又會有專項的工程師自行撰寫與相互協調,這就看組織分工的藝術。至此可以先拆分幾個環節參考。

平行的協作模式

垂直的協作模式

踢皮球大賽不好玩,PM跳出來玩政治議題的同時,把各自的遊戲規則講清楚

個人撰寫經驗

以下簡易分享兩個個人習慣,但這就未必通用於每個組織,必須隨著當下文化而調整。

建目錄、設編號:

如同「圖書管理系統標籤」、「資訊架構的階層設計」,都有助於我們在查找資料時更有效率,這也是為了在不同跨文件格式時,很好的索引。

source: PIXNET

拆用途、建連結

適合Roadmap, Flowchart, Mockup製作的文件各有不同,分別可能有PPT, Draw.io, Sketch/Zeplin。當每個各自的負責人皆有其團隊時,要把做好的文件「再度」統合又是大工程,那可以參考用網頁連結或是文件連結方式,可以達到幾個效果

當然也會有缺點

四、神秘連結

source: Link

結論

溝通與使用、功能歷史紀錄、自我保護。這三者都是我們撰寫PRD的重要目的

後記2021年4月26日

原先於文章開頭已標明文章參考講者內容以外,同時新增圖片出處,避免有人誤會是原創。原文撰寫後半年,講者本人Ian Wu已有寫獨立專文,且於各媒體報導,歡迎大家前往閱讀與交流 — 「PM產品文件指南 — Product Manager 必掌握的PRD/SPEC心法與撰寫教學」。

如果你喜歡這篇文章,歡迎多拍拍手👏,讓我們多多互動。
1. 👏[1個拍手] — 如果你單純路過
2. 👏👏[2-N個拍手] — 如果你喜歡這篇文章
3. 👏👏👏[50個拍手] — 如果你希望看到類似的內容
有任何互動或想法,歡迎寄信聯絡我:tianchen.tw@gmail.com

.

#PM361° - PM知識社群 #玩轉PM思維 #打造共享網路
本文章為非營利社團PM361°的2019年11月主題聚會分享主題的部分內容。
想跟更多PM夥伴討論此主題,歡迎加入PM361°PM FB社團進行更多交流,新型態聚會將於2020年重新展開。請在申請加入時,說明您是從PM361° Medium專欄中得知本社群的。有任何合作或其他互動,請聯絡PM361°的發起人-Chaoyen:chaoyen_wu@outlook.com

You can’t connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future.