Charles Zhang玩博客

最近李彦宏插手百度贴吧改版的消息在网上多有讨论。李彦宏最后拍板将改过的贴吧页面又给退回到过去的贴吧。然后，李彦宏自己又发文章，征询用户的意见。

互联网产品和其他产品设计的独特之处是，用户的意见似乎一直很重要。因此，做CEO的去兼做产品经理，似乎就天经地义了。特别是中国成功的互联网公司，从百度到腾讯，到网易到sohu，似乎CEO都喜欢去做产品经理。

为什么很多CEO总想做产品经理呢？

因为，我们的很多网站的创新还不够。怕出错。这一方面是因为互联网管得太死，太过有创意的产品设计，又可能碰了高压线。那不如不创新，在旧有的模式上打转，起码不会错得离谱。CEO这时候往往就变成了一个产品经理，什么都想管，把自己的习惯，传递给真正的产品设计和产品开发管理人员。

我们的产品宣传方法不多。很多企业做了一个好产品，非得要CEO出来宣传不可。否则似乎就没人用。比如谷歌中国的很多款特色产品发布。都有李开复的身影在其中。这就很不对。诚然，谷歌中国刚进入中国时，找李开复来宣传自己的产品，能起到最大的效果。但如果每一款产品，不管好坏都有李开复老师的影子，会给人很不好的感觉。奥，李开复又看中了这个产品。潜台词是，这产品，行不行？最近的谷歌mp3搜索就有这个嫌疑。“用户的需求在哪里？”我们没看到。

对用户的理解办法不多。很多互联网企业的新产品，都依赖于创始人或CEO 对互联网发展的超前理解。但这种超前理解，有时候也能成为制约产品创新的主要阻碍。一个企业如果很成熟了后，一定要对加强对用户的理解。我们很多做咨询的人，总梦想成为CEO的助手，总梦想自己的想法能被企业CEO所看重，其实都是对用户理解不足所引起的。如果你自信理解了用户，你就不会被CEO所左右。现在的互联网企业的CEO，每天除了应对各种政策麻烦外，多数都在财务报表中迷失。他们对用户的理解，不一定比一个外人更清楚。让CEO来做产品经理，无疑会给企业带来很多麻烦。好的CEO，应能看到2年后行业的变化，能熟知自己企业内部人员的优势，能真正有信心，自己制造的东西，是用户需要并且喜欢的。不能看到别人家的产品招人喜欢，自己就认为自己做一个类似的产品也会招人喜欢。特别是互联网，可替代可拷贝性这么强，用户抬脚就走，几乎来不及跟你打个招呼。

救火队员型的CEO，处理产品创新的办法不会很多。他们应当做的是在背后推动产品创新团队，充分了解竞争对手后，给自己的产品提出一个基本的需要超越对手的功能。如果一味地模仿或按自己的理解来“全权设计”产品，或“批准产品的出炉”。这样的产品，基本上不会受到用户的喜欢。当然，用户也不能幻想着做网站的CEO，不能以为自己的需求，就是网站必须为你第一解决的需求。这样也会让自己喜欢的网站，陷入迷茫。

如果你希望成为一个失败的产品经理，在遇到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.

何谓产品经理，英文product manager，但这样理解不能仅限于产品，很多公司产品经理其实也是一名间接的技术，真正意义上的PM，应该是product and marketing，更偏重于的应该是marketing，而不是product，这是大PM的概念，单纯的小PM仅仅是做一些产品的文档，对业绩对市场以及销售策略都不关心，这仅仅是产品的PM了。

      1.首先从引入一个产品开始，这就需要对市场的透彻了解，引入一个产品不是这个产品好，好的产品非常多，而是要看公司在引入这个产品后能不能有利益增长（任何公司盈利都是第一），那么这个产品在公司整个产品线中位置是什么，给公司带来什么样的解决能力，这个解决能力能不能实际由销售转换成利益，与其它产品的互补性如何，该产品的生命周期有多长，在该生命周期内市场的竞争对手如何，什么时候该产品可能会Phase out掉，等等，这些都是要考虑的问题。引入一个产品是非常容易的，但引入后不能销售出去，变成一堆库存，这就不容易解决了。

      2.产品的价格策略：价格策略是由市场定位的，而不是由产品定位。简单地说，虽然你的产品功能好，但没有知名度，同一等级的产品你的性能虽然好，但价格还是要低，低多少没有具体指标，多了公司没效益，少了产品销售不出，有一个方法，那就是看主要竞争对手的价格，以对手价格作为参照基础。但价格的变动宜主动不宜被动，今天TP_Link引领市场上的价格透明趋势，就是这个道理。

      3.销售策略问题：这虽然很多公司是由销售来完成，但实际PM要负责一部分。要很清楚下个月的可能完成的业绩是多少，这个业绩是哪些产品组成的，其中占前 10名的产品是什么。促销是种常见的销售策略，当我们想把一个产品做到占份额的前10位时，就需要开动脑筋了，最简单的方法就是促销，但促销不是万金油，搞不好会适得其反。

      4.市场活动：这可能是市场部的内容，但起码PM要主导一些。比如当一个新产品出来时，要提前多长时间做宣传，预计要达到什么效果，每一季度的主导的广告内容是什么，这都要有个清楚的纲要。当然各公司环境不同，分工是有区别。

      5. 库存问题：这是PM要关心的很重要的一个方面。库存多了，卖不掉到时候要降价，公司损失，但库存少了，没产品卖，也有损失。特别是IT这个行业，成本每季度都在降，所以这个问题要好好解决的。其中有几个参数要把握准就行，产品的LT，当前库存量（每周统计），产品的月RUNRATE，理解好这几个方面，基本能保证库存，千万不能完全相信销售的FO，到时候造成一堆库存，还得要PM来解决掉。

      6.产品资料：这是PM份内的工作，基本工作。

      还有一些方面，今天整理得比较零乱，想到哪写到哪了。做PM是一件非常复杂也很磨炼人的事情，从技术到市场，从产品到销售，每个环节都要很踏实的去想清楚，而不是像一些人把PM当成管理，浮而不实。

      作PM很重要的一条，就是做人，当销售没业绩时，一定会来找PM麻烦，找出各种理由，所以做人要到位，当然不能讨全部人的好，PM要有一定的强势，但要刚中带柔，销售只是关注自己的业绩，PM是关注全公司的业绩，所以做人是比较难的。这点超过做产品。

      各个公司环境不同，PM的性质也不同了，或许不能全部作到这些（有些今晚可能想不起来写了），但要有颗去除浮华的心来做，我个人感受最深的一点是，目前由于社会竞争非常激烈，人才也多，所以一些大道理大家都很明白，不是企业家可以说出比企业家更动听的道理，但实际操作起来就不是那回事了。现在人们都说“专业”这个词，所以大家都表现得很专业，话语、气势等等都要拿捏一下，以表现出来，但做起来又不是这样了。这点我是非常讨厌的，这样的人也很多。所以要自己去思考，独立思考是很重要的，并要有实际去做。