本篇適合想要知道產品經理常用產品文件的讀者，我將分享為什麼要寫文件、常見的產品文件與如何善用產品文件來做產品溝通。
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、FAQs 、Product 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 等文件，畢竟這些文件可以讓你思考什麼才是正確、有價值的事情，並將與團隊溝通。
- 適度的文件化：很多產品經理會花過多的時間在文件上，希望把文件做得盡善盡美。但其實要注意的是，產品文件並非產品最終產出，它並不能直接影響使用者的行為。所以，適度的文件化，只要能達到與團隊清楚溝通的目標即可。
希望這次的產品經理常見產品文件介紹對讀者有幫助！若讀者有什麼常用的產品文件、好的範例，也歡迎分享。
