三秒改变世界

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

If you want to be a bad product manager, solve a problem as soon as it becomes apparent. Why let something linger when you can take care of it? A product manager needs to be seen as someone who will “do” things, not just “think” about them. When a problem comes along, you must fix it as soon as possible. Sure, you may spend a lot of your time in this way, and it may distract you from other things, though this is really the best use of your time, isn’t it?

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

If you want to be a good product manager, do not immediately solve every problem which presents itself. It is often tempting to fix an issue as soon as it appears, though there are many good reasons to not rush to address problems:

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

   If you fix the problem right away, you may not be addressing the underlying issue that caused the problem in the first place. In fact, in most cases, there is a root cause which is likely not visible on first glance. This applies to many areas in product management, most notably in addressing requests from customers. This has been discussed here in several different posts, including Stop Gathering Requirements, Follow up on requests to learn more, Find solutions that address multiple problems.

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

   However, this concept applies to other areas of product management as well. There are many times when “points of pain” which are readily apparent can be traced back to root causes. Challenges within the product development process may be attributable to several factors. For example, releasing a product with many defects may initially appear to be a problem easily solved by adding additional Quality Assurance resources, though the real problem may be lack of appropriate details in product specifications. As another example, disagreements about prioritization for development work may cause many to push for a voting system, though the disagreements may be caused by an inconsistent view of the vision, strategy, and roadmap.

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

   In medicine, there is a saying that doctors should seek to treat the disease, not the symptoms, and product managers would be well served to follow this advice as well.

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

   Letting the problem subsist for a period of time may be the only way to get others to realize its severity. Parents often tell tales of how their children learned what not to do — not to touch a stove, for example — by letting the children try it once and learn for themselves that it is a bad idea. A similar approach can be taken in product development. Whenever you try to convince people to change or implement new ideas, you need to show them why the changes you are proposing are needed. Without understanding the need for change, people will cling to the status quo.

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

   For example, you may want to implement a requirements management tool because of the problems you see with how requirements are managed. Rather than spending all of your energy telling people why it is needed and doing demos of the various products, you may be better off letting the current requirements process show its weaknesses. Perhaps you have a new version of your product which is close to release, yet you know that there are requirements which were likely lost along the way. Instead of insisting that the release be held up, you can foreshadow the issues before the launch and let the product be released. If you are correct, it will soon be apparent to all that requirements were mistakenly never implemented because of the faulty requirements management system.

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

   This tactic needs to be used carefully. As product manager, you are still responsible for the product in the end, even if you are trying to teach your team a lesson or tell them “I told you so.” However, in many cases, it is possible to use smaller projects or specific aspects of the product as examples which can prove your point and make the case for change.

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

   Problems may not be as severe as you originally thought. Often, when an issue presents itself — defect in the product, complaint from a customer, argument in a meeting — there is a rush to resolve it immediately. A product manager will often break focus from the really important things — strategy, roadmap, getting out of the office to talk with customers — and instead spend energy on “fire fighting.”

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

   However, issues are rarely so important that they must be resolved immediately, and seldom are they more important than the larger strategic activities on which a product manager should be spending his or her energy. In the heat of the moment, every problem appears to be major, though with time, the importance of most usually diminish. The truly severe problems will become apparent quickly, and this will allow you to focus more attention on the major issues rather than the crisis of the day.

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

   More time gives you more opportunity to find the right solution. In a rush to find answers before we even understand the full extent of the problem, we often choose the first idea which comes to mind. While this may be an acceptable solution, with more time to understand the issue, look for underlying problems, and brainstorm solutions, it is likely that a better solution can be determined. While more time does not guarantee more or better solutions, it is at least certain that you will not have fewer ideas or worse solutions if you provide more time to consider your options.

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

The next time a problem comes along, resist the urge to take immediate action. Take a strategic — not tactical — approach to problem-solving by evaluating the issue and considering possible underlying causes along with the overall severity. By not responding immediately to every issue, you will spend less time putting out fires and more time on the true value-adding strategic aspects of product management.

本文译自<Take a cautious approach to problem-solving>，作者是Jeff Lash。

今天早上起来，北京又是灰蒙蒙的天，无比压抑。

下午看到康国平兄在海内的分享，有个哥们儿在进行一名“Looking For Blue Skys”的项目，每天在某固定位置拍摄窗外的北京天空。顺着这个项目的链接，看到了一些和北京蓝天相关的资讯。

07年，北京245个蓝天的目标在12月30日最终惊险达标。可事实上，北京的蓝天标准低得惊人。北京使用并不具象的API(air pollution index)作为参照，蓝天定义为API<100。

讽刺的是，API是由各国自定义，若要对比中国和国际标准，需要进一步换算：

• 北京蓝天 = API 100 = 悬浮颗粒150微克/立方米。
• WHO世界卫生组织的蓝天 = API 50 = 悬浮颗粒50微克/立方米。

也就是说，我国的蓝天标准低于国际标准3倍——中华民族真是能忍辱负重的和谐儿女。这里有一份详细的中、美、香港对于蓝天的API对比文章。可以看到：北京的蓝天 = 香港的高度污染 = 美国的适度天气。文中戏称，“一国两制”在这里得到了最好的体现。

奥运步步逼近，全城兵临城下。好消息是，如果我们认为北京市环保局发布的数据真实而且可靠，进入08年8月后的前3天API分别为27、34和35，都达到了WHO标准。但愿过了灰色的糟糕的烦躁的今天，明天能够继续享受国际标准的蓝天。

另，前段时间，某环保局官员和某奥组委官位接受采访时，均和谐号：灰蒙蒙天空是因为雾，和污染无关，这位国外独立环保博客迅速进行了反驳（但他的理由看得我云里雾里，待高人指教）。

附图：8月1日从工位俯瞰西城，西山香山百望山轮廓清晰可辨。当日API 27，是近一段时间的最低点。(摄影记者: RongjunMu，鼓掌感谢)

sohu是奥运合作伙伴，所以在奥运频道做得轰轰烈烈。满北京的公交车似乎都被贴上了“看奥运，上搜狐”的广告牌。

sina想尽了一切办法打擦边球，充分展示中华人民的智慧和力量。

163却似乎对擦边球不感兴趣，倒是默默做了很多有用又有趣的事情。

比如，163的这个倒计时做得十分赞，把数字的变化图形化，一下子从飘满倒计时牌的各式网页脱颖而出，让我一下子意识到：我靠，奥运竟然只剩13天了！

好吧。。我承认，我是图表控。

update: 看不到的朋友，请点这里

很早以前，我只知道Hillary是美国总统夫人，她的总统丈夫却总在外头鬼混。那时，她在我心目中是个可怜的怨妇，背后的女人。

几年前，Hillary出了一本书，封面是她大大的笑容，书我没有看，书名也都忘了。不过那时候，我主观的以为，这只是一本贵太太讲述自己雍容生活的流水账。

一年前，我听说Hillary要竞选美国总统，有点诧异。心想，可惜了宋祖英在中国，要不然也该竞选竞选，玩一票。

半年前，Hillary呼声越来越高，各种关于大选的新闻也多了起来。我开始重新认识这个女人，她从容、果断，似乎能够让人信任。

几个月前，看到小道新闻，说Hillary坚决支持葬独。我心想您老人家就算支持，也不应该这么恶狠狠赤裸裸的啊；心想老人家似乎正确的世界观伤害到我可能错误的民族主义了，作为小愤青的我管不了那么多是与非，于是从那时候起就开始期待Hillary败选。

前几天，她宣布退出竞选，我得意的窃笑了一下。

今天抽空，上Youtube去找她的退选演讲视频（英语讲稿），有着一点幸灾乐祸。但看完整段演讲后，我不得不承认，这个女人很经典。退选演讲应该是最困难的演讲之一，不能把自己完全定位成失败者，因为背后还有一大票支持你的选民；不能继续咄咄逼人锋芒毕露，因为退选后还得指望获胜的对手不要打击你与同党；然而，也不能一味向对手示好，否则让全国人民觉得你朝三暮四，可不是闹着玩儿的。

总之，要输得有骨气，更要输得有后路。

Hillary的演讲确实很成功，尤其是谈到失败与后悔的这一段，说到了我的心里面。我翻译不出原文的感觉，请诸君自己鉴定吧：

When you hear people saying or think to yourself, "If only, or, "What if," I say, please, don't go there. Every moment wasted looking back keeps us from moving forward.

Life is too short, time is too precious, and the stakes are too high to dwell on what might have been. We have to work together for what still can be.

简单的说，就是，要向前看。

向前看，意味着失败不代表什么；向前看，意味着为了人类共同愿景可以与曾经对手重新携手；向前看，更意味着大家的未来都还有无限可能。

上一次“强烈推荐”，是在FriendFeed刚推出的时候，不过FriendFeed是慢热的，过了很久我才逐渐粘上它。

然而这一次的Plurk实在是来势汹汹。昨日见有人在海内和twitter上提起，今天大早邮箱里又有了两封邀请，还有朋友直接通过GTalk说“相信我没错的”，遂试玩了一下。之后便不亦乐乎，在这为了毕业设计焦头烂额、水深火热的6月份，Plurk的出现让我欢喜让我忧。。

总之，您快抓紧时间注册吧。

如果你不盲目的信任我，硬要先让我介绍介绍Plurk再去注册。那么好吧：Plurk是增强的Twitter，- -b。听起来很无趣，好多网站都这么介绍，至于这个Plurk为啥让我如此激动？实践一下吧，实践是检验真理的唯一标准。