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

我们往往说要加入一个好的团队，但是好的团队是什么样的呢？ 有一本书中的序给出来答案，可以作为一个参考

《用户故事地图》一书中

Marty Cagan序  

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

书地址：http://www.tup.tsinghua.edu.cn/booksCenter/preface.html?id=06102901

 

好的团队，有引人入胜的产品愿景，怀着传教士般的热忱在工作。

差的团队，像是由雇佣兵组成的，当一天和尚撞一天钟，靠混的。

 

好的团队，从关键业务指标得到启发，通过观察用户的痛点和分析用户使用过程中产生的数据，不断尝试新技术解决现实问题。

差的团队，从销售人员和用户那里收集需求。

 

好的团队，理解谁是主要干系人，干系人所受的约束，承诺引入解决方案，方案对用户和客户有用，同时也满足业务上的约束条件。

差的团队，只知道从干系人那里收集需求。

 

好的团队，掌握大量的技术手段，这些技术手段可以快速验证哪些产品创意是值得开发的。

差的团队，召集会议来制定路标和排列优先级。

 

好的团队，喜欢和公司内有想法的主管展开头脑风暴和讨论产品。

差的团队，在团队之外的人胆敢提议他们做任何事的时候，会觉得自己受到了冒犯。

 

好的团队，产品经理、交互设计师和开发工程师坐在一起，对功能、用户体验、技术可行性达成一致见解。

差的团队，各自坐在小格子间里，没有文档和会议安排，就不会主动响应其他人的请求。

 

好的团队，持续尝试新想法以求创新，过程中会注意保护公司利益和品牌。

差的团队，仍然坐着等待开始尝试的指令。

 

好的团队，对于创造出成功产品所需的技能很有信心，比如强大的交互设计能力。

差的团队，甚至压根儿就不知道交互设计为何物。

 

好的团队，保证开发工程师每天有时间参与产品原型的讨论，为做好产品献计献策。

差的团队，在迭代计划会上展示原型，一心只为了估出工作量。

 

好的团队，每周直接和用户交流，以更好地理解用户诉求，并试探用户对最新的产品创意的反馈。

差的团队，以为他们自己就能代表用户。

 

好的团队，清楚地知道尽管他们很喜欢自己在产品上的创意，但这些创意中的很大一部分用户并不见得会接受，即使有一些被用户接受了，也需要经过多个迭代的打磨才能达到预期的效果。

差的团队，只开发路标上规划的内容，能按时交付，只求不出重大质量问题就阿弥陀佛。

 

好的团队，理解速度和快速迭代对于产品创新的价值，更知道速度来自于正确的方法，而非强制加班。

差的团队，抱怨同事工作不够努力，速度太慢。

 

好的团队，在评估方案，确认可行并对用户和业务有实际价值后，共同做出承诺。

差的团队，抱怨自己公司是一个受销售驱动的公司。

 

好的团队，使用工具，以便快速了解用户是如何使用产品的，并基于数据做出判断。

差的团队，认为统计分析是可有可无的。

 

好的团队，持续集成和发布产品，因为他们知道持续的小发布能为用户提供了稳定可靠的解决方案。

差的团队，在经过痛苦的集成联调之后，手工测试，一次性发布所有功能。

 

好的团队，专注于用户。

差的团队，专注于竞品。

 

好的团队，在关键业务目标重大影响达成后庆祝。

差的团队，在终于发布产品之后庆祝。