告別落落長的產品需求文件，用產品啟動文件一決勝負吧！
📣 產品三眼怪的粉絲專頁開張囉，我們之後會將文章和 Podcast 的更新在粉專一次公告，讓大家方便發摟。現在就先追起來才不會忘記！🏃♀️🏃
網路上有許多產品需求文件的範本，如果按表操課的話要寫出一份夠完整的產品需求文件也不是難事，但每個產品經理幾乎都會遇到一樣的問題：「文件太長資訊太多沒人要看」「需求文件寫完幾乎變成 test case」（？）登愣！辛苦了半天，如果最後沒人看不就白費了。
但其實我一直很討厭硬梆梆的產品需求文檔，看到就覺得好無聊啊連我在當產品經理都不想看了誰想看！所以只要團隊沒有需要我就不會去寫。
不過我最近加入了快速成長的中型新創，加上還在疫情期間的遠端工作模式，為了有效的統整資訊，公司的產品開發流程中也會傾向準備一份「產品啟動文件」來跟大家簡報。使用過後覺得產品啟動文件還蠻好的，不會拖泥帶水包含一堆執行細節，所以想要來寫篇文章跟大家分享一下。
在這篇文章中你可以看到：
1. 什麼是產品啟動文件？
2. 產品啟動文件的三大功能與超多優點
3. 我的產品啟動文件框架：七大必寫核心資訊
4. 如何處理產品規格的細節呈現？
5. 產品啟動文件的使用心得▍什麼是產品啟動文件？
什麼是產品啟動文件？估狗大神是這麼說的： A kick-off document lets you share with stakeholders the smallest thing you can build that will either validate or invalidate your hypothesis.
簡單來說，產品啟動文件是拿來敘述一個產品前因後果的故事，讓所有人都可以看完並且看懂，並且快速理解你為什麼要做這件事情、有什麼假設、怎麼驗證成功，而不是一份落落長的規格表、商業邏輯或 acceptance criteria。
▍產品啟動文件的三大功能與超多優點
1. 提早與 Key Stakeholder 在重點上達成共識
產品啟動文件顧名思義就是幫助你畫出一個產品改動的大方向架構，讓你可以順利的啟動這個產品專案。通常一個產品改動會有非常多不同面向的 stakeholder，從自已的團隊、主管、其他產品經理到互相合作的其他部門等等，和這些夥伴們在早期規劃階段達成大方向的共識有非常多好處：
好處一：當你和夥伴們都先在方向上達成共識、確保大家都對你的動機有所了解後，後面在專案的執行會更容易和其他人溝通。
好處二：當你提出最初的想法時，其他人也可以在早期啟動階段就分享他們的想法，或許在討論中，會發現一些你沒考慮到的面向或者不知道的組織內部資源也說不定！
好處三：因為這個階段還不會討論太多解法和規格和細節，只會討論「大方向」，所以可以避免 Stakeholder 只關注一些細節的介面或者交互的問題，鼓勵大家都一起思考產品改動的核心價值和重點。
2. 幫每個產品改動做「全面的健康檢查」
產品啟動文件的框架就是一份最棒的「產品提案 101」 Checklist，一但你有了這個框架，每次在做產品改動的時候，只要一邊填表格，也等於一邊鼓勵自己思考不同面向，把重點都扎實的寫下來，可以避免思慮不周所產生的意外。
3. 一份文件打天下，減少資訊混淆的情況
產品啟動文件基本上紀錄了「所有人都會有興趣了解的核心資訊」，所以任何人都可以看。在遠端工作的模式中，這份文件也會是資訊集散地、 Single source of truth。
那麼哪些資訊是「產品健康檢查重點」兼「大家都想看的核心資訊」呢？
▍我的產品啟動文件框架：七大必寫核心資訊
產品啟動的重點是在「這個問題值不值得解決」「這是不是最好解決這問題的方法」「怎樣叫解決」這些基礎定義和認知上取得共識，所以以下的七大核心資訊大致上都會圍繞著這些問題打轉。
我綜合了一下以前用過的產品文件範例，整理出七個重點資訊：問題、假設、範疇、指標、風險、上線計畫、利益關係人名單，以下讓我娓娓道來。
1. 問題敘述 Problem statement
問題敘述是一切產品改動的根源，如果沒有問題，就不需要改產品。這一段資訊將會解釋「為什麼」你準備要做這一個產品改動，我認為這是一個好的產品啟動文件不可或缺也是最最最重要的一部分。
- 要解決哪些人的什麼問題？是什麼樣的用戶情境？（當然，這裡的用戶也可以是終端用戶、內部使用者、產品團隊、或任何一個需要被解決的商業或產品問題都可以）
- 有哪些研究資料、數據佐證這是個值得被優先解決的問題？這部分可以包含你的市場數據、競品分析、質化研究或量化數據。
有些人可能會用 User story 或者 JTBD（Jobs to be done）的方式敘述用戶情境和問題，其實都可以，沒有一定。總之目標就是讓任何看完這一段資訊的人，都能夠 100% 了解做這件事情的理由和重要性。
2. 產品假說 Hypothesis
在上一段中我們確定了這是一個值得解決的問題，那麼我們也會跟著好奇，這個問題又是如何連結到你的產品目標、商業目標？如果解決了這個問題，他會產生怎樣的 Impact？每個人在做產品改動的時候都有自己心中的「假設(assumptions）」，所以把這些假設寫下來，會讓思路更清晰、更知道自己到底是在驗證什麼。
所以敘述完問題後，我會簡短的寫下產品假說，我也還不是很確定什麼是最好的格式，所以這邊分享幾個範例參考：
3. 產品改動的範疇 Scope
說明過問題和假說後，就可以來談談這次實際上的產品改動到底是改什麼？ 這部分用「產品範疇」取代「產品規格」有幾個原因，一是我們在產品啟動文件階段時，可能還不會有完整的產品方案和設計，二也是因為其實在開始設計之前，本來就也應該要花時間定義範疇，確保我們要改的範疇和夥伴們的期待是有共識的。
關於產品改動範疇，除了要寫出「要改哪些」以外，更重要的是寫出我們這次「不要改哪些」，才可以確保改動不會因為大家的許願而無限擴大。
4. 衡量成功的指標 Measure of Success
第四點也是非常關鍵的資訊，也就是我們會如何衡量這個產品改動的成敗，決定要不要將其上線。這部分必須在 Kick Off 階段就
這部分會建議列出幾項重要資訊 1. 團隊目標：這個產品假說 / 改動如何連動到團隊的目標（e.g. 相關 OKR） 2. 成功指標：哪些指標能夠衡量這個產品假說為真 3. 輸入指標：哪些指標能夠看出這個產品改動有效果 / 其他想要觀察的指標 4. 健康指標：如何確保這個產品改動沒有破壞到原本產品的健康
指標的選擇有許多眉角，礙於篇幅這邊就不長篇大論，更詳細的說明我有收錄在這篇文章：
5. 風險評估與未知數 Risk & Unknowns
產品改動通常也會伴隨著風險和未知，這一段就是拿來思考與寫下可能產生的一些風險，我們才知道可以如何控制風險。這段也是拿來幫你的 Stakeholders 解決他們腦袋裡的擔心害怕的！至少他們看到這裡的時候，他們可以知道你是有思考過、並且有計畫去控制風險的。
1. 目前能夠預知的風險：改了買家體驗，會不會影響到賣家體驗？改了用戶瀏覽體驗，會不會影響到廣告收入？產品改動可能會對體驗有哪些負面影響？這些全部都得好好思考過並且列出來。
2. 如何控制這些風險：可以是加一些 business logic 去減低可能的負面影響，也可以是在產品營運上 workaround，當然也可以什麼都不做但至少先觀察相關的數據指標或事後進行用戶訪談等等，總而言之就是想辦法控制並且減低上述的風險。
3. 目前有哪些未知：可以是營運策略上的未知數，或者也可以是技術或系統上的未知數，產品啟動階段總是還有一些事情還沒完全搞清楚。寫在這裡，提醒自己之後要跟團隊一起去幫這些未知找答案吧！
4. 如何解決這些未知：關於營運策略上的未知，你會找誰去討論決定下一步；關於系統上的未知，你會怎麼跟工程師一起把他們變成已知等等。
其實也不用寫得非常仔細，在大方向上有個交代就好。如果只是很小的改動沒什麼太大風險，跳過這段也沒關係。
6. 上線計劃 Roll out plan
這段可以簡述關於你會如何將這產品送到用戶的手中：AB Testing、 Beta 測試群、是否會需要行銷團隊的支援等等，一樣也寫個大概就可以了。
7. 利益關係人 Stakeholders
最後也是蠻重要的一步，就是這件事情會影響到組織內部的哪些部門 / 團隊 或人，也確保你沒有漏掉一些重要的大人物。這邊介紹一個我最近才學到但很喜歡的框架：RACI metrix。
- Responsible 負責人：這些人對於專案執行負責，確保這個產品改動有被 規劃與交付，身為產品經理通常我會放我自己的名字 & 我的團隊名稱。
- Accountable 最終負責人：這些人對於最後的成果負責，其實我覺得這跟 responsible 是蠻像的，課本上都建議我們只能放一個人的名字，不過我希望團隊也有 ownership，所以我也會放我自己的名字 & 我的團隊名稱。
- Consulted 顧問：在做決定前，你必須詢問這些人的意見。在我的情況下，每個功能這個名單可能會有差異，但通常我會包括相關產品團隊、相關部門（例如行銷）、產品行銷經理 Product Marketing Managers、文字撰稿人 Copy writer 等夥伴。
- Informed 其他相關人士：在做決定時你不需詢問這些人意見，但至少在做決定後，必須讓這些人知道結果。在我的情況下，這部分可以是客服團隊、法務等等。
老實說我也還在體會 Responsible & Accountable 的差異（如果有人有心得歡迎留言分享我需要和您請教一下🙇♀️），但我覺得這個框架最有用的其實是後兩項：哪些人需要被 consulted 哪些人需要被 informed，基本上就是給予這些重要人物發語權。在產品啟動會議的時候如果有人被漏掉，要請他們舉手發問！
BONUS: 常見問題集 FAQ
剛寫出來的產品啟動文件絕對不會一次就定案，通常大家會有不同的問題，還會有各種討論讓你修修改改這份文件，所以在中間我也蠻推薦附一段常見問題，若是後來又有人問一樣的問題，就可以從這個段落找答案。
看到這邊你可能覺得⋯產品啟動文件也還是落落長啊！到底是省略了什麼？
對，因為一個產品改動就是如此複雜嗚嗚！不過也可以根據功能大小，決定這些東西一句精簡帶過，還是多寫幾句解釋，可長可短但關鍵資訊不可省。
但說真的，有超多東西都已經被省略了，以下我會列出「不需要被列在產品啟動文件」內的資訊給大家參考。
▍產品規格的細節呈現
是的，如果產品啟動文件只講述故事，那麼商業邏輯、acceptance criteria 這些細節都會放在哪裡呢？
我自己覺得這些細節因為撰寫者不同、受眾不同、資料的內容也不同，可以用其他方式呈現，再用連結的方式當成啟動文件的附錄，這樣一方面用不同的方式更好的呈現數據、圖表、流程圖等等細節，另一方面也可以避免「單一文件落落長」的問題。
這些細節可能包括（但不僅限）以下資訊：
1. User research / Competitor analysis
文件撰寫：產品經理 & 產品設計師 & 用戶研究員 文件受眾：產品團隊、行銷團隊、或任何對於競品細節有興趣的人 呈現方式：通常我們可以在產品啟動文件裡面放重點節錄，剩下完整的報告可以使用投影片或者其他能夠較好呈現「競品截圖」「比較表格」「用戶旅程」細節的格式，例如使用 Miro / Whimscal 等大 Canvas 的軟體。
2. Data insights
文件撰寫：產品經理 & 產品分析師 文件受眾：產品團隊或任何對於數據和相關資訊感興趣的人 呈現方式：和用戶與市場研究類似，通常我們可以在產品啟動文件裡面放重點節錄，只要足夠去支撐產品假設就可以了，剩下的資料可以放在投影片或者試算表裡面，如果有需要的話再點開來講解。
3. Wireframe / User flow / Prototype
文件撰寫：產品設計師 文件受眾：工程師（開發時要一直重複看）、客服團隊（需要和用戶溝通），當然還有各種 stakeholder 也都會看大致上的流程。 呈現方式：通常設計師會有自己習慣使用的軟體，例如把最後的流程放在 Zeplin 上供開發者取用，如果用各種 Prototype 軟體如 Figma / Protopie 通常也會有一個連結，這樣的話在主要產品文件上可以放連結就好，比較容易做版本控管和更新。
4. Technical documentation
文件撰寫：工程主管或工程師 文件受眾：團隊裡的各種工程師、或 Platform/System engineers 呈現方式：關於 API 文件關於 System design 任何關於「開發上如何實作」的細節都放在這裡就對了，雖然這對於開發協作很重要，但這是一份大部分 stakeholder 不會有興趣的文件，絕對不能加在產品文件裡，得另開文件。
5. Data tracking spec
文件撰寫：產品經理或產品分析師 文件受眾：團隊裡的各種工程師 呈現方式：建議可以直接把細節寫在 ticket 裡面，這樣更方便工程師實作。
6. Acceptance criteria
文件撰寫：產品經理或測試工程師 文件受眾：團隊裡的各種工程師、測試工程師 呈現方式：也同樣建議可以直接把細節寫在 ticket 裡面，方便工程師實作的時候參考，產品文件裡面只要寫出大致上的 Scope 就可以了。
要做一個產品改動其實包含的資訊包山包海，以上六項資訊是我目前會用到，但 Stakeholder 不需要知道全貌的資訊，所以用附錄的方式反而更方便操作和文件維護。給大家參考看看！
▍產品文件只是文件，不是你的產品
之前在三眼怪的 Anne Hsiao 寫的《如何撰寫產品需求與規格文件？給產品經理的問題、心法與實作小撇步！》中她也有提到，產品文件其實只是一種溝通的工具，所以還是希望大家不用太執著於產品文件的格式。
以上提供的框架和重點只是一些參考資訊，產品改動有大有小，平時的中小型改動可能就可以拿產品啟動文件直接做簡報，但大一點的改動除了文件以外，可能還需要事前的 Stakeholder interview / Workshop 來達成共識，再開大型的 Kick-off 會議，這個時候可能就需要文件紀錄資訊、投影片來做簡報現場溝通等等。
產品文件也和組織的文化相關，我曾經待過完全不用寫文件，習慣非常敏捷一邊做一邊討論的團隊，如果溝通順暢，沒有文件也沒差！也有待過比較依賴文件，每個改動都需要正式的 Kick-off 會議來告知利益關係人進度的團隊，這種時候我就要把文件寫的比較嚴謹清晰一點，可以幫助形成共識。
畢竟，對於產品經理來說最重要的還是 deliver impact，只要對 business 對用戶產生正面的影響，對於「產品文件這件事情」並不需要按表操課或過度擔心！
謝謝你的閱讀！如果有任何回饋或有興趣的主題，歡迎留言給我們 📒
如果單純想給我一點鼓勵，請給我 1–10 個拍手；
如果覺得文章對你有點幫助，請給我 11-30 個拍手；
如果想看更多產品心法相關文章，請盡情長按拍手（max 50）讓我們知道 👏🏻想要持續追蹤我們的最新文章和 Podcast，記得追蹤「產品三眼怪實驗室」的粉專(◉◉◉)！
我們每週都會認真更新唷！千萬別錯過了～
