產品經理與牠們的文件

本篇適合想要知道產品經理常用產品文件的讀者,我將分享為什麼要寫文件、常見的產品文件與如何善用產品文件來做產品溝通。

1.為什麼要寫文件?

相信許多人都同意「溝通」是產品經理的重要技能,也是每天工作中占比很大的部分。溝通有許多形式,包括口頭、訊息與文件。每個溝通的形式都有各自的好處,例如訊息的好處是是快,適合解決小問題。口頭則是互動性高,透過表情與肢體能知道彼此的好惡,適合來喬重要事情。文件則是適合用於溝通複雜的議題,往往文字的內容也會更加精準。另外,文件也更容易保存與回顧,當記憶逐漸模糊時,文件是個很好的參考。產品開發是個複雜的流程,因此產品經理必須善用文件做溝通。

2.常見的產品文件

產品經理最常處理的產品文件如下:

  • #1.Product vision and strategy:用來溝通產品的長期價值,以及要如何達成該目標。參考範例
  • #2.Product roadmap:用來溝通要達成目標,由近到遠、未來幾個月、幾季該做什麼事情。參考範例
  • #3.Product KPI and metrics:用來溝通如何衡量成功,包含商業成果指標、產品指標,未來特定時間範圍的目標值與指標定義,目前最流行的目標管理方法是透過 OKR。參考範例1參考範例2
  • #4.Prioritized product backlog:用來溝通工作項目優先性,通常為一經過排序的需求項目列表。參考範例
  • #5.Product requirements documents(PRD):用來溝通產品需求之文件,包含用戶問題、解決方案、方案規格、產品指標等。PRD 的規格撰寫方式差異蠻大的,有人透過用戶故事(user story)來呈現方案規格,也有人透過線框圖(wireframe)呈現。參考範例1參考範例2
  • #6.Product release checklist:用來溝通產品上線的注意事項,包括上線內容、日期、部署方式(Alpha、Beta、正式發布,不同地區、用戶群等)等、上線市場計畫(Go-to-market)。參考範例
  • #7.FAQs:用來溝通新產品、新功能的使用流程,以及用戶可能會遇到的問題與客服該如何回應的答案。通常 B2C 產品是提供文件給客服部門參考,B2B 產品則較為複雜,牽涉到業務、客戶成功,除了提供文件外,也常常需要內部的教育訓練。值得一提的是 Amazon 把這 FAQ 步驟提 到產品開發的前期(working backwards、PR FAQs 範例),儘早思考用戶在意的價值與可能遇到的問題。
  • #8.Product Outcomes:跟 Product KPI and metrics 類似,但主要是溝通產品上線後的成果,例如 KPI、商業成果與市場反應等。對於面向消費者產品而言,通常是 A/B tests 的實驗結果。

筆者在找尋上述範例時,發現了有網站已幫大家整理好產品管理常用的文件範例,可以參考:https://usefyi.com/templates/product-management-templates/

3.如何善用文件溝通?

要善用文件溝通,產品經理必須要知道不同階段該用什麼產品文件產品文件的受眾

不同階段該用什麼產品文件?

可以簡單將產品開發流程分成探索、開發與上線。

1.探索階段:常用文件如 Product vision and strategy、Product KPI and metrics、Product roadmap。在新產品或新專案開始之初,產品經理會花相當多的時間在這裡,例如需要進行市場研究、使用者研究與數據分析才有辦法制定出好的產品策略、設定出合理的目標。

2.開發階段:常用文件如 Product requirements documents、Prioritized product backlog。在確定產品大方向後,產品經理會開始與工程師、設計師密切討論,包括釐清用戶問題、排出優先性與提出解決方案。在寫 PRD 時,很難一次到位,通常會經過多次討論與修訂才能逐漸成形。

3.上線階段:常用文件如 Product release checklist、FAQsProduct Outcomes。產品開發到一定程度,產品經理會開始與市場與營運團隊討論上線事宜,並提供跟使用者第一線接觸的同事準備相關的 FAQs。上線穩定之後,產品經理也會開始整理指標數據,確認成果是否有達到預期目標。

產品文件的受眾

以下是軟體或網路產業中,與產品經理共事的主要角色,也就是產品文件的主要受眾。但與其說是受眾,不如說是協作者更為貼切,因會很多文件都是與他們溝通完的結論果。

1.產品開發核心團隊:通常為工程師、設計師,產品經理會在產品設計與開發流程與核心團隊從頭到尾合作,從討論產品願景、策略、路線圖,到產品需求、規格,再到產品上線。核心團隊成員最在意的就是為何而戰,與他們一起討論願景與策略對於凝聚共識非常有幫助。至於產品需求文件,每個成員對細節的要求不一,但最重要的是產品經理要能明確指出工作項目的範疇與優先級。在歐美公司,一般會賦予團隊設計師與工程師解決方案的 ownership(例如完全由設計師制定 user flow),但這絕對不代表產品經理對方案細節可以沒有想法。

2.產品開發次核心團隊:通常為產品行銷、用戶研究員、資料科學家/ 資料分析師,產品經理會跟他們在產品開發中某幾個階段合作。例如要有好的產品策略計畫,則必須與產品行銷合作了解市場趨勢,與用戶研究員合作了解與判斷用戶痛點,與資料科學家合作來衡量痛點與解決方案的影響力。在產品探索階段,儘早邀請次核心團隊成員參與,取得他們的 input,一起參與產品文件的協作是很重要的。

3.產品銷售與營運團隊:通常為營運、客服等,產品經理會跟他們討論用戶需求與反饋。產品文件通常要避免太多專有名詞或太技術性的說明,試著以淺顯易懂的方式、伴隨例子是與他們溝通的要點。此外,因為銷售與營運團隊是第一線接觸用戶的人,新產品、功能上線會很大的影響他們的日常工作,因此明確定的上線時間是與他們溝通時要強調之處。

4.利害關係人:通常為產品主管、商業部門(如業務、客戶經理),產品經理會在開發之前取得他們對專案的認可,在產品上線後也會對這群人負責。當透過產品文件與這群人溝通時,首重 KPI 與商業成果指標,提供產品上線前後的差異。一般來說,他們不會太在意產品開發、上線階段的細節,但是若產品經理能定時更新產品開發進展,對於取得利害關係人的信任是大有幫助的。

5.其他:路人甲,通常為其他部門的同事,想要了解你的產品,尋求合作機會。對於路人甲,產品經理若能有個已經整理好的 Product vision and strategy、Product KPI and metrics 與 Product roadmap 文件,分享這些文件給他們會讓路人們更容易了解你的產品。

最後,將產品文件按階段與對象整理至下表:

產品文件:階段與對象

4.注意事項

最後,談談兩點寫文件時的注意事項:

  • 不是從零開始:大多數的產品經理是接手已經存在的產品,產品經理的任務可能是直接進行產品開發,因此需要撰寫 PRD、Checklist、FAQs 等。在這個狀況下,建議還是要在接手產品的前一兩個月回過頭檢視或撰寫如 Vision、Metrics 與 Roadmap 等文件,畢竟這些文件可以讓你思考什麼才是正確、有價值的事情,並將與團隊溝通。
  • 適度的文件化:很多產品經理會花過多的時間在文件上,希望把文件做得盡善盡美。但其實要注意的是,產品文件並非產品最終產出,它並不能直接影響使用者的行為。所以,適度的文件化,只要能達到與團隊清楚溝通的目標即可。

希望這次的產品經理常見產品文件介紹對讀者有幫助!若讀者有什麼常用的產品文件、好的範例,也歡迎分享。

Product guy | Passionate about products | LinkedIn: https://www.linkedin.com/in/peter-su-09120020/

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store