功能都做完了，爲什麼還要寫文件…來談談Pre-Release Announcement！

做過軟體產品的人通常都經歷過從無到有，把屎把尿的將一個產品或功能給孵化出來的過程，從前期的規格書、介面流程設計、無止盡的開發會議，到最後的各種測試。

然後，完成了！

除了準時完成，如釋重負，身為產品經理的你，要將產品或功能給交付出去給行銷、內容、銷售等推廣團隊接手時，你還得再花時間做的最後一份文件：Pre-Release Announcement。

顧名思義就是在產品正式發佈前的一個內部公告，讓團隊可以快速掌握到這次更新的重點內容，並針對最重要的核心價值去推廣給客戶和市場。

以下我用過去寫過的架構，簡要的了解一下一份Pre-Release Announcement需要包括哪些內容。

簡要的描述和列舉為什麼我們要設計這個功能，或爲什麼要進行更新修改。這部分通常會從使用者或客戶在使用場景中遇到的問題、或是潛在的需求開始，這些需求和問題可能透過各種不同的方式發現，例如系統上的數據，或是客服、業務部門蒐集到的回饋等等，因此需要透過案例說明，讓團隊更快進入狀況。

最後，再敘述我們如何評估，並使用怎樣的新流程來解決這個問題，這部分不用解說到太細節，因為細節要在後面講。

簡要的描述新功能，以及這些能對用戶產生什麼價值。這部分我通常會列點描述功能各個面向、步驟，以及哪些權限的使用者可以進行操作，盡量避免用全面性的敘述(如果你非常會寫當然也可以啦)，以免有些細部的調整沒有被提及。

既然是要給推廣團隊，勢必不能少掉目標客戶與使用者，這邊可以依據產品的實際狀況調整，例如2B的產品要將客戶與使用者分開列舉，2C的話則可以針對特定族群進行敘述。

對使用者來說，這些新功能上線之後，會對他們的使用體驗造成什麼改變？對他們的工作流程可能會有哪些幫助？這部分敘述的越詳盡，對於後續推廣團隊在製作內容時，能幫助他們更容易切中核心。

當然，這邊也需要圖文並茂的告訴大家，功能的操作方式，請想像成寫操作手冊那樣進行。

最後還可以再補充一下，這次的變動，還有沒有什麼其他的潛在效益，例如更能夠Cross Sale其他的產品，還是因為這過功能的更新，能讓更多初階的使用者願意升級方案等等。