如果你希望成为一个失败的产品经理，在遇到bug时，请立即动手修复它。如果bug可以立即被修复，为何要一拖再拖？PM应该是一位“执行者”，而非总是纸上谈兵的“思考者”。当问题出现后，必须在第一时间搞定它。当然，这样做可能浪费大量的时间，也可能分散精力，不过这是一位PM的佳时间分配方式，不是吗？

如果你希望成为一个成功的产品经理，在遇到bug时，请不要总是立即着急的修复它。不可否认，我们在遇到问题时，总是迫不及待的想改正。然而事实上，其实根本不用那么的十万火急，理由如下：

如果迅速解决了问题，你可能会忽略问题的根本原因。在大多数时候，每个问题都有其根本诱因。在问题刚暴露的时候，诱因一般深藏不露，有很多的可能性。笔者认为，根本诱因可能来自于需求确认阶段。多篇文章都探讨了这方面的问题，比如： Stop Gathering Requirements， Follow up on requests to learn more， Find solutions that address multiple problems.

同样，在产品管理的其他阶段，这个理论也适用。有些问题可以很容易找到根本诱因，但产品开发的真正挑战来自各种不稳定的因素。例如，有时候一款漏 洞百出的产品在上线之初，只暴露了冰山一角：一个很小的Bug，似乎十分容易解决。另一个例子，开发过程中，团队成员对各项功能的优先级有争议时，靠“民主投票”来做决策，而忘了引发争议的源头：对产品远景、战略及计划缺乏共识。

医生治疗的是疾病，而不是治疗症状（译注：治疗感冒或支气管炎，而非咳嗽）。医生的任务不是治标，而是治本。对于PM而言，道理一模一样。

让问题暴露一段时间，或许是让大家认识到其严重性的方法。很多父母都会说，他们的小孩吃一堑才长一智??例 如，不去摸滚烫的炭炉??若小孩自己被炭炉烫伤一次后，他们自然会明白那东西是摸不得的。在产品开发过程中，存在着同样的道理。当你试图请同事修改或改进 某功能时，你需要解释这是为了什么。如果大家不明白改进的意义，自然会无动于衷。