举个例子，假设你发现团队使用的需求管理软件存在着很大的问题，假如你希望马上修改它，或许得花大量精力去告诉大家修改的意义，还得制作demo进 行说明。但如果让这个需求管理软件继续运转一段时间，让它自己暴露出弱点，可能是一种更好的办法。因为需求管理软件的问题，在新产品上线前，你会发现有些 初制定的需求并没有实现。此时，你可以告知大家这些遗漏的需求，但是不需要为之耽误了上线时间。如果你是正确的，要不了多久，大家会意识到，因为使用 了那个糟糕的需求管理软件，才导致产品出现一些无法挽救的Bug。

提醒，本方法需十分小心的使用。作为PM，算你本意是为了让同事们更透彻的看清问题，也不能忘了你是该产品终成败的负责人。所以多数情况下，使用本方法时，好选择小项目来作为案例。

问题可能没有你想象中那么严重。每次问题出现的时候??产品暴露了Bug，用户发出抱怨，会议上的争论??看上去总是迫切得非解决不可。于是，PM不得不暂时暂停正在进行的真正关键工作??战略、计划、用户调研??而把精力用在四处“灭火”上。

然而，必须立即解决的Bug其实很少。同时，与PM应该着重思考的产品方向等问题比起来，这些Bug的重要性实在很低。每个Bug都 有看上去万分关键的时刻，但过段时间后，它们似乎都变得无关紧要了。事实上，真正严重的Bug会迅速暴露出来。牢记这一点，会让PM把时间用在刀刃上，而 不是每天都在处理危机。

花更多的时间可以找到更完美的解决方案。若在全面了解Bug之前，急着去为Bug寻找答案，我们通常会选择脑 海中冒出来的第一个解决方案。这可能也算是一个过得去的方案，不过若我们花更多时间来分析此Bug，找到其根本诱因，甚至来一场头脑风暴，或许我们能发现 更完美的解决方案。当然了，花更多时间也不一定找得到更棒的方案，但至少，花了时间之后，得到的不会是更少的备选方案或更差的解决方案。

下一次遭遇Bug时，请别十万火急。PM需要有战略眼光（不是战术），请先分析Bug，找到根本诱因，并衡量全局重要性，再对Bug进行解决。若不 是每一次都着急解决每一个Bug，PM可以花更少的时间四处“灭火”，从而拥有更多的时间去思考产品战略??如何给用户带去更多的价值。