產品經理都在規劃新產品嗎？那些沒看到的產品營運日常｜EP79
產品經理的工作不只規劃新功能、開展 Roadmap，其實有滿多時間需要處理營運工作，像是小功能優化、bug 修復和資料維護等 ，這些看似微小，但常常是確保產品穩定性和用戶體驗的基礎。
一、產品營運的定義與範疇
⠀⠀
這裡指的產品營運是「規劃新功能之外的日常運行和維護相關任務」，包括幾個方面：
- 功能優化：對現有功能進行微調，以提升用戶體驗或避免非預期的操作，例如「增加欄位的錯誤提示、優化表單的填寫流程、增加操作時的阻擋條件」。
- Bug 釐清：修復功能邏輯錯誤，以確保產品穩定性，例如「修復特定付款方式造成的訂單錯誤、修復商品上架的欄位阻擋邏輯」。
- 修改資料：更新產品的資料，以確保時效性，例如「更新使用者的時區、大量更新商品頁的銷售起訖日期」。
這些看似簡單，但都是產品日常維運的基礎，產品經理需要確保這些任務都能在每週都能被及時處理，減少第一線人員收到客訴。
⠀⠀
⠀⠀
二、產品營運與產品規劃的差異
⠀⠀
上述提到的產品營運，其實在產品規劃中也會碰到，那為什麼要特別區分產品營運呢？以下再描述一下差異：
- 時間急迫
在產品規劃中，若專案延遲，產品經理通常可以與利害關係人協調、延後上線時間，但產品營運若遇到的是 Bug，通常不會是單一個案，而是固定比例的人都會遇到，像是 0.01% 的人在某個情境會交易失敗，就會讓消費者和客戶對系統產生不信任甚至留一星負評，因此這個情境都需要緊急 Hotfix 處理。 - 客訴成本
某些功能雖然不算是 Bug，但因為在使用者操作上容易造成誤會，因此可能讓客服人員每天都會有 10 個詢問，這種雖然非實質造成公司損失，但耗費的客服成本也相當巨大，因此這類型也會被列入緊急項目，在主要專案過程的插件處理。
⠀⠀
雖然上面提到的情境都偏向緊急事項，但產品經理在處理維運任務時，難免也會遇到一些挑戰，像是：
- 緊急程度的判斷
有時產品經理收到一個 bug，但第一時間可能不確定是極少數使用者的問題還是多數狀況，因此需要當下先自行還原情境，根據使用者操作路徑確認是否有異常。 - 影響程度的判斷
收到 Bug 後，若跟交易有關，有時候還要處理賠付問題，以電商平台為例，若消費者在一段時間都無法下單，可能需要賠償給該客戶，為了減少賠付金額，因此也需要盡快修復線上狀況。 - 資源分配的協調
在滿檔的開發團隊中，有時所有工程師都手上有專案或任務在做，產品經理需要當下決定哪個任務要優先執行、哪個可以先暫緩，確保工程師可以根據你的判斷進行工作調整。 - 部門協作的溝通
有些功能因為是多平台都遇到的 Bug，例如 web、ios app、android app都需要一起調整，這時產品經理需要協調各組工程師，確保大家可以一起修復的某個情境。
⠀⠀
⠀⠀
三、產品營運的工作心得
⠀⠀
通常 PM 都會想要接觸產品策略規劃、產品數據分析，而產品營運比較偏行政營運類的則比較少人願意接觸，但實際上產品營運卻也是產品重要的角色，特別是 Jr.PM 若剛進公司，可以透過處理維運單快速掌握產品現況！
因為這個角色會很常需要跨部門合作：
- 業務：收集客戶反饋並納入優化計劃，滿足 B 端客戶的小需求。
- 客服：處理用戶投訴並分析常見問題，制定長期解決方案。
- 技術：協調開發資源，確保 bug 修復和功能優化的及時性。
在收集這些維運項目的過程中，可以更知道第一線使用者都在抱怨什麼、最常操作什麼功能，但也會有一些缺點。
以大部分公司的產品團隊，PM 在晉升時難免都會看績效，而績效多半根據「你過去這一年做過多少好成績，像是中大型功能、或功能是否有提升具體數據、或是否協助客戶簽下大客戶、或是否針對產品提出新的規劃洞見」，而這些都是做產品營運比較不會碰到的（但有時也跟資歷有關，有些公司可能是 Sr.PM 才會碰到策略面）。
⠀⠀
產品營運雖然佔約工作中的 20% 左右，但卻能夠提升產品穩定性和客戶滿意度。
- 對 B 端客戶來說，代表更可靠的系統品質。
- 對 C 端消費者來說，代表更流暢的體驗和更少客訴。
而在 PM 本身的能力累積，也有幾個面向：
- 決策依據：通過分析異常行為，釐清「若不修復會造成什麼嚴重後果」來進行提案，累積自己的決策思維。
- 優先排序：根據問題的影響範圍和頻率，決定開發資源分配，「需要立即插件處理，且要今天 5 點 Hotfix 修復上線」，累積自己的優先級排序原則。
- 團隊溝通：在不斷與工程團隊、測試人員合作過程中，這類小型的需求修復，也可以培養團隊溝通的默契。
⠀⠀
⠀⠀
四、結論
⠀⠀
產品營運幾乎是每個 PM 都會遇到的日常工作，在和不同公司的 PM 交流過程中，我發現也並不是每個 PM 都可以 100% 時間都在做「新功能規劃、策略發想」，其實都有 20-40% 的時間是維運釐清，有些維運（Task）在釐清完，也會提高到專案等級（User Story / Project）。
另外在我之前的工作經驗，Jr.PM 幾乎一開始都會碰到產品維運，先從處理日常釐清單開始了解產品全貌，可以更快速了解使用者怎麼操作功能、也可以知道系統通常有哪些漏洞或限制（這些有時從產品教學文件看不出來）。
如對這系列文章有興趣可以再觀看：
