好的产品团队 VS 差的产品团队

昨晚开始看《用户故事地图》这本书，本文摘抄自其中的Marty Cagan序。因为写的很好，摘抄一遍，用来加强记忆。

当然，好的东西，必须拿出来分享，希望对你也有启发。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

其实，不论团队如何，咱们去工作，是要抱着为自己干活的意念做事。所以，一定要用高标准要求自己，做一股清流，必逆流而上