原文作者：Jeff Lash 原文鏈接：Take a cautious approach to problem-solving 翻譯：遠騁

如果你希望成為一個失敗的產品經理，在遇到bug時，請立即動手修復它。

如果bug可以立即被修復，為何要一拖再拖？PM應該是一位“執行者”，而非總是紙上談兵的“思考者”。當問題出現后，必須在第一時間搞定它。當然，這樣做可能浪費大量的時間，也可能分散精力，不過這是一位PM的最佳時間分配方式，不是嗎？

如果你希望成為一個成功的產品經理，在遇到bug時，請不要總是立即著急的修復它。

不可否認，我們在遇到問題時，總是迫不及待的想改正。然而事實上，其實根本不用那么的十萬火急，理由如下：

1. 如果迅速解決了問題，你可能會忽略問題的根本原因。 在大多數時候，每個問題都有其根本誘因。在問題剛暴露的時候，誘因一般深藏不露，有很多的可能性。 筆者認為，根本誘因最可能來自于需求確認階段。多篇文章都探討了這方面的問題，比如：  Stop Gathering Requirements, Follow up on requests to learn more, Find solutions that address multiple problems.

   同樣，在產品管理的其他階段，這個理論也適用。有些問題可以很容易就找到根本誘因，但產品開發的真正挑戰來自各種不穩定的因素。 例如，有時候一款漏 洞百出的產品在上線之初，只暴露了冰山一角：一個很小的Bug，似乎十分容易解決。 另一個例子，開發過程中，團隊成員對各項功能的優先級有爭議時，靠“民主投票”來做決策，而忘了引發爭議的源頭：對產品遠景、戰略及計劃缺乏共識。

   醫生的任務不是治標，而是治本。對于PM而言，道理一模一樣。

2. 讓問題暴露一段時間，或許是讓大家認識到其嚴重性的唯一方法。 很多父母都會說，他們的小孩吃一塹才長一智--例如，不去摸滾燙的炭爐--若小孩自己被炭爐燙傷一次后，他們自然會明白那東西是摸不得的。在產品開發過程 中，存在著同樣的道理。當你試圖請同事修改或改進某功能時，你需要解釋這是為了什么。如果大家不明白改進的意義，自然會無動于衷。

   舉 個例子，假設你發現團隊使用的需求管理軟件存在著很大的問題，假如你希望馬上修改它，或許得花大量精力去告訴大家修改的意義，還得制作demo進行說明。 但如果讓這個需求管理軟件繼續運轉一段時間，讓它自己暴露出弱點，可能是一種更好的辦法。因為需求管理軟件的問題，在新產品上線前，你會發現有些 最初制定的需求并沒有實現。此時，你可以告知大家這些遺漏的需求，但是不需要為之耽誤了上線時間。如果你是正確的，要不了多久，大家就會意識到，因為使用 了那個糟糕的需求管理軟件，才導致產品出現一些無法挽救的Bug。

   提醒，本方法需十分小心的使用。作為PM，就算你本意是為了讓同事們更透徹的看清問題，也不能忘了你是該產品最終成敗的負責人。所以多數情況下，使用本方法時，最好選擇小項目來作為案例。

3. 問題可能沒有你想象中那么嚴重。 每次問題出現的時候--產品暴露了Bug，用戶發出抱怨，會議上的爭論--看上去總是迫切得非解決不可。于是，PM不得不暫時暫停正在進行的真正關鍵工作--戰略、計劃、用戶調研--而把精力用在四處“滅火”上。

4. 然而，必須立即解決的Bug其實很少。 同時，與PM應該著重思考的產品方向等問題比起來，這些Bug的重要性實 在很低。每個Bug都 有看上去萬分關鍵的時刻，但過段時間后，它們似乎都變得無關緊要了。事實上，真正嚴重的Bug會迅速暴露出來。牢記這一點，會讓PM把時間用在刀刃上，而 不是每天都在處理危機。

5. 花更多的時間可以找到更完美的解決方案。 若 在全面了解Bug之前，就急著去為Bug尋找答案，我們通常會選擇腦 海中冒出來的第一個解決方案。這可能也算是一個過得去的方案，不過若我們花更多時間來分析此Bug，找到其根本誘因，甚至來一場頭腦風暴，或許我們能發現 更完美的解決方案。當然了，花更多時間也不一定就找得到更棒的方案，但至少，花了時間之后，得到的不會是更少的備選方案或更差的解決方案。

下 一次遭遇Bug時，請別十萬火急。PM需要有戰略眼光（不是戰術），請先分析Bug，找到根本誘因，并衡量全局重要性，再對Bug進行 解決。若不是每一次都著急解決每一個Bug，PM可以花更少的時間四處“滅火”，從而擁有更多的時間去思考產品戰略--如何給用戶帶去更多的價值。