最近，在思考“PM 把事情想好，然后告诉工程师怎么做”这种做法好不好，讨论了许多，但还是觉得很困扰。想到了这篇文章, Good Product Team, Bad Product Team （也是本书的前言），觉得很棒，摘译如下。原文也见于 http://svpg.com/good-product-team-bad-product-team/
至于本书，我觉得大方法论（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.
Good teams have a compelling product vision that they pursue with a missionary-like passion. Bad teams are mercenaries.
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.
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.
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.
其中一个常见的误解，就是觉得自己是Steve Jobs —— 想到了一个伟大的idea, 然后其他人听就行了。
真是不能在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.
 见于Creativity, Inc. 最后一节, The Steve We Knew.