[译] Good Product Team, Bad Product Team

最近读到了这篇文章, Good Product Team, Bad Product Team，觉得很棒，也就做了翻译，分享给大家 —— 由cqcn1991分享

最近，在思考“PM 把事情想好，然后告诉工程师怎么做”这种做法好不好，讨论了许多，但还是觉得很困扰。想到了这篇文章, Good Product Team, Bad Product Team（也是本书的前言），觉得很棒，摘译如下。原文也见于 [1] 至于本书，我觉得大方法论（Build a shared understanding）很棒，但是细的方法（Use story mapping）适用性较窄，只适合一般的信息管理产品

What I’ve learned is that there is a profound difference between how the very best product companies create technology products, and the rest. And I don’t mean minor differences. Everything from how the leaders behave, to the level of empowerment of teams, to how the organization thinks about funding, staffing and producing products, down to how product, design and engineering collaborate to discover effective solutions for their customers. 我所知道的是，业内的顶尖团队和一般团队有着巨大的差别。并不是小的差别，而是很大的差别。从领导如何作为，到团队所拥有的权力，到公司如何看待funding、团队组建和产品开发，一直到产品、设计师、工程师之间如何协作来创造有效的产品，都有着很大的差别。 Good teams have a compelling product vision that they pursue with a missionary-like passion. Bad teams are mercenaries. 好的团队有强烈的产品vision, 并且努力去追随这个vision；差的团队为钱而来。 Good teams get their inspiration and product ideas from their scorecard KPI’s, from observing customers struggle, from analyzing the data customers generate from using their product, and from constantly seeking to apply new technology to solve real problems. Bad teams gather requirements from sales and customers. 好的团队从KPI, 观察用户痛点，分析产品使用数据中得到灵感和产品 idea，并不断尝试用新技术解决问题；差的团队从销售和用户处收集需求。 Good teams understand who each of their key stakeholders are, they understand the constraints that these stakeholders operate in, and they are committed to inventing solutions that work not just for users and customers, but also work within the constraints of the business. Bad teams gather requirements from stakeholders. 好的团队知道影响他们的关键决策人物是谁，而且知道他们所受的限制，所以努力做出不仅让用户满意也满足商业要求的产品；差的团队从这些关键人物处收集需求。 Good teams are skilled in the many techniques to rapidly try out product ideas to determine which ones are truly worth building.Bad teams hold meetings to generate prioritized roadmaps. 好的团队有各种各样的方法来快速尝试不同的idea，来决定哪个真正值得做；差的团队靠开会来决定先做什么再做什么。 Good teams love to have brainstorming discussions with smart thought-leaders from across the company.Bad teams get offended when someone outside their team dares to suggest they do something. 好的团队喜欢和公司里各种优秀的人讨论自己的产品，差的团队讨厌别人对他们“指手画脚”。 Good teams have product, design and engineering sit side-by-side, and embrace the give and take between the functionality, the user experience and the enabling technology.Bad teams sit in their respective functional areas, and ask that others make requests for their services in the form of documents and scheduling meetings. 好的团队产品、设计师、工程师坐在一起，并且理解功能、用户体验和技术之间必需的妥协；差的团队各自坐在自己部门的办公室里，等着别人把文档发过来、开会来请自己工作。 Good teams are constantly trying out new ideas in order to innovate, but doing so in ways that protect the revenue and protect the brand. Bad teams are still waiting for permission to run a test. 好的团队不断尝试新的想法来创新，但也会注意保证公司收益和品牌不受影响；差的团队还在等着老板允许他们做某个测试。 Good teams insist they have the skill sets on their team necessary to create winning products, such as strong interaction design.Bad teams don’t even know what interaction designers are. 好的团队确保他们有足够的技能做出优秀的产品，比如交互设计；差的团队根本不知道什么叫交互设计。 Good teams ensure that their engineers have time to try out the discovery prototypes every day so that they can contribute their thoughts on how to make the product better.Bad teams show the prototypes to the engineers during sprint planning so they can estimate. 好的团队确保工程师有时间尝试各种原型，这样他们也能为产品贡献想法；差的团队把原型拿给工程师，好让他们估计需要完成的时间 Good teams engage directly with end-users and customers every week, to better understand their customers, and to see the customer’s response to their latest ideas.Bad teams think they are the customer. 好的团队直接和用户交流，来更好地理解他们，并且看看他们对一些新idea的反应；差的团队认为他们自己就是用户。 Good teams know that many of their favorite ideas won't end up working for customers, and even the ones that could will need several iterations to get to the point where they provide the desired outcome.Bad teams just build what’s on the roadmap and are satisfied with meeting dates and ensuring quality. 好的团队知道很多他们觉得好的想法，都不一定最终会对用户有用，即便真正有用的想法也要不断迭代才能真正有效果；差的团队只按预先的规划做开发，在规定日期完成，达到稳定性要求就满意了。 Good teams understand the need for speed and how rapid iteration is the key to innovation, and they understand this speed comes from the right techniques and not forced labor. Bad teams complain they are slow because their colleagues are not working hard enough. 好的团队知道速度和快速迭代是创新的关键，而且理解速度来自于正确的工作方法而不是强制性工作；差的团队抱怨他们速度慢是因为同事不够努力。 Good teams make high-integrity commitments after they've evaluated the request and ensured they have a viable solution that will actually work for the customer and the business. Bad teams complain about being a sales-driven company. 好的团队在评估了需求并且确保方案真正对客户真正有益后，会做出认真的承诺；差的团队会抱怨他们是一个销售导向的公司。 Good teams instrument their work so that they can immediately understand how their product is being used and make adjustments based on the data. Bad teams consider analytics and reporting a “nice to have.” 好的团队在产品里做好数据埋点，以便快速了解产品的使用情况，并且可以基于数据做调整；差的团队认为数据分析"有就行了"。 Good teams integrate and release continuously, knowing that a constant stream of smaller releases provides a much more stable solution for their customers.Bad teams test manually at the end of a painful integration phase and then release everything at once. 好的团队不断地发布功能，知道不断的小的更新是稳定产品的基石；差的团队在每次升级之后人工测试，然后把更新的内容全部发布。 Good teams obsess over their reference customers. Bad teams obsess over competitors. 好的团队关注为他们传播口碑的用户；差的团队关注他们的竞争对手。 Good teams celebrate when they achieve a significant impact to the business KPI’s.Bad teams celebrate when they finally release something. 好的团队在达成重要的KPI的时候进行庆祝, 差的团队在终于发布了点东西的时候进行庆祝。

我再补充几点，我不喜欢的是 (1) PM自以为是，觉得自己东西都想好，工程师做就行了 (2) 工程师不合作，不愿意参与到产品的讨论中，只喜欢遵守文档开发 (3) 团队不愿意做实验 其中一个常见的误解，就是觉得自己是Steve Jobs —— 想到了一个伟大的idea, 然后其他人听就行了。 “...嗯，而且Jobs自己就是这样一个“固执”于自己想法的人，但你看他，还不是搞成了。你们就是不懂我的NB之处啊。” 真是不能在further from the truth了....

Whenever offering a note, he always began the same way: “I’m not really a filmmaker, so you can ignore everything I say.… ” Then he would proceed, with startling efficiency, to diagnose the problem precisely. Steve focused on the problem itself, not the filmmakers, which made his critiques all the more powerful. 每次提建议的时候，他总是会这样说“我不是拍电影的，所以你们可以完全忽略我的想法...”，然后他会继续，用惊人的效率准确指出问题所在。Steve只关注问题本身，而不涉及工作人员，因此让他的意见很容易奏效。[2]

... "so you can ignore everything I say"，我不知道谁还有资格认为自己的想法是一定正确的。 最后，不知道国内有没有这样的团队，希望有机会可以加入，或者自己能建立一个这样的团队 [1] http://svpg.com/good-product-team-bad-product-team/ [2] 见于Creativity, Inc. 最后一节, The Steve We Knew.

原文链接：https://book.douban.com/review/8421504/

关键字：产品经理

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！