文/老谭
通过上一章节的学习，我们懂得了好的产品经理背后是一个强大的协作团队。本章我们一起来学习产品经理最容易掉进哪些坑？
本章的开头，作者就介绍了几个全球著名的大公司曾经在创造新产品时候的失败案例，比如：
可口可乐公司设计了新可口可乐（New Coke）来与更甜的百事可乐竞争，结果引发了忠实用户的大规模抗议，新可口可乐被迅速撤回，用回原来的配方。
索尼Betamax（Beta制大尺寸磁带录像系统）在特性比拼中输给了VHS（Video Home System的缩写，意为家用录像系统），因为它发起反对一盘磁带上录下一整部电影。
福特公司的埃兹尔轿车（Ford Edsel）配不上该公司产品发布前持续的大肆宣传，名字听起来像“蝴蝶脆饼”（pretzel），看上去却太奇怪了。
产品没准备好，就不要急于发布
当你想到产品质量，不要只想到你的开发团队制造出的产品，还要跨越鸿沟考虑整个产品，意味着还要联想到客户服务、合作方和分销渠道。否则，倘若整个产品体验中哪怕有一个环节失败了，也会毁掉一个完美的产品发布——这就是为什么想要做好太验证了。
苹果地图是苹果公司罕见的发布失败的产品。尽管苹果与谷歌起初关系很好——时任谷歌首席执行官的埃里克·施密特曾经一度出任苹果董事会成员——但谷歌发布了安卓系统之后，苹果与谷歌的关系变得紧张起来。史蒂夫·乔布斯非常生气，指责谷歌窃取了苹果的想法，并称要“干掉安卓”。症结在于谷歌地图逐渐转向安卓平台，而不在苹果系统的iOS上运行，并且谷歌不愿意放弃安卓的关键优势。所以在2012年9月iOS 6发布的时候，苹果从应用程序商店里移除了谷歌地图，取布代之的是苹果自己的软件。然而，很快人们就明白了，苹果地图尚未准备成熟就匆匆上市了。苹果地图引人注目的失败是产品质量不达标，与苹果公司一贯的对细节的关注不符。比如像金门大桥这样的地标位置标错了数英里，而布鲁克林大桥看上去好像融化了，信赖苹果地图的用户被骗上了机场的跑道，开进了澳大利亚沙漠。
别错失产品发布良机
尽管在某产品准备充分之前就匆匆发布毫无益处，但磨磨蹭蹭地进入市场也会让你失败，尤其当这个市场是短期的一时潮流时更是如此。在计划进入一个新市场的时候，保持一定的紧迫感。你不一定必须争第一名，但你当然不想做最后一名。要敢于首先交付能够完全满足基本市场需求的最简产品特性，然后从反馈中吸取教训，并在正确的领域里迅速地实施迭代以获得改进。
别天真地进入你不了解的市场
微软的第一代Surface平板电脑很大天空雅虎可以说是一个市场的失败，于是该公司对下一代产品做了改进，第二代Surface产品受欢迎程度增加。对微软而言，这是在个人电脑市场被削弱的情况下建立消费品业务的重要一步，这是通过累积的努力而完成的。
然而，倘若你天真地试图进入一个离贵公司的专业领域相去甚远的市场，也可能会造成重大失误。这种尝试往往最终会使你偏离核心产品策略，在着手了解市场运作机制时耗费资源和投资，多数大企业在进入新市场时，采取收购小的专业公司的策略是有充分理由的——正如苹果通过收购推出iTunes和iPod，微软收购诺基亚：尽管比较昂贵，但这是获得利基市场专业知识的最迅速的方法。
避免有缺陷的商业案例：建立最佳情况、最糟情况和最可能情况案例
失败在于各方沟通不畅
产品管理在一家公司里的作用如此重要，原因之一就是如果没有产品管理，就没有人既理解每个部门各自的挑战和需求，又负责积极主动地与所有人分享相关信息。人们很少愿意承认他们对某事并不了解，这就是为什么开发好的软件对许多业务主管而言往往是一个神秘的过程。当公司的左膀对右臂正在做什么一无所知——而且毫无兴趣搞清楚的时候，这种内部沟通不佳的状况就会导致产品失败。因此你必须频繁地与计划、创造和交付你的产品所涉及的所有不同部门进行沟通。这可能是这份工作真正的困难之一，因为团队中有些人也许并不乐意告诉你他们遇到的难题，而其他人可能讨厌你问这个问题。
学会从成功中取经
看一下iPhone多年来的表现，很明显可以看到苹果公司也越来越擅长产品更新：
苹果公司让产品发布看起来很简单，然而在实际操作中，一个成功的产品发布组织起来可能难度很大。我发现通过列出每个内部部门、用户和合作方需要知道的信息和时间的清单，能够提高你成功的概率。这可不会是个短的清单。自然地，这些内容是针对你公司的，因此要与团队合作创建你所需要的清单。保持手上有一份发布清单，随着发布日期的临近，最少每周回顾一次进展。然后，在发布之前，评估一下你的公司、用户、合作方以及目标市场对即将到来的发布准备的情况如何，检验一下他们是否消化了你发出的信息。你也可以跟分销商或者销售团队核实一下已经有了多少预定。在产品发布之后，你所收集到的数据能让你分析销售率、现有用户升级产品的比例，以及不同的市场渠道的效益如何，这样下一次你就能复制成功经验并提高绩效。
敏捷开发
传统的产品开发采取“闭门造车”的方式，几乎无法查看项目的进展，典型地只能牺牲质量，因为时间（即金钱）和需求范围不可更改。整个过程中开发团队背负的压力之大可想而知，他们往往面临尴尬的选择：要么未能达到高层管理人员设定的标准，要么交付一个不合格的产品。相比之下，灵活的开发方式能让相关方对项目进展有更细致和透明的观察，也给了开发团队一定的灵活度，既能赶上截止时间，同时又能保证质量，只要产品负责人有权就需求范围做出最好的判断。这样一来，赶上最后期限的压力就落在了产品经理的肩上，但产品经理有权管理团队的工作，从而及时地交付产品。“为发布准备得足够好”并不意味着“制造出所有的东西，包括厨房的水槽在内”。
关于敏捷的产品开发风格最普遍的一个是敏捷开发（Scrum），其创造者肯·施瓦伯（Ken Schwaber）和杰夫·萨瑟兰（Jeff Sutherland）在《敏捷指南》（The Scrum Guide）一书中对其有简洁的解释。产品经理兼敏捷教练罗曼·皮希勒（Roman Pichler）在他的博客里描述了传统（“老派”）与敏捷（“新派”）方式产品管理的不同之处：
在敏捷开发中，产品的开发由好几个冲刺阶段组成。冲刺阶段是一个有时间限制的开发周期，通常一个月或者更短时间，然而时间的长短总是一样的，在这个周期中，一个潜在的可以发布的产品增量被创造出来。产品负责人是敏捷开发的一个特定角色，通常由产品经理担任，全权负责决定哪些项目进入冲刺任务清单，这个清单包含了产品开发工作划分而成的一个个很小而具体且彼此分离的任务。对于任务清单上的每一项，产品负责人和开发团队都要一起在用户故事中描述预期用户角色需要与产品进行互动的方式和原因。他们也将一同评估每个用户故事的故事点的相对复杂程度。有意将待办任务安排成小块的工作是因为比起大块的工作（一部史诗——这么称呼是因为这个用户故事非常庞大），小块的工作更容易评估和完成。产品负责人将优先级最高的任务列在任务清单最上面，从而确保团队首先处理这些任务。敏捷开发为开发团队建立了一个惯例，即令冲刺任务可以预测，并让开发人员集中注意力做他们最擅长的工作——开发产品。正如你现在满怀希望地注意到，一个产品经理有各种各样的职责，成为产品负责人仅是其中之一，所以需要好的时间管理，以避免产品负责人的角色占据了你所有的注意力。
一旦你的开发团队适应了这个惯例（或者节奏），你就可以衡量每个冲刺阶段的速度，这个方法可以预测一个产品什么时候能准备妥当。速度就是衡量给定时间里团队能完成清单上的多少个任务，可以按任务完成的故事点的总数来衡量。你也许会像我那样发现，越频繁地发布产品更新，可能意味着越发没有人（无论是你的公司还是用户）注意到它的到来。因此时不时地掀起更大的波澜（正式的发布）让市场注意到你所做的改进不失为一个好办法，即便产品已经被发布了也无所谓，尤其是如果在这一系列的改进背后有一个连贯的故事或者主题就更好了。如果你了解到团队通常在一个为期两周的冲刺阶段能完成约20个故事点的工作，而在重大的产品发布前仍需完成约60个故事点的工作，那么你就知道，不出意外的话，产品大约在六周之后就能发布。这个方法基于的假设是你不会每次都变更产品团队成员，并且他们比较擅长估算故事点数量（经过几个冲刺阶段后他们理应掌握这一点）。
牢记这几点很重要。不同冲刺阶段的速度有差别是很正常的，所以把它当作一个经验法则就行了，可别当成是精确地预测产品交付时间的方法。此外，敏捷流程倾向于关注提供短期活动的详细内容（现冲刺阶段，最多到下个冲刺阶段），所以做不到对遥远任务的详细估算。这一方法有时候也称为水平线规划。从长远来看它节省了你的时间，因为随着你通过一次次的增量发布对产品和市场的了解增多，你的计划也在不断地改进，因此没有必要把计划做得很长远很细致。
产品路线图计划能防止糟糕的表现
你的整体产品策略是许多不同活动的组合，这些活动有短期、中期和长期的关注点，比如根据正在进行的市场调查决定未来产品需求，或者根据市场和竞争对手活动的变化来审查定价策略。你可以放大每一个活动，找到更多的细节——关于特性要求，你可以考虑适用的用户角色，把史诗分成更小的用户故事，与一些用户突击检查你的假设，并在开发产品之前迅速地做出一个产品模型。
如果变更路线，请告知相关人员。
本章需要记住的要点——成功与失败之间的微妙界线
1. 失败总有可能会发生：倘若整个产品体验中哪怕有一个环节失败了，也会毁掉一个完美的产品发布。在你准备妥当的时候再发布。
2. 不要跨出贵公司的核心技术太远。获取你所缺乏的专业技能。
3. 对你的商业案例的最好、最糟和最可能的结果采取现实的态度，注意利润空间不足这样的红色警报。
4. 有效的沟通，不论在内部还是外部，对于协调产品发布，确保正确的信息传达给合适的人而言至关重要。
5. 预先准备和计划可以防止产品表现不佳。
6. 模拟失败，学习如何从失败中恢复，或者如何避免失败。
7. 一直都要学习，无论是从成功还是失败中学习。
——The end.
