產品經理都在規劃新產品嗎?那些沒看到的產品營運日常|EP79

產品經理都在規劃新產品嗎?那些沒看到的產品營運日常|EP79

更新於 發佈於 閱讀時間約 6 分鐘

產品經理的工作不只規劃新功能、開展 Roadmap,其實有滿多時間需要處理營運工作,像是小功能優化、bug 修復和資料維護等 ,這些看似微小,但常常是確保產品穩定性和用戶體驗的基礎。

raw-image

一、產品營運的定義與範疇

⠀⠀

這裡指的產品營運是「規劃新功能之外的日常運行和維護相關任務」,包括幾個方面:

  • 功能優化:對現有功能進行微調,以提升用戶體驗或避免非預期的操作,例如「增加欄位的錯誤提示、優化表單的填寫流程、增加操作時的阻擋條件」。
  • Bug 釐清:修復功能邏輯錯誤,以確保產品穩定性,例如「修復特定付款方式造成的訂單錯誤、修復商品上架的欄位阻擋邏輯」。
  • 修改資料:更新產品的資料,以確保時效性,例如「更新使用者的時區、大量更新商品頁的銷售起訖日期」。

這些看似簡單,但都是產品日常維運的基礎,產品經理需要確保這些任務都能在每週都能被及時處理,減少第一線人員收到客訴。

⠀⠀


⠀⠀

二、產品營運與產品規劃的差異

⠀⠀

上述提到的產品營運,其實在產品規劃中也會碰到,那為什麼要特別區分產品營運呢?以下再描述一下差異:

  1. 時間急迫
    在產品規劃中,若專案延遲,產品經理通常可以與利害關係人協調、延後上線時間,但產品營運若遇到的是 Bug,通常不會是單一個案,而是固定比例的人都會遇到,像是 0.01% 的人在某個情境會交易失敗,就會讓消費者和客戶對系統產生不信任甚至留一星負評,因此這個情境都需要緊急 Hotfix 處理。
  2. 客訴成本
    某些功能雖然不算是 Bug,但因為在使用者操作上容易造成誤會,因此可能讓客服人員每天都會有 10 個詢問,這種雖然非實質造成公司損失,但耗費的客服成本也相當巨大,因此這類型也會被列入緊急項目,在主要專案過程的插件處理。

⠀⠀

雖然上面提到的情境都偏向緊急事項,但產品經理在處理維運任務時,難免也會遇到一些挑戰,像是:

  1. 緊急程度的判斷
    有時產品經理收到一個 bug,但第一時間可能不確定是極少數使用者的問題還是多數狀況,因此需要當下先自行還原情境,根據使用者操作路徑確認是否有異常。
  2. 影響程度的判斷
    收到 Bug 後,若跟交易有關,有時候還要處理賠付問題,以電商平台為例,若消費者在一段時間都無法下單,可能需要賠償給該客戶,為了減少賠付金額,因此也需要盡快修復線上狀況。
  3. 資源分配的協調
    在滿檔的開發團隊中,有時所有工程師都手上有專案或任務在做,產品經理需要當下決定哪個任務要優先執行、哪個可以先暫緩,確保工程師可以根據你的判斷進行工作調整。
  4. 部門協作的溝通
    有些功能因為是多平台都遇到的 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 幾乎一開始都會碰到產品維運,先從處理日常釐清單開始了解產品全貌,可以更快速了解使用者怎麼操作功能、也可以知道系統通常有哪些漏洞或限制(這些有時從產品教學文件看不出來)。

如對這系列文章有興趣可以再觀看:

avatar-img
張家惟 Evan Chang的沙龍
103會員
180內容數
《思維的創意想像》是工作之餘發起的 Side Project,因為近期快速吸收各種資訊跟商業知識(Input),但一直沒有地方輸出(Output),因此想透過這系列記錄學到的內容,包含商業知識、產業洞見,或是職場分享等等,目前已有產品開發、客戶成功、社群行銷、思維增長、職場日記等系列文章。
留言
avatar-img
留言分享你的想法!
從 ChatGPT、Claude、Gemini 各種模型的出現,「AI 是否會取代 PM / UX / RD」一直是軟體業在討論的話題,AI 已能撰寫 PRD 產品需求文件、分析用戶、設計原型 Prototype,甚至提供產品決策建議,甚至對於一些產品主管來說,只會執行的初級產品經理職缺可能會越來越
在電商產業擔任產品經理,最常被問的就是「AI 可以在電商平台做哪些事」,像是個人化商品推薦、文案生成、加速上架、AI 客服等,市面上已陸續有 AI 功能逐漸釋出,但 AI 協助購物這段流程要怎麼進行,這篇想記錄初步想法。
Retrospective 是敏捷流程中的回顧環節,對產品經理來說是一個可以回顧過往、反思的時刻,這篇會記錄 Retro 的重點,以及產品經理可以如何運用 Retro,讓產品團隊提升開發效率。
從 ChatGPT、Claude、Gemini 各種模型的出現,「AI 是否會取代 PM / UX / RD」一直是軟體業在討論的話題,AI 已能撰寫 PRD 產品需求文件、分析用戶、設計原型 Prototype,甚至提供產品決策建議,甚至對於一些產品主管來說,只會執行的初級產品經理職缺可能會越來越
在電商產業擔任產品經理,最常被問的就是「AI 可以在電商平台做哪些事」,像是個人化商品推薦、文案生成、加速上架、AI 客服等,市面上已陸續有 AI 功能逐漸釋出,但 AI 協助購物這段流程要怎麼進行,這篇想記錄初步想法。
Retrospective 是敏捷流程中的回顧環節,對產品經理來說是一個可以回顧過往、反思的時刻,這篇會記錄 Retro 的重點,以及產品經理可以如何運用 Retro,讓產品團隊提升開發效率。