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

如果你希望成為一個成功的產品經理，在遇到bug時，請不要總是立即著急的修復它。不可否認，我們在遇到問題時，總是迫不及待的想改正。然而事實上，其實根本不用那麼的十萬火急，理由如下：

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

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

醫生治療的是疾病，而不是治療症狀（譯註：治療感冒或支氣管炎，而非咳嗽）。醫生的任務不是治標，而是治本。對於PM而言，道理一模一樣。

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

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

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

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

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

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

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