關(guān)注我的朋友應(yīng)該知道，2022年底我們上線了一款公眾號排版插件：小破球，從2022年10月份項目立項，到2023年1月上線。

整個過程花了2個多月，最終5個人完成了beta版本的上線。

從起初的痛點和梳理需求后到產(chǎn)品設(shè)計，再到和開發(fā)同學(xué)產(chǎn)品設(shè)計方案的可行性、技術(shù)難點、和方向；再到完善產(chǎn)品設(shè)計和開始啟動UI設(shè)計，再到推進開發(fā)和產(chǎn)品上線。

整個階段除了使用MVP的產(chǎn)品設(shè)計方法外，對于我而言就是耗費時間在產(chǎn)品的測試和驗收，同時在產(chǎn)品上線后開始種子用戶的邀約。

那么我是如何做一款產(chǎn)品的優(yōu)化呢？

我優(yōu)化一款產(chǎn)品之前，首先保證通過評審的需求上線。

產(chǎn)品設(shè)計的方案已經(jīng)完全上線，我們才能稱之為優(yōu)化，否則就是屬于修改BUG。

但是很多產(chǎn)品在上線早期，一邊修復(fù)Bug，一邊做優(yōu)化。

比如在測試產(chǎn)品的過程或者產(chǎn)品使用的過程中，發(fā)現(xiàn)了原先功能設(shè)計不完善的問題，就通過提出優(yōu)化項來修復(fù)，否則用戶一樣不會買單。

為了提供完整的用戶體驗，才會在這個階段將BUG的修復(fù)和優(yōu)化會一起做。

我怎么確定優(yōu)化項？

優(yōu)化的需求可以來源多個方面，只要是一位產(chǎn)品的使用者都可以產(chǎn)生任何方向的產(chǎn)品優(yōu)化需求。比如功能使用過程中，有沒有邏輯順序不對的、有沒有文案誤導(dǎo)的、有沒有按鈕大小、位置或者點擊異常的；

還有一些優(yōu)化項并不是剛開始就會發(fā)現(xiàn)，而是需要在產(chǎn)品使用過程中，隨著使用時間加長才會出現(xiàn)。比如發(fā)布內(nèi)容數(shù)量或者累計操作多了，出現(xiàn)了頁面展示問題，或者操作無響應(yīng)的問題，也可以記錄為優(yōu)化項。

我認(rèn)為優(yōu)化項是產(chǎn)品設(shè)計方案的補充，并不是創(chuàng)造全新的功能，而是對以往的功能做完善。比如我們做的公眾號排版插件默認(rèn)會在公眾號里以彈窗展開，但是早期beta版本彈窗會擋住公眾號原有的封面入口，影響了創(chuàng)作者排版，于是提出需要將公眾號插件彈窗支持拖拉拽的、同時以更小的圖標(biāo)來表示的優(yōu)化項需求，

如下圖彈窗可以展開和折疊

很多時候，我們也不能全部按照新功能來界定優(yōu)化需求和新需求，比如增加一個功能入口，或者增加版本提示的新功能。這類需求的開發(fā)成本非常低，所以也會當(dāng)做優(yōu)化需求一起加上了。

有的時候我們也會把一些小的優(yōu)化項目和新功能放在某個大版本里面集中發(fā)布，希望為新版本做好更宣傳效果。

優(yōu)化項目也是需求，根據(jù)需求的復(fù)雜程度，所需要的資源、時間也不同，所以我們需要通過排期來保證資源的投入是在最優(yōu)先的需求里。

當(dāng)然這也和產(chǎn)品經(jīng)理的經(jīng)驗相關(guān)，經(jīng)驗多的產(chǎn)品經(jīng)理會在每個版本的設(shè)計方案里面都盡可能的完善，不會遺留太多優(yōu)化項的空缺。

除了找到優(yōu)化項，我認(rèn)為產(chǎn)品經(jīng)理最難的是跟蹤優(yōu)化項目，以及做及時的跟蹤，對優(yōu)化項目的完成情況進行驗證。

比如某個優(yōu)化項提出后需要開發(fā)進行狀態(tài)標(biāo)注，對已經(jīng)修改的優(yōu)化項目標(biāo)注為【待測試】，再讓對應(yīng)的測試同學(xué)接手，標(biāo)注為【待驗收】，產(chǎn)品經(jīng)理最后來做驗收環(huán)節(jié)，通過后標(biāo)注為【上線】

跟蹤優(yōu)化項，意味著需求的解決速度得到保證，如果是APP還要和運營進行同步，上架到各個渠道市場，快速的讓用戶得到更加完善的產(chǎn)品。否則產(chǎn)品的用戶仍然在持續(xù)的流失。