原文作者：Jeff Lash
原文链接：Take a cautious approach to problem-solving
翻译：远骋
如果你希望成为一个失败的产品经理，在遇到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可以花更少的时间四处“灭火”，从而拥有更多的时间去思考产品战略--如何给用户带去更多的价值。