原文摘自：https://svpg.com/product-success/
Exactly a year ago I was invited to give a keynote at the Craft Conference in Budapest and I discussed the 10 biggest reasons why product teams fail. You can read the narrative article here.
恰好在一年前，我受邀参加布达佩斯的Craft会议，并发表了主题演讲，主要讨论了产品团队失败的10个最大原因。你可以点击“here”查看叙述稿。
As I mainly shined a light on why so many teams are operating so ineffectively, and despite claims to the contrary, most product organizations are hardly “agile” in any meaningful sense of the term, as the organization overall is still operating in a very waterfall fashion, the conference organizers invited me back again this year to give the sequel, to discuss more about how the best teams I know work.
我主要阐述为什么许多团队运营效率如此低下，尽管他们声称敏捷很重要，但是大多数产品团队在任何意义上都没有“敏捷”，整个团队仍然是瀑布式的方式，会议主办方今年再次邀请我作拓展的演讲，讨论关于我所知道的优秀团队是如何工作的。
Last week I delivered that talk, and this article is a narrative version.
上周，我发表了相关的演讲，本文是演讲的叙述版。
After the first talk quite a large number of people contacted me and asked for more information about the alternative. Other than recommend to people that they read my book or attend a 2 day workshop, I didn’t feel like I was able to give a very satisfying answer. So it inspired me to think hard about the most important characteristics of very strong product teams, and I forced myself to pick what I consider the ten most important.
在第一次演讲之后，许多朋友联系我，并问我替代方案的更多信息。除了向他们推荐阅读我的书或参见2天的研讨之外，我觉得我自己无法给出令人满意的答案。因此，这也驱使我不断思考关于优秀产品团队的重要特征，同时我也强迫自己梳理我认为的最重要的10条特征。
CONTINUOUS DISCOVERY AND DELIVERY
持续的探索和交付
Just as I described the ten biggest problems in the context of the Waterfall model, I described the ten attributes of successful teams in the context of the Continuous Discovery and Delivery model (also known as Dual Track Agile, or Discovery Sprints and Delivery Sprints).
正如我在的瀑布模式一文中的给出了10个最大问题一样，我在持续探索和交付一文中给出了成功团队的10个最大属性（被称为双轨敏捷，或者发现sprints和交付sprints）。
KEYS TO SUCCESS
成功秘诀
1. Empowered Product Teams
1.强大的产品团队
The most important characteristic of all is the absolutely fundamental concept of a strong product team. But what does that really mean?
所有最重要的特征都是优秀产品团队最基本的概念。但是这到底是什么意思呢？
First, it’s essential that the team is durable; the members are not meant to be moved around like chess pieces. If they want to actually innovate, they need the time to get to know each other, their technology, their customers, and the business context.
首先，这个团队必须持久；团队成员不能像象棋棋子那样随意调动。如果他们确实想创新，他们需要时间去相互了解彼此，他们的技术，他们的客户和他们的业务环境。
Second, the chemistry of the members of the team is key. This means that the know and respect each other enough that every member of the team feels comfortable contributing and raising suggestions, and challenging themselves and each other to do better.
第二，团队成员的组成也很重要。主要是指团队成员之间能足够的互相尊重，这使得每个成员都乐意提出自己的意见和建议，并不断挑战自己和彼此来做的更好。
Third, this means that teams have the necessary skill-set diversity, which is typically product management, user experience design, and engineering. In many cases we would add to this list data analysis and user research.
第三，团队需要有多样性必备的技能组合，主要是产品管理，用户体验设计和工程设计。在很多情况下我们会加入数据分析和用户研究。
Finally, despite being a sensitive topic for many companies, it is hard to argue with the advantages of a co-located team. Co-location means that the product manager, product designer, and the engineers (or at least the tech lead) all sit right next to each other. We can’t always achieve co-location for all of our teams, but we try. And just to be clear, having teams in multiple locations is not the issue, it’s when a single team is split up that causes the negative impact to both velocity and especially innovation.
最后，尽管对很多公司来说这是一个敏感的话题，很难去争论一个本地团队的优势。本地团队是指产品经理，产品设计师和工程师（或者至少是技术负责人）都集中在一起协作。我们并非总能在所有的团队中实现集中办公，但是我们需要尽最大努力。需要明确的是在多地拥有团队并不是问题，然而当把一个团队分开就会引起效率和创新的负面影响。
2. Product Vision and Strategy
2.产品愿景和策略
In order for a product team to actually be empowered and act with a meaningful degree of autonomy, the team must have a deep understanding of the broader business context. This starts with a clear and compelling product vision, and a path to achieving that vision, which is referred to as the product strategy.
为了能够使一个产品团队为了某种意义自主的工作，这个团队需要对广泛的业务场景有着深入的了解。这始于一个清晰且引人注目的产品愿景，通往这个愿景的途径就是产品策略。
The product vision describes the world we are trying to create, typically somewhere between 2 and 5 years out (longer for hardware efforts).
产品愿景描述的是我们需要创造的世界，通常在2到5年（对于硬件需要更长的时间）。
The product vision must be inspiring. When done well, it is one of our most effective recruiting tools, and motivates people to come to work every day. Strong technology people are drawn to an inspiring vision. They want to work on something meaningful.
产品愿景必须鼓舞人心。当做的很好时，这是一个最有效的招聘工具之一，并且激励人们每天为之奋斗。技术牛人被鼓舞人心的愿景吸引。他们想为一些有意义的事情工作。
The product strategy is our sequence of products we plan to deliver on the path to realizing the vision. It would be a very poor strategy to try to please everyone with a single product release. Instead, we have a prioritized list of markets, geographies, or personas and we focus on achieving product/market fit for each of these markets.
产品策略是指实现产品愿景的道路上的交付的一些列的产品序列。试图用一个产品发布来取悦每一个人是一个很糟糕的策略。因为，我们有一个市场优先级、位置或角色的列表，并且我们专注实现适合这些市场的产品。
The more product teams you have, the more essential is to have this unifying vision and strategy in order for each team to be able to make good choices.
你拥有越多的产品团队，你就更加需要一个统一的愿景和策略，让每个团队都能力作出好的选择。
Most importantly, the product vision should be inspiring, and the product strategy should be very intentional.
最重要的，产品愿景应该鼓舞人心，产品策略应该精心策划。
3. Focus on Business Outcomes
3.关注业务成果
The second part of the business context that an empowered, autonomous team needs in order to be able to make good decisions is the set of prioritized business objectives. The OKR (Objectives and Key Results) system is intended to facilitate precisely this.
业务环境的第二部分是商业目标的优先级设置，一只优秀自主的团队可以做出好的决定。OKR(目标和结果)系统将会帮助实现这以目标。
The OKR’s reflect the list of specific business problems that the team is being asked to solve. These are not features. Features are only potential solutions to problems. Launching a feature is not success for a team; solving the actual business problem is.
OKR反应了要求团队解决的一系列的商业问题。这些不是功能。功能是表示这些问题的一些潜在解决办法。对于一个团队来说，启动功能不算成功，解决问题才是。
The two principles that are behind these performance management techniques are: first, teams will perform better if you give them the problems you need them to solve, rather than give them the solutions; and second, the team is measured by results, not output. Shipping features on a roadmap is output, solving business problems are results.
这种绩效管理技术背后的主要两个原则：1，告诉团队你需要他们解决的问题比告诉他们解决办法更好；2，以结果为导向，而非以输出为导向。完成roadmap的功能是输出，解决业务问题是结果。
4. Competent Product Manager
主管产品经理
Sadly many engineers have never had the opportunity to work with a capable product manager. The ones that have are the ones insisting that they always have such a person on their team. Even worse, many engineers don’t even know what the product manager is supposed to be contributing to the team.
很遗憾的是很多工程师都没有机会和有能力的产品经理一起工作。有些人总是坚持认为他们团队中会有这样的人。更糟糕的是很多工程师甚至不知道产品经理应该为团队作出什么贡献。
Think of it this way. In order for a product team to solve hard business problems, it’s not enough that the solution just work technically, and it’s also not enough that the customer loves it, but also, and often most difficult, the solution must actually work for your business.
可以这么说。为了能让产品团队解决一个棘手的商业问题，凭技术方案是不够的，仅凭客户喜欢也是不够的，往往最困难的是解决方案必须真正围绕你的业务。
Think about what this means. Imagine you are working for Uber or AirBnB and you have to navigate complex laws and unions and trade groups. Or eBay which had to navigate significant constraints to be classified as a marketplace rather than an e-commerce site. Or Tesla which had to navigate liability issues with Autopilot. Every company has a list of these types of constraints.
思考一下这是什么意思。想象一下你正在为Uber或者Airbnb工作，你必须在复杂的法律，工会团体和贸易团体之间找到一个正确的方法。或者ebay，不得不克服重大的限制才能作为一个商场，而不是电子商务站点。或者是Tesla，不得不解决自动驾驶的责任问题。每个公司都有这种类型的限制列表。
There are legal constraints, financial constraints, sales and pricing constraints, brand and marketing constraints, privacy constraints, security constraints, partnership conditions, and the list goes on.
存在法律约束，财务约束，销售和定价约束，品牌和营销约束，隐私约束，安全约束，合作伙伴条件，并且这个约束列表还在不断的演进。
Unfortunately, in many cases the only person that has done the work to understand all of them is the CEO, and if that’s the case, you can imagine why he or she might not feel comfortable truly empowering the team to make decisions.
不幸的是，在很多情况下，了解所有完成这一工作的人就只有CEO，如果是这样，你可以想象为什么他或她真正赋予团队决策时会不太放心。
There are really three options to how teams work. One is that the CEO or some other exec decides everything. The second is that the weak product manager schedules a big meeting and invites all the executives into a room and they argue it out – this is called design by committee – which consistently produces weak results. The third is that the product manager does her job and learns these constraints, and brings them to the team so that the team can figure out the best way to solve the problem.
有三种关于团队工作的方式的选择。一种是CEO或者其他执行者决定一切。第二种是弱势的产品经理安排大型会议，并邀请所有的执行者到会议室，然后通过辩论获得结果，这种方式一般称为“委员会设计”，一般会产生微弱的结果。第三种是产品经理完成工作并了解这些限制，并把这些带到团队中，以便团队给以找出解决问题的最好办法。
Combine this with strong understanding of technology, and deep knowledge of the users and customers, and hopefully you can see why this is a tough job. But also one that’s absolutely key to a strong product team especially if the team wants to have any meaningful degree of autonomy.
将这些与深入的技术洞察，对用户深入的研究相结合，希望你能明白为什么这是一项艰巨的任务。但是对于一个强大的团队尤其是希望有一定意义的自治的团队来说，绝对是关键的。
5. Collaboration-driven Solutions
5.协作驱动的解决方案
I am not saying “collaboration” here as a buzzword. What I mean by this is that rather than a product manager handing down “requirements,” and a designer making things pretty, and engineers just there to code what they are told to, instead, the three skills – product, design and engineering – truly collaborate to solve the problems. This is because with good solutions, the technology drives the functionality as much as the functionality driving technology. The technology enables design options as much as design drives technology selection. And design direction drives functionality as much as the other way around.
这里所说的“合作”不是我们常说的合作。合作不仅仅是指产品经理处理需求，然后设计者将其设计漂亮，工程师在这里仅仅就是按照他们所说的进行编码，合作需要三个技能（产品/设计/编码）真正的协作解决问题。这是因为一个好的解决方案，技术可以像功能驱动技术一样驱动功能。技术提供了与设计驱动技术选择一样多的设计选项。设计方案和其他方法一样，也可以驱动功能。
The point is that the technology, the user experience design, and the functionality, are all completely intertwined. We come up with good solutions with a constant back and forth, give and take, between the three.
关键是技术，用户体验，设计是完全交织在一起的。一个好的解决方案需要在技术、用户体验、和设计之前不断往复和尝试。
The need for these collaboration-driven solutions is the single biggest reason why co-located teams consistently out-perform distributed teams.
对这些协作驱动型解决方案的需求，这就是位于本地团队始终胜过异地团队的最大原因。
6. Product Discovery: Learn Fast
6.产品探索：快速学习
Much of great product boils down to the ability for the team to try out lots of ideas quickly. We want to quickly separate the good ideas from the bad. Product discovery is a broad set of techniques intended to help us learn quickly which ideas will fly and which are not so great. Some ideas are big and some are small. Some are risky and some are expensive. Sometimes we need proof, and sometimes we just need evidence.
很多伟大的产品归结为团队能够快速尝试很多想法的能力。我们想要快速区分一些坏的想法。产品探索是一系列广泛技术，主要是为了帮助我们了解哪些想法可以快速实现，哪些不行；哪些想法很大，哪些想法很小；哪些有风险，哪些代价太大。有时我们需要证明，有时我们仅需要证据。
Lots of people describe this is different ways. Some like to describe this as “fake it before you make it” and some like to emphasize the “build things that don’t scale” point. The key is we need to learn fast and minimize waste.
很多人描述这是不同的方式。有些喜欢描述称为“你制作之前假装可以”，有些了人强调“非规模的构建”。这里的关键是我们需要快速学习并最大程度上减少浪费。
Using the engineering team to build and release actual products in order to try out an idea is considered the slowest, most expensive way to learn.
利用研发团队去构造和发布实际的产品，以此来验证一个想法，这被认为是最慢最贵的方式。
7. Focus on Key Risks
聚焦关键风险
There’s a couple important points to emphasize about product discovery.
关于产品的探索，有几点需要强调。
The first is that we need to focus on the four key risks: value risk – would anyone buy this or choose to use it?; usability risk – would they be able to figure out how to use it?; feasibility risk – can our engineers build this with the technology available, the time available, and the skill-sets available on the team?; and stakeholder risk – are the different parts of the company ok with this proposed solution?
第一，我们需要聚焦4个关键风险：价值风险，是否有人愿意选择或者购买？可用性风险，他们是否能够知道如何使用？可行性风险，工程师是否可以在现有技术，时间和技能下实现产品？利益相关者的风险，提议的解决方案对公司的不同部门是有可行？
In product discovery we are looking for good answers to these four questions. If so, we have the evidence and confidence we need to have the engineering team spend the time to build and deliver a product quality and scale solution.
在产品探索中，我们不断探寻四个问题的答案。这样，我们就有证据和信息，我们需要研发团队花时间来研发和交付产品质量和规模解决方案。
8. The Role of an MVP
8.MVP角色
The concept of an MVP is one of the most important concepts in product yet it’s also one of the most abused and misunderstood concepts.
MVP（最简化可实行产品）的概念是产品中最重要的概念，同时也是最容易乱用和混淆的概念。
It’s always dangerous to generalize, but I’m going to go out on a limb here and argue that an MVP should never be a product. In every single case I have ever encountered, when the team spent the time and the money to build an actual QA’d product as their MVP, I have always been able to show them afterwards how they could have accomplished the same learning at much less cost and waste.
一概而论一般是很危险的，但是我将给出一些经验性的规则，并争论MVP不应该是一个产品。在我遇到的每一案例中，当一个团队花时间和金钱来构建一个实际的产品质量检查作为他们的MVP，我总能在事后告诉他们如何在更少的代价下完成相同的学习。
So an MVP is an experiment; a test. It’s usually one of the forms of prototype. Often that’s a user prototype, sometimes it’s a live-data prototype, sometimes a feasibility prototype. And sometimes they’re hybrids. In every case, it’s a fraction of actually building out a real product.
因此MVP是一项实验，一个测试。一般是某种形式的原型。通常是用户原型，有时是实时数据的原型，有时是可行性原型。有时是是综合的原型。在每个案例中，他是真是构建产品的一部分。
9. Product Delivery: Release with Confidence
9.产品交付：放心发布
My point here is not to tell developers how to build and release software. Actually quite the contrary. One of the issues that comes from the prior issue where teams use the engineering team to create these MVP’s, is that the engineering team is often pressured to release software that they know is not really something that should be released. It’s not something they feel comfortable standing behind. There might be major reliability issues, or scale issues, or performance problems. But the product manager keeps saying “it’s just an MVP, so relax!”
我的意思不是告诉开发者如何构建和发布软件。实际恰恰相反。从前面的问题发现其中问题之一就是团队使用研发团队来创建一些MVP的产品，这使得研发团队经常被迫发布一些他们知道其实不应该真正发布的产品。他们在后面会觉得舒服。可能存在关键的可靠性问题，或者扩展问题，或者性能问题。但是产品经理一直强调“放轻松，这只是一个MVP”
I’m suggesting here that when it comes to software that your customers are actually depending on to run their business, you should not compromise. We have plenty of good product discovery techniques for testing MVP’s in ways that protect our customers, our revenue, our reputation and our own employees.
在此，我也建议当你的客户实际需要软件实现他们的业务时，你不应该妥协。我们拥有很多有效的产品探索技术来测试MVP的方法，这样可以保护我们的用户，收入，名声和我们的员工。
So use your best practices, and only release true products to production when you have the necessary confidence in that release.
因此使最佳的实践，只有在对发布具有真正的信心时，才将真正的产品发布到生产中。
10. Obsess Over Customers
10.对客户的痴迷
The final point I’d like to make is a bit different. Nearly every company I meet tells me how much they love their customers. It’s usually somewhere in their company values or mission statement, but I have to tell you that it’s easy to say the words, but much harder to actually follow through.
足后一个观点我想要有一点与众不同，几乎我遇到的每个公司都告诉我他们是多么尊重他们的客户。并且经常在写在他们的公司价值或者使命中，但是我不得不告诉你，这些都是说起来容易，实现执行起来困难的多。
I can tell pretty quickly when I talk to the team. If a customer production issue comes up, how do they respond? What level of urgency is there? Does the team reach out directly to customers to understand if they need to? Do team members know customers by name? What type of relationship do they have with customers? Do they consider the customers a big pain, or do they consider them more like colleagues?
在于团队交谈时，我们很快说出，如果发现一个的产品出现问题，他们将如何应对。那里的紧急程度如何？团队是否直接与客户联系，了解客户的需求？团队是否按名称认识客户？他们有客户之间的关系是什么样的？他们是否考虑客户的痛点，还是认为他们更像同事？
The best way to instill this true empathy for and commitment to customers is to connect the team, including and especially the developers, directly to customers.
灌输对客户真正的同情和承诺的最好方法是使团队（包括开发人员）直接与客户联系。
I hope this gives you a better sense of what makes great product teams great.
我希望这能使您更好地了解如何使优秀的产品团队变得更好。