做為產品經理，多少都會遇到 RD 出包的情況，這個時候，除了看平常這位 RD 的表現之外，就是看他跟所有人的關係好不好，再來，就是看看有沒有需要藉由這次的機會，來敲山震虎。
釐清問題，先別捅刀
收集問題情報
我知道這個時候蠻多 PM 會見獵心喜的準備要向老闆報告，但報告的多半是要告訴老闆這個出包情況有多嚴重，完全是某位 RD 或是某個部門的 RD 的問題。
身為產品經理，這個時候其實不該急著捅刀RD，應該是先解決用戶的問題，不過，但你可以晚一點再捅。
你現在要做的，就是盡可能的收集出包問題的資訊，像是用戶回報了什麼內容，我們能不能取得用戶的操作錄影，甚至於能不能有Log檔可以取得，這些情報一定要先想法拿到手，不然，RD也是兩手一攤，說我沒辦法通靈。
什麼？你沒有放log？那麼重要的用戶登入流程你沒放log，那麼請問你要怎麼找出用戶的步驟重現bug？通靈？還是觀落陰？光這是這一題，大概就可以和RD吵很久了……。
先試著重現問題
我會先在測試環境測試看看問題是否會發生，若可以，則表示這個問題我應該在測試環境就要發現，但是在測試環境沒有發現的話，就再往正式環境來測試。
若是這個問題只發生在正式環境，那麼，這個問題到底是怎麼觸發的呢？以及你需要找出這個問題影響到的範圍會有多大。
我就曾經遇過，工程師找了兩個星期，都找不到為什麼這個問題只會發生在正式環境，而測試環境不會出現問題。
因為我們的測試環境和正式環境是完全相同的⋯⋯。
最後才發現，是防火牆造成的，而之所以查那麼久，就是因為只有在正式環境才有防火牆，所以，這也是一次的經驗學習，只是很花時間就是了。
如果你今天做的是APP產品，那麼還得要加上追溯前面幾個版本，確認這個問題到底是哪一版開始有的，因為這影響到不同版本的用戶，身為產品經理的你應該要知道怎麼應對。
在測試重現問題時，要一步一步的試驗和調整，找出最關鍵的變數，不要試著一次性想解決所有問題。
此時，RD 也不是閒置狀態，他們應該也有人正在看問題（如果你祖上積德遇到好 RD 的話），但多半應該是進去程式碼在看看整個邏輯或是最近有沒有動到code，反覆的在查驗，當然，前提是你家的RD的認知要先正確，他們才會主動的先去做這件事情。
溝通下次可以怎麼避免
先問出root cause
找到問題之後，接下來，先讓RD解釋這個問題的root cause，提出目前可以進行的解法，讓產品經理可以評估該怎麼做，而且同時要提出你的觀點、擔憂等等。
確認這個任務的優先級
知道了root cause之後，接下來就是要討論問題對用戶的影響，是否如產品經理所想的一樣在某個範圍之下。
會需要這樣討論的原因，是要決定這個問題的優先級，而且，要請RD定出一個時間表，一來是要告訴用戶我們已經知道問題，我們預計何時修復好，二來是要安撫內部單位，表示問題都在我們的掌控之中。
但是，工程師無法提出時間點來修好問題的話，那就要經由產品經理的同意將此問題列為Known issues，再發出公告給各個相關單位，直到後續RD想到解法為止。
捅刀前，一定要能站的住腳
接下來，就是重頭戲了，這位RD或是這個部門的RD，是否平常就和大家溝通良好，主動要任務來做，而不會推卸責任，遇到新功能、調整功能就強烈反對等等…，一大堆產品經理最討厭的地方。
但是，今天你決定要和RD一起面對老闆的拍桌大罵，那麼就一起找老闆吧！你帶著RD，全程由你開口說明這些問題的源頭、問題點、現況打算怎麼處理，甚至於還要講出：是我沒有把這個功能考慮的更清楚，來幫RD坦一下。
不過，當你決定要捅爆RD的話，就是不一樣的作法了，先把事情的源頭到目前的現況寫成一封信，loop所有相關人的「主管」，直接在信裡說明因為RD在開發上的錯誤，造成今天有這樣的用戶回報……，以及發生之後，產品經理目前做了什麼協助等等…。
最後，再藉由這個機會，提出流程制度上的改變，而這封信的目的就是要獲得公司的認同。
例如，我曾經就是利用這樣的機會，替全公司定義出怎麼出版本的流程：
在我去這間公司之前，都一直使用「口耳相傳」的方式來出版本。
產品經理用嘴巴和RD說要做什麼，RD再用嘴巴和QA說做好了、可以測了，然後QA再用嘴巴跟產品經理講測好了，可以上架了……，而這種有趣的機制，在我們南部知名大學博土老闆還在西提餐廳裡聚餐時親口說出「我覺得我們的流程很好」……。
所以你說說，這種情況是不是應該「藉機」調整RD單位的流程？因此，產品經理你要記得，該出手的時候一定要出手，但不要只是為了自己，而是要為了公司、為了用戶！