產品經理在排序優先級時,不免會被問「這個很急嗎」,有時就會讓不緊急的項目往後排,但這些小優化、小 bug 會越累積越多,讓整個系統到處都有漏洞,某天使用者就會開始抱怨「系統實在不怎麼好用」,那要如何避免呢?可否將小需求逐步安排進團隊開發?這篇想記錄我在產品團隊的工作模式。
在敏捷開發的快節奏中,產品經理往往面臨資源有限、時程緊湊、需求繁多的多重壓力,這樣的情況下,持續規劃「看得到、說得出」的大功能似乎才是價值的具體展現,也更容易讓團隊被高層看到。
但以使用者的角度出發,除了亮點功能之外,每天的操作過程若能持續更順、更快、更直覺,使用者也能感受到產品「有在進步」,但要做到持續優化有幾個關鍵:
⠀⠀
小需求是指什麼呢?回到使用者對產品貼上「不好用」的標籤時,不一定是某個單一功能的缺陷,而是多個小痛點長期積累的結果,可能包括:
⠀⠀
這些優化項目不一定會在 Product Roadmap 被看見,也不容易被量化衡量,但它們卻會每天影響用戶的操作體驗,當用戶開始累積到一定程度,用戶就會透過客戶經理、客服管道開始抱怨(若大客戶抱怨,在某些公司是很嚴重的事,即使有時候是一個小優化)。
⠀⠀
⠀⠀
上述雖然提到小需求的常見問題,但為什麼在多數產品團隊都不容易去安排這些小需求呢?
一個新功能的推出通常伴隨明確的市場目標或業務需求,能用數據支持其價值,對上溝通具備說服力,對於產品經理本身的職涯或年度績效也至關重要。
在有限的資源與工時下,「不會被使用者注意到的修改」往往被犧牲,並標註「有空再處理」。
許多團隊沒有設計專屬的維運追蹤流程,小優化往往排不進 Roadmap。
有時產品經理想要改一些小優化,但工程師認為這些需求影響小、回報低,進而排斥投入資源處理。
⠀⠀
⠀⠀
持續的小更新和上線發布,能讓使用者覺得產品是「活著」的,這些變化雖不重大,但當使用者感受到上次提到的改善建議被解決了,可以增加用戶對產品的信任。
許多客訴源於介面設計不良或防呆機制不足,隨手將這些問題優化,可以減少第一線客服成本。
將「減少走錯路的操作」、「重要按鈕的提示文字」的小細節做好,能減少產品經理要不斷做各種教學手冊的時間成本,讓用戶看到產品就會使用。
⠀⠀
⠀⠀
除了一開始提到的 3 點方向:
⠀⠀
實際上我待的產品團隊是透過以下方式來進行:
將各種維運、bug、文案修正、彈窗修正、載入過慢等各式零星的需求,收集成 backlog,並每 1-2 週請前端 / 後端工程師陸續調整。
跟專案 Backlog 一樣,這些維運 Backlog 也要有優先順序,並且不能一次太大量釋出給開發團隊,要每 2 天 1 張的進度慢慢收掉。
這個也是有些團隊會有的文化,每個 Sprint 除了 2–3 位工程師固定開發專案的項目,還會有 1 位工程師專門處理維運 Backlog 的事項。
因此平均每個 Sprint 都會有 10–20% 的開發時數可以安排到優化項目,讓優化行動變成一種常態,而非偶發性的「有空才做」。
將這些小優化定期向利害關係人匯報,像是 Sales、AM、主管,讓他們知道除了專案進度之外,團隊成員也持續在優化產品細節。
通常維運 Backlog 相對簡單,但視覺上完成的 ticket 數量很多,因此也會讓主管感覺到「團隊產出很大量」。
這個就很看不同 PM 和團隊的做事文化,因為維運項目通常較簡單,不一定需要 QA 人員寫完整的測項,有時可以讓 PM 直接自己踩完 Happy Path 就 排上線,避免一直佔用 QA 的時間。
⠀⠀
⠀⠀
在 B 端擔任產品經理,最主要的任務是持續推出新功能解決用戶的新問題,但同時也要解決用戶每天遇到的小問題,從錯字修正到提示優化,從流程精簡到邏輯防呆,這些看似不起眼的小事,其實都是「用戶感知進步」的關鍵。
產品除了是 Product Roadmap 上的大項目堆疊起來,也是每一次微小優化的積累。
如對這系列文章有興趣可以再觀看: