【人人译客】好的产品团队与不好的产品团队–区别在哪里？？？

注脚：我的同事兼朋友Jeff Patton即将出版一本关于用户故事和故事图谱的新书。我被邀请为该书写序，这篇文章是序的一部分。我同时还是该书的审稿者，这是一本产品必读书籍，它弥补了目前敏捷系列中的一些空白。如果想要预定可以去O’Reilly上预定。（ps: 博文上有，友情翻译一下）

本人运气非常好，有幸与世界上很多一流的技术团队共过事。这些人开发出了你们喜爱且每天使用的产品。说这些团队改变了世界，一点也不为过。

我也曾经被请去帮助一些表现不那么好的企业。我见过，想要在烧光钱之前找到出路的初创团队；还在折腾过时“创新”的大企业；无法继续为产品增加价值的团队；苦恼于想法何时实现的团队Leader；被产品管理者气炸了的攻城狮……

经历了这些，我发现那些创造出一流产品的好企业跟其他企业有着非常大的差别。没错，我不是说一点点差别。大到团队Leader的行为；团队激励的方式；团队对于融资、招人和产品的看法；小到产品、设计和研发应该如何协作并发现用户需求的解决方案。

谨向Ben Horowitz的“好的产品经理/不好的产品经理”致敬，对那些还没有机会加入或观察一个超强产品团队的人，我想通过这篇文章尽量阐述清楚“好的产品团队/不好的产品团队”区别在哪里。

好的团队有着坚定的产品愿景，他们带着使命感去追求那个愿景。不好的团队更像一个雇佣兵团。

好的团队从他们的KPI记录中寻找灵感、从观察用户的不爽中寻找灵感、从用户使用产品的记录数据中寻找灵感、从持续尝试挖掘新技术来解决产品问题的过程中获取灵感……不好的团队从销售团队和用户那里直接搜集需求。

好的团队了解每一位重要股东是谁，他们还清楚这些股东给他们的商业束缚是什么，他们致力于找到那些不仅对用户有用的方法，而且这些方法还能跟商业束缚相协调。不好的团队则从股东那里获取需求。

好的团队一般精通很多技术，他们能快速验证产品想法，并找到值得深耕的那一个。不好的团队老是开会商讨产品路标的优先级。

好的团队喜欢跟公司里任何部门的聪明Leader进行头脑风暴。不好的团队在听到外部人员建议时会觉得不爽。

好的团队里，产品、设计、开发总是坐得很近，他们一起在功能、用户体验和技术可行性上协商取舍。不好的团队他们自顾自，不停地要求其他人给出规范文档或者安排会议。

好的团队会不断尝试新想法并想办法创新，但他们会考虑保护产品的营收和形象。不好的团队还在等领导批准这个测试。

好的团队强调要有齐备的技能组合，这样他们才能打造优秀的产品，比如交互设计。不好的团队连交互设计师是干啥的都不知道。

好的团队每天都会给攻城狮时间去使用新版本，这样攻城狮也能为产品的打磨贡献思想。不好的团队在敏捷开发计划时把原型扔给开发团队，让他们估计成本。

好的团队每周都会与用户（使用产品的人）和客户（付钱的人）沟通，以便能更好理解他们，并获取他们对产品新功能的看法。不好的团队认为自己就是用户。

好的团队知道很多自己喜欢的想法最终对用户无用，即便有些想法已经迭代了多次并有些效果。不好的团队按路标规划开发产品，并满足于按时按质交付产品。

好的团队明白执行速度和快速迭代对于产品创新的重要性，同时也明白速度源自正确的技术而不是强制加班。不好的团队总是抱怨同伴不够努力导致进度延后。

好的团队一旦评估完需求就会高度集中地投入，并保证产出一个对用户和商业都有用的方案。不好的团队一直抱怨公司被销售驱动。

好的团队量化他们的工作和产品，这样他们就可以快速理解产品当前的使用情况并基于数据快速做出调整。不好的团队认为分析报告是个“利器”。

好的团队持续、谨慎地整理和发布功能，他们明白持续的小改进才能给出更好的解决方案。不好的团队在经历了一个痛苦的整合期后才来手动测试功能，然后将所有功能一次发布。

好的团队死磕相关用户。不好的团队纠缠竞争对手。

好的团队在关键KPI取得重大突破时庆祝。不好的团队发布了一点东西就沾沾自喜。

如果上面说到的你中枪很严重，我建议你考虑提高团队的标准，再看看会不会有改善。

本文由人人都是产品经理@Tobbi翻译，转载请注明来源且保留本文链接。

原文地址：http://www.svpg.com/good-product-team-bad-product-team/