產品文件有哪些？產品經理常見的 5 種文件撰寫指南｜EP66

在產品經理這個職位上，常需要撰寫各種產品文件，像是產品需求文件、產品教學手冊、產品路線圖、產品維運常見問題等，這篇想整理過往以產品經理的角色需要維護哪些文件。

一、產品文件的重要性

在產品開發的不同階段，往往需要不同產品文件來跟利害關係人溝通，像是面對客戶、面對工程師、面對客戶經理，往往就需要不同種文件。

常見的產品文件像是：

1. 產品提案文件：產品最初期的規劃，面向各利害關係人的提案，包含使用者流程、開發項目盤點、競品比較、預估時程、預期效益等。
2. 產品需求文件：提案通過之後，接著會開始撰寫面向產品團隊的需求文件，包含功能目的、功能盤點、功能調整內容等。
3. 產品上線文件：功能開發完要上線前，會需要提前向客戶、業務說明功能簡介，可以達到什麼目的、適合什麼情境。
4. 產品教學手冊：呈上，上線文件通常比較簡略，當客戶或業務有興趣時，就可以看教學手冊，會包含更多種支援與不支援的情境，或使用者流程，更細部的按鈕操作路徑。
5. 產品維運手冊：呈上，有些教學手冊只告訴使用者怎麼用，但沒有特別放 FAQ（常見問題），因此當公司有客服部門時，有時會另外一份 FAQ 文件，讓客服知道各種情境可以怎麼回答，或是可以到教學手冊第幾頁找操作步驟。

⠀⠀

⠀⠀

二、常見的產品文件類型

⠀⠀

（一）產品提案文件

⠀⠀

在產品經理接到需求後，有時不會直接寫完文件就進開發，針對中大型功能，通常還需要經歷「提案」流程，提案對象包含產品主管、工程主管、或預計使用者的客戶，主要是為了確認產品經理規劃的內容符合：

1. 技術可行：邏輯上、技術架構上要能做到
2. 客戶接受：產品經理的提案，要能解決客戶提出的需求場景
3. 操作便利：介面操作要盡可能最少步驟，就讓使用者完成任務
4. 迭代潛力：要確保未來若要加功能，不會因為這次規畫產生過多技術債

⠀⠀

因此產品提案文件裡面可能會包含：

1. 使用者流程圖：預計使用者完成一項任務會經過哪些流程，像是匯出 Excel、編輯 Excel、匯入 Excel。
2. 功能最終產出：使用者操作後，會獲得什麼、能設定什麼。
3. 功能支援範疇：通常會有「現況可滿足」、「可滿足，但時程關係先不做」、「技術上不可行」等情境。
4. 預計操作畫面：有時為了方便展示，可以透過 Figma 快速拉一個 Mockup（精緻圖，但非畫面最終定案）。
5. 預估規劃時程：根據上述的規劃會初步抓一個開發時程，但若提案過程要加需求，則會再往上喊。

⠀⠀

（二）產品需求文件

⠀⠀

產品需求文件（Product Requirements Document, PRD）幾乎是產品經理一定會碰到的文件，差別是不同公司的格式可能不一樣。

• 有些敏捷開發的公司，產品需求可以直接寫在看板工具的卡片上。
• 有些瀑布開發的公司，產品需求需要很完整寫成一份 word。

不論是哪一種，通常產品需求文件目的是：

1. 說明功能目的：告訴設計師、前後端工程師、測試工程師這個功能要讓使用者做到什麼事／完成什麼任務。
2. 說明功能範疇：說明此功能預計會改到的位置、介面、文案、架構、API 等。
3. 說明驗收標準：使用者做完什麼情境才會功能開發完畢。

因此產品需求文件裡面可能會包含：

1. 功能緣起：為什麼要修改、修改完可以達成的目的和效益、適用的使用者對象是誰。
2. 功能範疇：本次要調整的位置、介面、文案、架構、API 等。
3. 使用流程：除了文字說明，通常需要簡易流程圖，例如 A > B > C。
4. 介面流程：若有新功能或新操作，通常會需要請設計師規劃新的介面和流程，像是使用者點了按鈕會前往哪些介面，跳出什麼錯誤彈窗。
5. 範例文件：若有些後台功能需要使用者匯出 Excel、匯入 Excel 進行大量資料修改，則也需要提供範例文件、或各種情境的錯誤訊息。
6. 驗收標準：使用者要完成哪些情境、介面要顯示哪些文案、或是達到什麼數據指標，才算功能開發完畢。
7. 開發時程：期望的測試時程或上線時程。

⠀⠀

（三）產品上線文件

⠀⠀

產品開發完成後，通常不會默默地上線：

• 若是 C 端產品，通常會搭配行銷、廣告進行曝光，盡可能上線當天可以讓功能最大化被看見。
• 若是 B 端產品，通常會需要客戶經理提前向客戶說明，盡可能上線當天就有人使用。

產品上線文件通常是 5 分鐘向利害關係人簡述功能，因此不太會將功能講太細，目的主要是：

1. 讓客戶經理、業務知道該功能的用途，後續可以再拿著教學手冊給客戶
2. 讓其他部門想要知道上線內容的人，可以用 5 分鐘快速了解功能概念。

⠀⠀

因此產品上線文件裡面可能會包含：

1. 功能簡介：產品原本內容和本次修改的差異。
2. 適用情境：適合使用的客戶或使用者是誰，什麼場景可以使用。
3. 流程簡介：使用者可以從哪個頁面，做完會得到什麼。
4. 相關連結：其他更細節的教學手冊可以放超連結在文件。

⠀⠀

（四）產品教學文件

⠀⠀

產品開發完成後，通常需要有一份「產品全貌文件」，讓使用者知道各個步驟，像是正確流程、什麼情況會錯誤、支援什麼、不支援什麼，也要讓產品團隊未來在迭代功能時，可以掌握產品現況是什麼樣子。

通常產品教學手冊的目的是：

1. 客戶教學：讓客戶知道怎麼操作功能，可以滿足什麼情境。
2. 產品現況：當未來的產品開發團隊要繼續加新的功能時，可以知道要從哪邊開始改，以及要改哪些位置。

⠀⠀

因此產品教學手冊裡面可能會包含：

1. 步驟教學：當客戶在介面遇到問題，可以根據手冊一步步操作。
2. 支援範疇：讓客戶理解功能可以協助他到做到什麼事。
3. 介面規則：當有跳出錯誤時，要能知道為什麼他會操作錯誤、是否有欄位字數限制、或相關非預期的情境等。
4. 關聯功能：有些功能是互相影響的，例如在 A 功能操作後，會在 B 介面看到新資料，因此手冊也要說明互相影響的位置。
5. 聯繫管道：當有其他疑問、但不在手冊上，可以聯繫哪個窗口。

⠀⠀

（五）產品維運手冊

⠀⠀

產品維運手冊和產品教學手冊通常相輔相成，教學手冊是「正向表列」功能可以怎麼使用，但通常各種客戶或使用者一定會有特殊的用法或期待，因此就需要一份產品維運手冊（a.k.a. 常見問題集 FAQ），根據不同疑問，可以快速為客戶解答。

產品維運手冊的目的是：

1. 公版回答：一間公司通常會有多位客服或客戶經理，每個人若都回答不一樣的答案，往往會造成客戶困擾，這時若有一份公版回答，就能讓大家給客戶的說法盡可能相似，例如要設定 a 一律都到 A 頁面。
2. 檢視產品：在製作問題集的過程中，往往也是檢視產品現況的好時機，可以讓產品經理更清楚知道「到底這個功能可以做到什麼事／不能做到什麼事」，以利做為未來優化方向。

⠀⠀

因此產品維運手冊裡面可能會包含：

1. 各種情境：以電商前台為例常常會拆成，註冊登入、瀏覽商品頁、加入購物車、刷卡、退貨等情境；後台則可能包含上架、編輯、刪除等情境。
2. 正逆流程：建立資料、編輯資料、移除資料的做法（CRUD, Create、Read、Update、Delete）。
3. 相關連結：遇到什麼情況可以參考教學手冊的第幾頁。
4. 產品現況：哪些使用者的疑問確實是功能現況不支援的，因此建議使用者的操作備案。⠀⠀

⠀⠀

⠀⠀

三、其他重要產品文件

除了上述 5 種文件，有些公司的產品經理還會需要製作：

1. 競品分析報告：定時查看各競品當季的新功能、或市場趨勢。
2. 用戶分析報告：定時分析用戶數據、確認數據走向或用戶特徵。
3. 產品業績報告：定時查看產品被使用的、被購買、被訂閱的業績等。
4. 產品策略報告：每季提出產品優化方向、或新的產品路線圖。

但因為我對上述的文件撰寫經驗還不完整，因此這篇先不針對上述文件展開說明。

⠀⠀

⠀⠀

四、文件維護指南

⠀⠀

產品文件做完第一版後，通常需要不定期更新，因此有幾個方式：

1. 指定產品負責人：該 Product Owner 要維護哪幾份文件，當有新功能就要回去增加，確保文件的準確性。
2. 紀錄文件版本：在文件的前幾頁可以用表格紀錄版號，例如在幾月幾號誰更新了什麼。

但其實文件管理這件事非常難，因為同一個產品可以會經手不同產品經理，有些文件在傳承過程中會遺失，甚至沒人去更新，再加上並非每位產品經理都有共同的文件整理習慣。

因此我認為文件管理機制仍需要看不同公司的團隊文化、以及產品經理們互相討論出一個可長期維護的流程。

⠀⠀

⠀⠀

五、總結

⠀⠀

產品文件是產品開發中一定會碰到的工具，有完整的產品文件可以讓團隊更清楚產品全貌，也能讓未來接手的人更快速掌握產品，不僅能夠提升團隊協作效率，還能降低溝通成本，確保產品開發順利進行。

這篇僅先分享我在工作中實際撰寫產品文件的心得，但也並非一定要照著上面格式才是正確的，文件的格式、收整、類型，會根據不同團隊而有滿大的差異。

因此往前推，我覺得產品經理的角度可以先確認做文件的目的是什麼，當寫文件的人意識到這件事是重要的，在管理上也會相對輕鬆。

⠀⠀

如對這系列文章有興趣可以再觀看：

• 產品規劃如何運用減法思維？以最小可行性產品為目標｜EP65