好的产品经理和差的产品经理（好的团队和差的团队）

转自《用户故事地图》Marty Cagan序 http://www.tup.tsinghua.edu.cn/booksCenter/preface.html?id=06102901

原做者：Ben Horowitz（本·霍罗威茨）

原文叫<好的产品经理和差的产品经理>我的感受这篇文章叫<好的团队和差的团队>更好。

===华丽的分割线，如下是正文。=====================================================

好的团队，有引人入胜的产品愿景，怀着传教士般的热忱在工做。差的团队，像是由雇佣兵组成的，当一天和尚撞一天钟，靠混的。

好的团队，从关键业务指标获得启发，经过观察用户的痛点和分析用户使用过程当中产生的数据，不断尝试新技术解决现实问题。差的团队，从销售人员和用户那里收集需求。

好的团队，理解谁是主要干系人，干系人所受的约束，承诺引入解决方案，方案对用户和客户有用，同时也知足业务上的约束条件。差的团队，只知道从干系人那里收集需求。

好的团队，掌握大量的技术手段，这些技术手段能够快速验证哪些产品创意是值得开发的。差的团队，召集会议来制定路标和排列优先级。

好的团队，喜欢和公司内有想法的主管展开头脑风暴和讨论产品。差的团队，在团队以外的人胆敢提议他们作任何事的时候，会以为本身受到了冒犯。

好的团队，产品经理、交互设计师和开发工程师坐在一块儿，对功能、用户体验、技术可行性达成一致看法。差的团队，各自坐在小格子间里，没有文档和会议安排，就不会主动响应其余人的请求。

好的团队，持续尝试新想法以求创新，过程当中会注意保护公司利益和品牌。差的团队，仍然坐着等待开始尝试的指令。

好的团队，对于创造出成功产品所需的技能颇有信心，好比强大的交互设计能力。差的团队，甚至压根儿就不知道交互设计为什么物。

好的团队，保证开发工程师天天有时间参与产品原型的讨论，为作好产品献计献策。差的团队，在迭代计划会上展现原型，一心只为了估出工做量。

好的团队，每周直接和用户交流，以更好地理解用户诉求，并试探用户对最新的产品创意的反馈。差的团队，觉得他们本身就能表明用户。

好的团队，清楚地知道尽管他们很喜欢本身在产品上的创意，但这些创意中的很大一部分用户并不见得会接受，即便有一些被用户接受了，也须要通过多个迭代的打磨才能达到预期的效果。差的团队，只开发路标上规划的内容，能按时交付，只求不出重大质量问题就阿弥陀佛。

好的团队，理解速度和快速迭代对于产品创新的价值，更知道速度来自于正确的方法，而非强制加班。差的团队，抱怨同事工做不够努力，速度太慢。

好的团队，在评估方案，确承认行并对用户和业务有实际价值后，共同作出承诺。差的团队，抱怨本身公司是一个受销售驱动的公司。

好的团队，使用工具，以便快速了解用户是如何使用产品的，并基于数据作出判断。差的团队，认为统计分析是无关紧要的。

好的团队，持续集成和发布产品，由于他们知道持续的小发布能为用户提供了稳定可靠的解决方案。差的团队，在通过痛苦的集成联调以后，手工测试，一次性发布全部功能。

好的团队，专一于用户。差的团队，专一于竞品。

好的团队，在关键业务目标重大影响达成后庆祝。差的团队，在终于发布产品以后庆祝。