關注我的朋友應該知道，2022年底我們上線了一款公眾號排版插件：小破球，從2022年10月份項目立項，到2023年1月上線。
整個過程花了2個多月，最終5個人完成了beta版本的上線。
從起初的痛點和梳理需求后到產品設計，再到和開發同學產品設計方案的可行性、技術難點、和方向；再到完善產品設計和開始啟動UI設計，再到推進開發和產品上線。
整個階段除了使用MVP的產品設計方法外，對于我而言就是耗費時間在產品的測試和驗收，同時在產品上線后開始種子用戶的邀約。
那么我是如何做一款產品的優化呢？
我優化一款產品之前，首先保證通過評審的需求上線。
產品設計的方案已經完全上線，我們才能稱之為優化，否則就是屬于修改BUG。
但是很多產品在上線早期，一邊修復Bug，一邊做優化。
比如在測試產品的過程或者產品使用的過程中，發現了原先功能設計不完善的問題，就通過提出優化項來修復，否則用戶一樣不會買單。
為了提供完整的用戶體驗，才會在這個階段將BUG的修復和優化會一起做。
我怎么確定優化項？
優化的需求可以來源多個方面，只要是一位產品的使用者都可以產生任何方向的產品優化需求。比如功能使用過程中，有沒有邏輯順序不對的、有沒有文案誤導的、有沒有按鈕大小、位置或者點擊異常的；
還有一些優化項并不是剛開始就會發現，而是需要在產品使用過程中，隨著使用時間加長才會出現。比如發布內容數量或者累計操作多了，出現了頁面展示問題，或者操作無響應的問題，也可以記錄為優化項。
我認為優化項是產品設計方案的補充，并不是創造全新的功能，而是對以往的功能做完善。比如我們做的公眾號排版插件默認會在公眾號里以彈窗展開，但是早期beta版本彈窗會擋住公眾號原有的封面入口，影響了創作者排版，于是提出需要將公眾號插件彈窗支持拖拉拽的、同時以更小的圖標來表示的優化項需求，
如下圖彈窗可以展開和折疊
公眾號排版插件的優化需求產品優化沒有絕對的邊界很多時候，我們也不能全部按照新功能來界定優化需求和新需求，比如增加一個功能入口，或者增加版本提示的新功能。這類需求的開發成本非常低，所以也會當做優化需求一起加上了。
有的時候我們也會把一些小的優化項目和新功能放在某個大版本里面集中發布，希望為新版本做好更宣傳效果。
優化項目也會涉及到需求排期優化項目也是需求，根據需求的復雜程度，所需要的資源、時間也不同，所以我們需要通過排期來保證資源的投入是在最優先的需求里。
當然這也和產品經理的經驗相關，經驗多的產品經理會在每個版本的設計方案里面都盡可能的完善，不會遺留太多優化項的空缺。
我尤其看重要優化項的狀態與跟蹤除了找到優化項，我認為產品經理最難的是跟蹤優化項目，以及做及時的跟蹤，對優化項目的完成情況進行驗證。
比如某個優化項提出后需要開發進行狀態標注，對已經修改的優化項目標注為【待測試】，再讓對應的測試同學接手，標注為【待驗收】，產品經理最后來做驗收環節，通過后標注為【上線】
跟蹤優化項，意味著需求的解決速度得到保證，如果是APP還要和運營進行同步，上架到各個渠道市場，快速的讓用戶得到更加完善的產品。否則產品的用戶仍然在持續的流失。
