前陣子在《產品經理最佳實務》看到一個章節在描述產品經理的道歉情境，不論是需求漏開、結論下錯、時程錯估，產品經理在各種場合有時需要作為道歉的角色，但有些情境也不一定要真的「道歉」，這篇會記錄不同場合的表達方式。
一、為何產品經理需要道歉藝術
⠀⠀
從產品規劃到最終上線難免會遇到大大小小的失誤，像是：- 產品規劃有漏盤點情境
- 時程規劃完但開發到一半發現調整範圍變多
- 中途被插件導致原需求延後交付
這些都需要產品經理向利害關係人解釋原因，有些比較嚴重的話可能會需要道歉，但道歉不是「向利害關係人承認錯誤」就結束，心態比較像是「認知到這件事的嚴重性，因此做了 A/B/C 的措施進行改善，想展現積極處理的態度讓有受影響的人」。
但為什麼產品經理常常是需要扮演這個道歉的角色呢？原因通常產品經理作為「產品」與「用戶」之間的橋樑，既了解產品的技術限制與商業考量，也了解用戶的需求與期待，正因為這種定位，使得產品經理在重要關頭時，常需要出面解釋或道歉。
⠀⠀
二、產品失誤的常見類型及應對方式
⠀⠀
具體來說產品經理會面臨哪些產品失誤的道歉情境呢？常見有這三種：
（一）功能失誤
比較典型的像是功能上線後出現異常 Bug，導致消費者無法正常下單、商品無法正常上架、訂單資料異常 … 等，影響到原本使用者流程等。
有些情境若是很隱諱的 Bug 或長期就存在的，產品經理有時不需直接道歉，可以用「這個是既有邏輯，不是這次上線改壞的，但我們會先確認影響範圍並安排修復」來應對。
（二）溝通失誤
原本答應需求方預計會在 OO 月交付功能上線，當因為種種原因，不論是隕石插件、或開發延遲，導致上線時間延後，這時產品經理也會需要到前線去解釋原因。
解釋的方式會以「我們因為什麼原因而延遲，這段期間需求方可以先用 OO 替代方案進行」來和對方溝通。
（三）期待失誤
跟溝通失誤有點像，但期待失誤比較像是「期待值管理」沒掌控好，例如需求方原本以為使用者路徑是「A > B > C」，結果功能做完其實要「A > B > C > D > E」，讓使用者覺得功能跟想像不一樣、超難用，導致衍生的客訴抱怨。
這時產品經理也不一定要立即道歉，而是先掌握期待落差的原因，確認需求方的情境和當時規劃為什麼有落差，先了解原因再進行解釋。
⠀⠀
三、解釋前的準備工作和五大原則
⠀⠀
遇到上述情境，通常產品經理要先做一些事前調查，以功能失誤為例：
- 發生緣由：真的是產品經理個人有做錯導致的失誤？還是系統現況導致客訴？還是不可抗力因素？這會影響到要用「解釋」的說法還是「道歉」的說法。
- 影響範圍：事情發生後，現在誰被影響到？影響程度是什麼？需要立即修復調整嗎？有造成公司或對方什麼損失嗎？這些會影響到要下一步要做什麼行動。
- 解決方案：是否有立即修復的必要？是否有賠償問題？對方是否有索取補償？會影響到產品經理層級能否自己處理。
⠀⠀
上述都調查完之後，接著有幾個原則：
1. 及時：把握黃金時間
當問題發生時，若很嚴重的話通常需要在短時間內（1 hr 內）獲得足夠資訊，若時間到仍找不到發生原因，則也要盡速向利害關係人說「已經收到，但正在釐清中，預計 30mins 後回報進度」，讓各窗口知道產品經理已經收到問題正在積極處理。
2. 真誠：透明坦承狀況
對於公司內的利害關係人，保持透明是比較有效的第一步（但也看各公司企業文化），以我待過的產品團隊，直接透明說明現在使用者遇到的問題，會讓開發團隊更願意講真話，也能更快找到解決方向。
3. 明確：提出解決方案
和工程師確認完問題和修正方向後，也要盡速向利害關係人說明下一步，例如「預計 16:00 進行 Hotfix，影響客戶清單如下」等行動，讓對應的客戶經理或業務知道要怎麼回應給客戶。
4. 預防：如何避免再發生
當上述都解決完之後，最後進到 Retro，也是各窗口會在意的「如何避免這件事再次發生」，因此正也考驗產品經理到底有沒有釐清問題怎麼發生的，是工程師改壞了？還是需求寫錯了？測試沒踩到？雖然釐清完不見得可以 100% 根治，但至少讓內部開發團隊知道原因後，可以降低再發生的機率。
⠀⠀
四、總結
⠀⠀
正常情況下，有負面問題都會影響到產品經理的信任（Credit），但也不得不說在每次問題發生後，都會伴隨心理素質的成長，有時候可以觀察到「某些人特別在意什麼」。
例如客戶經理很在意「如何修復」、主管很在意「如何預防」、技術端很在意「為什麼開發方向不符需求」，這都仰賴產品經理去串起這些資訊落差。
道歉的最終目標不僅是平息當前的危機（有時其實只要解釋，還不用到道歉的等級），更是重塑用戶對產品的信任。
