注：本文为 "产品管理思维模型" 相关合辑。
英文引文，机翻未校。
图片清晰度受引文原图所限。
如有内容异常，请看原文。
MVPM: Minimum Viable Product Manager
MVPM：最小可行产品经理
Brandon Chu
Apr 4, 2016
You've probably seen this diagram before. It elegantly shows that product management is the intersection of a diverse skill set.
你可能以前见过这个图表。它优雅地展示了产品管理是多种技能集的交汇点。
Product Management
Its simplicity has made it one of the most successful product management memes out there, and it's done good things for the discipline.
它的简洁性使其成为最成功的产品管理模因之一，并且为该学科做了好事。
Long ago, as a young PM padawan, it helped me realize that I needed to structure my learning for breadth. What it didn't tell me, however, was where to focus --- I started trying to learn everything, and in hindsight that was a mistake.
很久以前，作为一名年轻的产品管理学徒，它帮助我意识到我需要为广度构建我的学习。然而，它没有告诉我应该关注哪里------我开始尝试学习一切，事后看来那是一个错误。
There isn't enough time on this Earth to learn everything you could about those three circles, so as helpful as this diagram is, it ends up impractical.
在这个地球上没有足够的时间来学习关于这三个圆圈的一切，所以尽管这个图表很有帮助，但它最终是不切实际的。
Yea... not really helpful
是啊......不太有帮助
What would have been far more helpful was to know what actually comprises that intersection:
远更有帮助的是知道那个交汇点实际上包含什么：
What actually is this?
That intersection is what I call the Minimum Viable Product Manager (MVPM) , and it defines a set of skills or knowledge that are useful to be an effective generalist product manager, one who can work on almost any problem.
那个交汇点就是我所说的最小可行产品经理（MVPM），它定义了一组技能或知识，这些对于成为一名有效的通才产品经理是有用的，一个可以处理几乎任何问题的人。
MVPM in no way implies that you need to achieve mastery of its skills to be effective, which is both impractical and counterproductive for someone starting out. Instead, view it as a syllabus of sorts for the course in product management that doesn't exist.
MVPM 绝不意味着你需要掌握其技能才能有效，这对刚开始的人来说既不切实际又适得其反。相反，将其视为不存在的产品管理课程的一种教学大纲。
I write this for my younger self, for new product managers, and for more experienced PMs still looking to level up. To maintain some symmetry with the diagram, skills are divided into sections for each discipline. I cover three key concepts/skills to focus on, and one that you really shouldn't focus on. As much as possible, it's in plain language and is written for someone who's approaching any of the subjects cold.
我写这篇文章是为了年轻时的自己，为了新产品经理，也为了那些仍在寻求提升的更有经验的产品经理。为了与图表保持某种对称性，技能按每个学科分为几个部分。我涵盖了三个需要关注的关键概念/技能，以及一个你真正不应该关注的技能。尽可能用平实的语言编写，为那些对任何主题都陌生的人而写。
MVPM: Technology
1. The Stack
1. 技术栈
When engineers refer to 'the stack', they're talking about the layers of technologies that are used to provide functionality to your product (i.e. make the thing work). From the moment a customer loads your landing page to when they delete their account, the technologies in the stack handle everything.
当工程师提到"技术栈"时，他们指的是用于为产品提供功能的技术层（即让东西工作）。从客户加载你的着陆页的那一刻到他们删除账户的那一刻，栈中的技术处理一切。
Fastest way to learn --- Ask an engineer to take you through the stack at a high level. Write down the names of each technology. Quick Googling of those terms will teach you some of the high level benefits and trade-offs of each technology chosen, and how they work in harmony together. Stay at a high level because you can fall into the rabbit hole easily (add "trade offs + benefits + vs" to your search query)
最快的学习方式------ 请一名工程师带你高层次地了解技术栈。写下每种技术的名称。快速 Google 这些术语会教你一些关于所选每种技术的高层次好处和权衡，以及它们如何和谐地协同工作。保持在高层次，因为你很容易陷入兔子洞（在你的搜索查询中添加"trade offs + benefits + vs"）
How does this make you a better PM? --- When engineers are discussing how to build something, terminology flies around the room. Knowing the stack means you can at least follow along, and over time you'll begin to understand what depth in the stack they're referring to. Generally, the more layers in the stack they need to touch, or the deeper the layer, the more complicated and risky a change will be. Knowing this may push you to re-consider a different way to solve the problem.
这如何让你成为更好的产品经理？------ 当工程师讨论如何构建东西时，术语在房间里飞来飞去。了解技术栈意味着你至少可以跟上，随着时间的推移，你会开始理解他们在栈中指的是什么深度。一般来说，他们需要触及的栈层越多，或者层越深，变更就越复杂和风险越大。了解这一点可能会促使你重新考虑用不同的方式解决问题。
2. System Architecture
2. 系统架构
If the stack represents what technologies are being used, system architecture represents how those technologies are structured to work together to deliver the product. Whereas the stack is mostly about raw technical capability, the architecture of a product incorporates the customer's intended behaviour in its design.
如果技术栈代表正在使用什么技术，系统架构代表这些技术如何被构建以协同工作来交付产品。虽然技术栈主要是关于原始技术能力，但产品的架构在其设计中融入了客户的预期行为。
Fastest way to learn --- Ask an engineer to draw you the architecture. You'll get something like this:
最快的学习方式------ 请一名工程师为你绘制架构图。你会得到类似这样的东西：
"Why are there only two of the thing called triple store?"
"为什么叫 triple store 的东西只有两个？"
First, don't panic. Ask them to walk you through what each component (box) in the system does. Some will handle internet requests, some will house the 'business logic', others still will hold the data that is saved (cylinders).
首先，不要惊慌。请他们带你了解系统中每个组件（方框）的作用。有些会处理互联网请求，有些会容纳"业务逻辑"，还有些会保存数据（圆柱体）。
Second, believe it or not, this is very useful for you.
其次，信不信由你，这对你非常有用。
How does this make you a better PM?--- When you understand the architecture, you start to think of your product like a system, which is generally how engineers will as well. Having an understanding of how each component in the system contributes to the whole helps you make better decisions and trade offs.
这如何让你成为更好的产品经理？------ 当你理解架构时，你开始像系统一样思考你的产品，这通常也是工程师的思考方式。理解系统中每个组件如何为整体做出贡献有助于你做出更好的决策和权衡。
Generally , the components in the system that have the most connections are the most complicated to change because so many others rely on them for data or functionality. The more components you have to change in order to complete your build, the more dependencies you have, and the harder the project will be to execute.
一般来说 ，系统中连接最多的组件是最难更改的，因为许多其他组件依赖它们获取数据或功能。为了完成构建而必须更改的组件越多，你就拥有越多的依赖关系，项目就越难执行。
In larger companies, the number of components you touch is often synonymous with the number of teams/ groups you need to interact with, and the more alignment you'll need to gain to execute a project.
在更大的公司中，你触及的组件数量通常与你需要交互的团队/组数量同义，你需要获得更多的对齐来执行项目。
3. The Data Model and its APIs
3. 数据模型及其 API
A data model organizes information used by your product and standardizes how pieces of that information relate to one another. By 'information', we're really talking about things like Users, Products, and Credit Cards, which collectively are called entities. These entities can relate to each other in certain, structured ways; for example a User can have many Products, but only one Credit Card*.
数据模型组织产品使用的信息，并标准化这些信息片段如何相互关联。说到"信息"，我们实际上是在谈论像用户、产品 和信用卡 这样的东西，它们统称为实体。这些实体可以以某些结构化的方式相互关联；例如，一个用户可以拥有许多产品，但只能拥有一张信用卡*。
The data model is closely related to the system architecture in that certain entities 'live' in certain components. Your Users model may live in component A and so might the Products data, but because of its sensitivity, Credit Cards live in component B. If your feature needs to show which Users own a product in a list, that's pretty easy since they live in the same component. But if you need to know which of those users have a credit card stored, then component A needs a connection to component B in order to share the data. That's harder, and to accomplish it, they need an API (application programming interface).
数据模型与系统架构密切相关，因为某些实体"居住"在某些组件中。你的用户 模型可能居住在组件 A 中，产品 数据也可能如此，但由于其敏感性，信用卡居住在组件 B 中。如果你的功能需要在列表中显示哪些用户拥有产品，这很容易，因为它们居住在同一个组件中。但如果你需要知道这些用户中哪些存储了信用卡，那么组件 A 需要与组件 B 建立连接以共享数据。这更难，为了实现它，他们需要一个 API（应用程序编程接口）。
APIs are built on top of the data model and represent how any two components talk to each other and exchange information about their underlying models. Importantly, APIs also let you talk to external components. When you call an Uber from Google maps, the Google maps app is talking to a component from Uber. Most applications have Public APIs and Private APIs, which are usable by anyone on the internet, or just those you specify, respectively. Knowing your public APIs are critical to understanding how your product can interact with the outside world.
API 建立在数据模型之上，代表任意两个组件如何相互通信并交换关于其底层模型的信息。重要的是，API 还允许你与外部组件通信。当你从 Google 地图呼叫 Uber 时，Google 地图应用正在与 Uber 的组件通信。大多数应用程序都有公共 API 和私有 API，分别可供互联网上的任何人或仅你指定的人使用。了解你的公共 API 对于理解你的产品如何与外部世界交互至关重要。
Fastest way to learn --- You should focus first on gaining an understanding of your Public APIs. They're usually easy to find, and often live on your website's developer docs. When you see them, you'll see code and that may or may not freak you out depending on your background, but if the documentation is half-way decent, that should be irrelevant and you should be able to read it fine. The beauty of studying your APIs is that they often represent most of your underlying data model, so you get two birds with one stone.
最快的学习方式------ 你应该首先专注于了解你的公共 API。它们通常很容易找到，通常位于你网站的开发者文档中。当你看到它们时，你会看到代码，这可能会或可能不会让你感到惊慌，取决于你的背景，但如果文档还算过得去，那应该是无关紧要的，你应该能够很好地阅读它。研究 API 的美妙之处在于，它们通常代表了你大部分底层数据模型，所以你一石二鸟。
How does this make you a better PM? --- Knowing your data model expands your ability to know what information you can utilize to create better products, and how hard it may be to access that information. Knowing your APIs mean you understand what types of information partners and third party developers can get from your application, and therefore what types of integrations are possible. The extensibility of software is one of it's most valuable properties, and being able to work well with other products (that your customers are potentially using everyday) is quickly becoming table stakes.
这如何让你成为更好的产品经理？------ 了解你的数据模型扩展了你知道可以利用什么信息来创建更好产品的能力，以及访问该信息可能有多困难。了解你的 API 意味着你理解合作伙伴和第三方开发者可以从你的应用程序获取什么类型的信息，因此什么类型的集成是可能的。软件的可扩展性是其最有价值的属性之一，能够与其他产品（你的客户可能每天都在使用）良好协作正迅速成为基本要求。
4. Where you shouldn't focus
4. 你不应该关注的地方
Programming. Don't get me wrong, I love programming and it does help you be better, but unless it's a highly technical product, you just don't need it to be an effective PM. If you find yourself coding as a PM, you may need to ask yourself if you're actually doing high leverage work, or you're not sure what else you should be doing. That being said, I think it's a very worthwhile and fun experience to have built at least one app and shipped it to a production environment.
编程。别误会我，我喜欢编程，它确实能帮助你变得更好，但除非它是高度技术性的产品，否则你不需要它来成为一名有效的产品经理。如果你发现自己在编码，你可能需要问自己你是否实际上在做高杠杆工作，或者你不确定还应该做什么。话虽如此，我认为构建至少一个应用程序并将其发布到生产环境是一个非常值得且有趣的体验。
MVPM: Business
1. Project Management
1. 项目管理
Boring, I know. I hate it too, but it is really important. If you can't run a project well you're never going to be a good PM. Period.
无聊，我知道。我也讨厌它，但它真的很重要。如果你不能很好地运行一个项目，你永远不会成为一名好的产品经理。就这样。
Fastest way to learn --- This one is hard. To be an effective project manager takes a lot of experience and time. You can read up all you want, but at the end of the day it's a human behaviour problem. It takes time to learn about the spectrum of personalities you'll end up working with, and any advice you'll find on how to approach it is often subjective to your personality, too.
最快的学习方式------ 这个很难。要成为一名有效的项目经理需要大量的经验和时间。你可以尽情阅读，但最终这是一个人类行为问题。了解你最终要合作的各种性格需要时间，你找到的任何关于如何处理它的建议往往也取决于你的性格。
That being said, there are some software specific things you can invest in to accelerate your learning curve:
话虽如此，有一些软件特定的东西你可以投资以加速你的学习曲线：
-
Understand the basics of product development so that you can empathize with your team. Learn about version control (Git), collaborative programming (GitHub), Quality Assurance processes, and at a high level how and when code gets deployed to users in your product.
理解产品开发的基础知识，以便你能与团队产生共鸣。了解版本控制（Git）、协作编程（GitHub）、质量保证流程，以及高层次上代码如何以及何时部署给用户。
-
Learn about the common problems that plague software teams, and the processes others have developed to try and solve them. You'll come across things like agile, scrum and kanban. There is value in learning the philosophies behind their approaches, whether your company uses them or not.
了解困扰软件团队的常见问题，以及其他人开发出来试图解决这些问题的流程。你会遇到像敏捷、Scrum 和看板这样的东西。学习他们方法背后的哲学是有价值的，无论你的公司是否使用它们。
-
Understand decision making at your company, and map out your stakeholders. These are often your customers, your boss, your team members' bosses, and other PMs. Find a way to ensure that everyone is aware of the status and direction a project is going at a level contextual to what they care about (you'll have to find that out too).
理解你公司的决策制定，并绘制出你的利益相关者。这些通常是你的客户、你的老板、你团队成员的老板和其他产品经理。找到一种方法确保每个人都了解项目的状态和方向，达到与他们关心的内容相关的层次（你也必须找出这一点）。
How does this make you a better PM? --- You'll get more shit done with your team, and people will enjoy working with you because everyone hates a poorly managed project.
这如何让你成为更好的产品经理？------ 你会和你的团队完成更多的事情，人们会喜欢和你一起工作，因为每个人都讨厌管理不善的项目。
2. Modelling Impact
2. 影响建模
Things that aren't measured rarely get done well. Every product should have quantitative goals that are tied to it's ultimate success, basic things like user growth, feature adoption, revenue, etc.
不被衡量的事情很少能做好。每个产品都应该有与其最终成功相关的定量目标，基本的东西如用户增长、功能采用、收入等。
When your team is debating the highest leverage thing you could build next, it's important that you can develop a model of how the product will move the dial on those metrics.
当你的团队在争论你接下来可以构建的最高杠杆事物时，重要的是你能够建立一个模型，说明产品将如何推动这些指标。
Fastest way to learn --- It's time to get your spreadsheet on. A good model clearly shows two things:
最快的学习方式------ 是时候打开你的电子表格了。一个好的模型清楚地展示两件事：
The unit economics of a product and the assumptions that create them:
产品的单位经济学及其产生的假设：
- How much does it cost to acquire a new customer?
获取一个新客户的成本是多少？ - How much does it cost to serve the product?
服务产品的成本是多少？ - How much does a conversion move the needle on your goal?
一次转化能在多大程度上推动你的目标？
The forecasted impact and the assumptions that create them:
预测的影响及其产生的假设：
- How much does this product move the needle over the next year? The next three?
这个产品在未来一年能推动多少？未来三年呢？ - How many people will we need to hire to enhance and support it?
我们需要雇佣多少人来增强和支持它？ - How are market forces like cost reductions, inflation, and competition accounted for in the long term
长期如何考虑成本降低、通货膨胀和竞争等市场力量
Gotta love that fake model growth rate
必须喜欢那个虚假模型增长率
How does this make you a better PM? --- The exercise of building a model for your product is a great way to test your instinctual assumptions and ensure that your product has enough potential to make it worth doing. It makes your job easier too; by enabling you to justify projects in a way that resonates with your stakeholders, and by easily enabling you to compare the opportunity cost with other projects you could be doing.
这如何让你成为更好的产品经理？------ 为你的产品建立模型的练习是测试你本能假设的好方法，并确保你的产品有足够的潜力值得去做。它也让你的工作更容易；使你能够以与利益相关者产生共鸣的方式证明项目，并使你能够轻松地与其他你可能正在做的项目比较机会成本。
3. Gather & Analyze Data
3. 收集和分析数据
Being able to independently gather data is vital to making quick decisions. For all but the most involved analyses, relying on someone else to get data for you is not only an inefficient use of their time, but it also doesn't lead to insights, because anyone who's been an analyst before knows that insights come through iterative exploration of data, not some perfect report you dream up.
能够独立收集数据对于做出快速决策至关重要。对于除了最复杂的分析之外的所有分析，依赖别人为你获取数据不仅是低效利用他们的时间，而且也不会带来洞察，因为任何曾经是分析师的人都知道，洞察来自对数据的迭代探索，而不是你梦想中的某个完美报告。
It also reduces your ability to make data-informed decisions when they matter. Almost everyday, a decision about how a product should behave in a certain scenario will pop up, and having data to support a decision makes it easy for you and your team to feel confident in the right direction.
这也降低了你在关键时刻做出数据知情决策的能力。几乎每天，关于产品在特定场景中应该如何表现的决策会出现，拥有数据支持决策使你和你的团队很容易对正确的方向感到自信。
Fastest way to learn --- Your goal is data independence . Whether you need to write SQL queries or use a drag and drop interface depends on the data infrastructure at your company. Regardless of what it is, you need to invest in learning the tools available to you. Google them.
最快的学习方式------ 你的目标是数据独立。无论你是需要编写 SQL 查询还是使用拖放界面，取决于你公司的数据基础设施。无论它是什么，你都需要投资学习可用的工具。Google 它们。
How does this make you a better PM? --- When data is easily accessible to you and you're comfortable getting it, you will use it more and it will enable you to be more iterative. Whether you're considering what to build next, or you're seeing how your launch is doing, you will build a reflex to use data as an important input into your decision making --- and better products will result.
这如何让你成为更好的产品经理？------ 当数据对你来说容易获取并且你习惯于获取它时，你会更多地使用它，它将使你更加迭代。无论你是在考虑接下来构建什么，还是在看你的发布进展如何，你都会建立一种反射，将数据作为决策的重要输入------从而产生更好的产品。
4. Where you shouldn't focus
4. 你不应该关注的地方
Take this from someone with a business degree - don't waste your time making strategic business cases, 3 year plans, and other MBA artifacts. I won't go as far as to call it bullshit, but it's not the way to succeed in software. Understand the vision, find a problem worth solving to achieve it, build a hypothesis to solve it, and then validate it as quickly as you can with real customers. Rinse and repeat.
从一个拥有商科学位的人那里接受这个建议------不要浪费时间制作战略商业案例、3 年计划和其他 MBA 产物。我不会称之为胡说八道，但这不是在软件领域取得成功的方式。理解愿景，找到一个值得解决的问题来实现它，建立一个假设来解决它，然后尽快用真实客户验证它。重复这个过程。
MVPM: User Experience
1. Know the design patterns of your product
1. 了解你产品的设计模式
Most products develop design patterns over time, whether planned or not. Patterns are the consistent use of the same visual and interactive components in your product. All text on buttons are font-size 25px, all forms must be no more than 3 fields, every time an error happens we will make an explosion sound and send the user an email with the details --- these are all patterns.
大多数产品都会随着时间的推移发展出设计模式，无论是有计划的还是无意的。模式是在产品中一致使用相同的视觉和交互组件。按钮上的所有文本都是 25px 字体大小，所有表单必须不超过 3 个字段，每次发生错误时我们都会发出爆炸声并向用户发送包含详细信息的电子邮件------这些都是模式。
Random example, Material Design on thenextweb.com
随机示例，thenextweb.com 上的 Material Design
Knowing your product's patterns are critical in understanding how users map your product in their minds, and how they can effectively be given new features over time. If you usually give users a green button saying "Add New Feature" when you launch something, and this time you switch to an orange button that says "Blow your mind", you will confuse the shit out of people.
了解你产品的模式对于理解用户如何在脑海中映射你的产品，以及他们如何能够随着时间的推移有效地获得新功能至关重要。如果你通常在发布东西时给用户一个写着"添加新功能"的绿色按钮，而这次你换成一个写着"震撼你的心灵"的橙色按钮，你会把人搞糊涂的。
As a product grows, consistent use of patterns becomes even more important because they enable teams to work independently of each other but still build a product that feels cohesive.
随着产品的增长，一致使用模式变得更加重要，因为它们使团队能够独立工作，但仍然构建一个感觉有凝聚力的产品。
Design patterns are also usually developed in harmony with technical patterns, like style guides and components, which are basically libraries of re-useable code that speed up teams because they don't have to re-design or re-implement the same functionality again.
设计模式通常也与技术模式（如样式指南和组件）协调开发，这些基本上是可重用代码的库，可以加速团队，因为他们不必重新设计或重新实现相同的功能。
Fastest way to learn --- Talk to your designer, they should know these patterns cold and (hopefully) be able to give you links to a style guide. Also talk to your front-end engineers, they can equivalently give you links to a pattern library.
最快的学习方式------ 与你的设计师交谈，他们应该对这些模式了如指掌，（希望）能够给你链接到一个样式指南。也与你的前端工程师交谈，他们同样可以给你链接到一个模式库。
How does this make you a better PM? --- Plainly put, designing products on pattern is far easier and faster. They let you stand on the shoulders of design decisions your team made in the past, decisions that result in a product that's easier for customers to use. If you ever need to break existing patterns - to be clear there sometimes good reasons to do so - be prepared with very good reasons why it's necessary for the long term health of the product.
这如何让你成为更好的产品经理？------ 坦率地说，基于模式设计产品要容易和快得多。它们让你站在团队过去做出的设计决策的肩膀上，这些决策导致一个对客户来说更容易使用的产品。如果你需要打破现有模式------需要明确的是，有时有很好的理由这样做------要为为什么这对产品的长期健康是必要的准备好非常好的理由。
2. Know how to execute user experience research
2. 知道如何执行用户体验研究
PMs are supposed to be the voice of the customer. If you don't understand your users, you will never build great products. From interviewing a single person face to face, to quantitatively analyzing millions of user actions, understanding the basics of good research are imperative to your job.
产品经理应该是客户的声音。如果你不了解你的用户，你永远不会构建出伟大的产品。从面对面采访一个人，到定量分析数百万用户行为，理解良好研究的基础对你的工作至关重要。
Fastest way to learn --- Effective research is a very big field, so instead of sending you into the rabbit hole, I recommend you focus on understand the following:
最快的学习方式------ 有效的研究是一个非常大的领域，所以为了不让你陷入兔子洞，我建议你专注于理解以下内容：
- Understand Sample Size and how to calculate statistical significance
理解样本量以及如何计算统计显著性 - How to normalize your sample and why that's important
如何规范化你的样本以及为什么这很重要 - How to ask unbiased, non-leading questions in surveys and interviews
如何在调查和采访中提出无偏见、非引导性的问题 - How to synthesize results and avoid bad conclusions
如何综合结果并避免错误的结论
How does this make you a better PM? --- By consistently and frequently testing your product with customers, you can take away a lot of the guesswork (and risk) in product development. Before a project even starts, you should be testing to validate that the problem you think you're trying to solve really is one. While you're designing and building, you should be testing that the product's design is easy to use and is likely to solve the customer problem. After launching, you should be validating that the problem was solved for the customers you wanted to solve it for.
这如何让你成为更好的产品经理？------ 通过持续和频繁地与客户测试你的产品，你可以消除产品开发中的大量猜测（和风险）。在项目开始之前，你应该测试以验证你认为要解决的问题确实是一个问题。在你设计和构建时，你应该测试产品的设计是否易于使用，是否可能解决客户问题。发布后，你应该验证问题是否为你想要解决的客户解决了。
3. Know how to prototype your ideas
3. 知道如何原型化你的想法
Prototyping in this context means being able to create visual mockups that can effectively express your ideas. They need to be good enough so that you can:
在这个上下文中，原型化意味着能够创建视觉模型，有效地表达你的想法。它们需要足够好，以便你能够：
Communicate a product concept clearly
清晰地传达产品概念
It is incredibly difficult to communicate a product experience verbally or in writing. A prototype, something people can see and preferably interact with (you can do this without code), is 10x more effective.
用语言或文字传达产品体验是极其困难的。一个原型，人们可以看到并最好与之交互的东西（你可以在没有代码的情况下做到这一点），效率要高出 10 倍。
There are two reasons for this: first, it forces the articulation of the product in terms of what customers will actually interact with, and second, because humans naturally think visually, a prototype levels the playing field so that everyone on the team can speak the same language and give their points of view effectively.
这有两个原因：首先，它迫使以客户实际将与之交互的内容来阐明产品；其次，因为人类天生以视觉方式思考，原型使竞争环境公平，以便团队中的每个人都能说同一种语言并有效地给出他们的观点。
Unblock a team when design is behind or absent
当设计落后或缺失时解除团队阻塞
In most projects, it is important that the product's design is ahead of development. Designers try to "stay ahead of the devs" because the switching costs for developers is much higher once they start building the product in a particular direction.
在大多数项目中，产品的设计领先于开发是很重要的。设计师试图"领先于开发者"，因为一旦开发者开始以特定方向构建产品，他们的切换成本就会高得多。
Because so much of product design is iterative and done in parallel with the build, when there's a setback (e.g. user research says the design is not effective) design can quickly fall behind. It's in those situations that a PM must be able to roll up her sleeves and be a "design intern" for the lead designer, helping to push pixels and ship mockups so the engineers can continue the build.
因为产品设计的很多部分是迭代的，并且与构建并行进行，当出现挫折时（例如，用户研究说设计无效），设计可能很快落后。在这些情况下，产品经理必须能够卷起袖子，成为首席设计师的"设计实习生"，帮助推动像素和发布模型，以便工程师可以继续构建。
Fastest way to learn --- I won't spend time justifying this, but just start using Sketch, it's like MS paint and Photoshop had a baby and it's awesome.
最快的学习方式------ 我不会花时间证明这一点，但只需开始使用 Sketch，它就像 MS Paint 和 Photoshop 生了一个孩子，它很棒。
How does this make you a better PM? --- By prototyping and showing people what you're thinking instead assuming they understand, you will get better feedback from your team on your ideas, and reduce the risk that mis-communication leads to wasted effort. Also, it's nice to be able to actually produce something tangible once in a while.
这如何让你成为更好的产品经理？------ 通过原型化并向人们展示你在想什么，而不是假设他们理解，你会从团队那里获得关于你想法的更好反馈，并减少沟通错误导致浪费努力的风险。此外，能够偶尔实际产出一些有形的东西也是很好的。
4. Where you shouldn't focus
4. 你不应该关注的地方
Don't focus on being a great visual designer. Your ability to make a slick looking interface is redundant and disempowering to someone who's spent a career learning the deep craft that is product design. Unless you're design savant (to be clear there are some), you also probably just think you're good, and you actually suck.
不要专注于成为一名伟大的视觉设计师。你制作光滑界面的能力对于花费职业生涯学习产品设计这一深厚技艺的人来说是多余的和削弱权力的。除非你是设计天才（需要明确的是，确实存在一些），否则你可能只是认为自己很好，而实际上你很糟糕。
MVPM
最小可行产品经理
I don't want to trivialize learning all this stuff. It's not easy, and it takes a lot of time, so tackle it bit by bit and enjoy what you're learning*. I hope this helps you be a little more efficient in your quest to be a great, if minimally viable, product manager.
我不想轻视学习所有这些内容。这不容易，需要很多时间，所以一点一点地攻克它，享受你正在学习的东西*。我希望这能帮助你在追求成为一名伟大的、即使是最低限度可行的产品经理的道路上更加高效一些。
Applying Leverage as a Product Manager
产品经理如何有效运用杠杆
Brandon Chu
Nov 29, 2016
I get every new PM I manage to read (or re-read) High Output Management by Andy Grove within the first month of joining my team. It's a timeless, no bullshit overview of what a manager is and how to think about being one. Most PMs do not have people reporting into them, but in all cases they are still managing outcomes that are executed through a team.
我要求我管理的每位新产品经理在加入团队后的第一个月内阅读（或重读）Andy Grove 的 High Output Management。这是一本关于管理者是什么以及如何思考成为管理者的永恒、毫不废话的概述。大多数产品经理没有直接下属，但在所有情况下，他们仍然在管理通过团队执行的结果。
There are two critical concepts in that book that I aspire for PMs on my team to internalize: the first is how to measure managerial output , and the second is the idea of managerial leverage.
书中有两个关键概念，我希望我团队中的产品经理能够内化：第一个是如何衡量管理产出 ，第二个是管理杠杆的概念。
Managerial output is what you produce as a manager and is succinctly explained the book:
管理产出 是你作为管理者所产出的东西，书中简洁地解释道：
A manager's output = output of their team + output of the surrounding teams that they influence
管理者的产出 = 他们团队的产出 + 他们影响的周围团队的产出
Managerial leverage is the idea that some things a manager does creates more output than others, and for each possible thing, the amount of output created per unit of time is its leverage. That's the basis of how you should decide whether to do activity A or activity B.
管理杠杆 是指管理者做的一些事情比其他事情创造更多产出的理念，对于每件可能的事情，每单位时间创造的产出量就是它的杠杆。这是你应该决定是做活动 A 还是活动 B 的基础。
When internalized, these concepts impart on PMs a sense of what matters most in their role. They have lots of choices in what they can do everyday --- all of which produce some positive output- but developing awareness of where they have leverage is critical to their long term impact.
当这些概念被内化时，它们会给产品经理一种关于他们角色中最重要事物的感知。他们在每天可以做的事情上有很多选择------所有这些都产生一些积极产出------但培养对他们拥有杠杆的地方的意识对他们长期的影响至关重要。
Here's a framework that I share with PMs on thinking about leverage in their roles (which coincidentally turns out to be one of my highest leverage activities as their manager).
以下是我与产品经理分享的关于思考他们角色中杠杆的框架（这巧合地成为我作为他们管理者的最高杠杆活动之一）。
Some definitions:
一些定义：
- Vision describes where you're going; the aspiration or goal
愿景 描述你要去哪里；抱负或目标 - Strategy defines how you plan to get to your vision in the context of the market/company/customers/product
战略 定义你计划如何在市场/公司/客户/产品的背景下实现你的愿景 - Scope defines what you need to ship to execute your strategy
范围 定义你需要发布什么来执行你的战略 - Backlog represents the units of work to achieve a scope
待办事项 代表实现范围的工作单元
What I hope PMs take away from this framework is simple:
我希望产品经理从这个框架中得到的很简单：
Product managers exert the most leverage through vision and strategy --- the rest is optimization
产品经理通过愿景和战略发挥最大的杠杆作用------其余的都是优化
Vision and Strategy are foundational. They provide the direction, the inspiration, and enable a group of people to execute as a team.
愿景和战略是基础。 它们提供方向、灵感，并使一群人能够作为一个团队执行。
Scope and Backlog are optimizations. They accelerate progress towards a known destination .
范围和待办事项是优化。 它们加速向已知目的地的进展。
Both are important, but going faster in the wrong direction is far worse than going slower in the right one. When prioritizing their focus, a PM should first ask themselves if they've built a solid foundation for their team to operate in. If not, that's where they need to start.
两者都很重要，但在错误的方向上走得更快比在正确的方向上走得更慢要糟糕得多。在优先考虑他们的关注点时，产品经理应该首先问自己，他们是否为团队的运作建立了坚实的基础。如果没有，那就是他们需要开始的地方。
First Principles of PM Leverage
产品经理杠杆的第一性原理
This framework was built upon an early aspiration of mine as a PM to create the conditions where:
这个框架建立在我作为产品经理的一个早期愿望之上，即创造条件使：
- Any individual on my team knows how their work directly contributes to achieving the company's vision. [Vision]
我团队中的任何个人都知道他们的工作如何直接有助于实现公司的愿景。[愿景]- Any individual on my team can explain the rationale behind why we're approaching the goal the way we are [Strategy]
我团队中的任何个人都能解释我们为什么以这种方式接近目标的理由。[战略]
This aspiration is rooted in leverage. Your team is full of smart engineers and designers who know better than you how to build things, so if you start focusing on the implementation details, not only are you exerting less managerial leverage, you're also diminishing their leverage .
这个愿望根植于杠杆。你的团队充满了比你更懂得如何构建东西的聪明工程师和设计师，所以如果你开始关注实现细节，你不仅施加了更少的管理杠杆，而且还在削弱他们的杠杆。
You're making 1+1 into 0.5 + 0.5.
你把 1+1 变成了 0.5 + 0.5。
In contrast, when a PM drives vision and strategy, their breadth of expertise accross the product makes them the best suited to process all the context, and subsequently make better decisions about the direction of the team.
相比之下，当产品经理推动愿景和战略时，他们在产品上的专业知识广度]使他们最适合处理所有背景，随后对团队方向做出更好的决策。
The easiest way to test for good product management on a team is to ask any engineer or designer on that team to describe the vision and strategy for their product. The coherence of their answers will give you all the feedback you need.
测试团队上良好产品管理的最简单方法是询问该团队上的任何工程师或设计师描述他们产品的愿景和战略。他们答案的一致性将给你所需的所有反馈。
Building the Foundation
建立基础
Vision and Strategy are often seen as wishy-washy concepts, the domain of MBAs with no hard skills. They are in fact critical, and in my experience, most PMs don't actually know the distinction between the two, nor how to utilize them effectively.
愿景和战略通常被视为含糊不清的概念，是没有硬技能的 MBA 的领域。事实上它们是关键的，根据我的经验，大多数产品经理实际上不知道两者之间的区别，也不知道如何有效利用它们。
Vision
愿景
Vision is used to describe the end state of your team's efforts. Its primary importance is to provide the organization a succinct understanding of what a team cares about. It represents the heart, the raison d'etre , of that team.
愿景用于描述团队努力的最终状态。它的主要重要性是为组织提供一个简洁的理解，即团队关心什么。它代表了该团队的核心，存在的理由。
A good vision influences the everyday micro-decisions being made by a team. It should also be the basis of alignment between a product team and their stakeholders.
一个好的愿景影响团队做出的日常微观决策。它也应该是产品团队与其利益相关者之间一致性的基础。
I won't go too deep in this post about how to establish a good vision, but I will share one thing that I always remind PMs I manage, which is that the vision they create has to fit into the bounds of the company's vision (and in bigger organizations, any parent group vision).
我不会在这篇文章中深入探讨如何建立一个好的愿景，但我会分享一件我总是提醒我管理的产品经理的事情，那就是他们创造的愿景必须符合公司愿景的界限（在更大的组织中，任何上级团队的愿景）。
Make sure your vision fits into the company's.
确保你的愿景符合公司的愿景。
I've seen too many PMs come in guns blazing, trying to be the CEO of the product and do epic shit . I love the energy --- and their vision should still be ambitious, exciting, and strongly opinionated --- but it can't deviate from the bounds of the global vision, or else they run the risk of a blow-up down the line.
我见过太多产品经理带着满腔热情进来，试图成为产品的 CEO 并做史诗般的事情。我喜欢这种能量------他们的愿景仍然应该是有野心的、令人兴奋的、有强烈观点的------但它不能偏离全球愿景的界限，否则他们就有在未来某个时刻崩溃的风险。
PMs should always be spending considerable time talking to the leadership team in their company to internalize the nuances of the vision. This is true of new PMs and ones that have been there for a while, as the process of vision alignment never really ends. The forces of growth and technology continuously spur up new situations which push a vision --- one that was established in much simpler times --- into new territory and debate.
产品经理应该始终花费大量时间与公司的领导团队交谈，以内化愿景的细微差别。这对于新产品经理和已经在那里工作了一段时间的产品经理都是如此，因为愿景对齐的过程从未真正结束。增长和技术的力量不断刺激出新情况，推动一个------在更简单时期建立的------愿景进入新的领域和辩论。
At Shopify, we call this staying on the green path .
在 Shopify，我们称之为保持在绿色路径上。
Strategy
战略
Strategy describes the chosen approach towards achieving the vision. Its primary importance is to intersect the goals of the vision and the realities of the world into a gameplan for action.
战略描述了实现愿景所选的方法。它的主要重要性是将愿景的目标与世界的现实交叉成一个行动计划。
Building a strategy is hard because the world isn't like this:
建立战略很困难，因为世界不是这样的：
Instead, there are tons of things to consider that influence your path forward. Should we do feature A, B, or C first? Who should be the first customers we target? How likely is competitor X to do the same thing, and in what time frame? A good strategy incorporates questions like these into a decision about how to proceed.
相反，有大量的事情需要考虑，这些事情会影响你前进的道路。我们应该先做功能 A、B 还是 C？谁应该是我们瞄准的首批客户？竞争对手 X 有多大可能做同样的事情，在什么时间框架内？一个好的战略将这样的问题纳入关于如何继续的决策中。
Again, I won't deviate into the making of a strategy here, but will leave one thought I see PMs often trip up on.
同样，我不会在这里偏离战略的制定，但会留下一个我经常看到产品经理绊倒的想法。
A strategy is not a roadmap. Roadmaps should be an output of strategy , and good ones will always clearly tie back to one. Real strategy answers what we're building and why , who we're going to target and why , how we're going to grow and why , and how the end result will put the company into a better competitive position relative to alternatives. And why.
战略不是路线图。 路线图应该是战略的输出 ，好的路线图总是会清楚地与之联系。真正的战略回答我们在构建什么以及为什么 ，我们将瞄准谁以及为什么 ，我们将如何增长以及为什么 ，以及最终结果将如何使公司相对于替代品处于更好的竞争地位。以及为什么。
Leverage Enables PMs to Scale Efficiently
杠杆使产品经理能够高效扩展
The final benefit of operating under this framework is that it enables a product manager's impact to scale more efficiently as they grow in a company. By becoming great at setting the foundation for a team, a single PM can have significantly more impact within an organization by doing that work accross a set of teams.
在这个框架下运作的最终好处是，它使产品经理的影响力能够随着他们在公司中的成长而更有效地扩展。通过擅长为团队奠定基础，一个产品经理可以通过在一组团队中做这项工作，在组织内产生显著更大的影响。
Next-level pyramid use.
下一级别的金字塔使用。
Admittedly, there are still times when PMs do need to drive the optimization portions of the pyramid, particularly in high priority or time sensitive projects where there is lots of executional risk. In those cases, refinement of scope and排序 materially increases the likelihood of success and value to the company and a PM should be capable of doing it.
诚然，有时产品经理确实需要驱动金字塔的优化部分，特别是在高优先级或时间敏感的项目中，这些项目存在大量的执行风险。在这些情况下，范围和排序的细化实质上增加了对公司的成功和价值的可能性，产品经理应该有能力做到这一点。
Generally though, when headcount is growing quickly and there are more teams ready to build then there are visions to execute, it makes most sense for PMs to build foundations for as many products as they can and then just trust their teams to execute.
但一般来说，当人数快速增长，准备构建的团队多于要执行的愿景时，产品经理为他们能做的尽可能多的产品建立基础，然后信任他们的团队去执行，是最有意义的。
At Shopify, we're now seeing the median PM manage 2--3 products, which in most places would be untenable. I believe this is possible in large part because of the appreciation of managerial leverage within our organization, and because of the incredible team we have in engineering and design.
在 Shopify，我们现在看到中位数的产品经理管理 2-3 个产品，这在大多数地方是不可持续的。我相信这在很大程度上是因为我们组织内对管理杠杆的欣赏，以及我们在工程和设计中拥有的令人难以置信的团队。
Are you doing the highest leverage work you can?
你在做你能做的最高杠杆的工作吗？
If nothing else, I strive for PMs to take this question and make it a mindset.
如果没有别的，我努力让产品经理接受这个问题，并使其成为一种心态。
Make your next hour the most impactful it can be, and assume creating output through your team is the best way to do it. Ask yourself if you've established the right foundations for your team to operate in, and if not, build them.
让你下一个小时尽可能有影响力，并假设通过你的团队创造产出是最好的方式。问问自己，你是否为团队的运作建立了正确的基础，如果没有，就建立它们。
Ruthless Prioritization
无情的优先级排序
Brandon Chu
Mar 6, 2017
All high functioning teams must prioritize. Not once a month, not once a week --- but rigorously, and ruthlessly .
所有高绩效团队都必须进行优先级排序。不是一个月一次，不是一周一次------而是严格地、无情地。
Prioritization means doing the things that are most important first. If you build products, it means doing the things that create the most customer value first.
优先级排序意味着先做最重要的事情。如果你构建产品，它意味着先做那些创造最大客户价值的事情。
In my experience, the craft of making prioritization decisions is one of the most difficult skills to impart on teams because of how complex those decisions can become, and while it's usually a core responsibility of product managers, I've found that the best teams are the ones where everyone is maniacally prioritizing towards the same goal, and doing so in a way that's consistent with each other.
根据我的经验，做出优先级排序决策的技艺是最难传授给团队的技能之一，因为这些决策可能变得多么复杂，虽然这通常是产品经理的核心职责，但我发现最好的团队是那些每个人都疯狂地朝着同一个目标进行优先级排序，并以彼此一致的方式这样做的团队。
This post is about a framework to think about prioritization.
这篇文章是关于一个思考优先级排序的框架。
A Framework for Prioritization
优先级排序框架
Prioritization in product management can be broken down into two scopes:
产品管理中的优先级排序可以分解为两个范围：
- Prioritization between projects --- this is about determining what project your team should do next.
项目之间的优先级排序 ------ 这是关于确定你的团队下一步应该做什么项目。 - Prioritizing work within a project ---this is about how efficiently you can execute a project.
项目内部的优先级排序 ------ 这是关于你能多高效地执行一个项目。
As we'll see, the way we should tackle each of these scopes is very different. The reason is because they are each driving at different types of decisions.
正如我们将看到的，我们应该处理这两个范围的方式非常不同。原因是它们各自驱动不同类型的决策。
When prioritizing between projects, you have to make one big decision: what will my team invest in next? The right way to approach this turns out to be like completing a puzzle. Apply a rigorous process to find all the pieces, and the answer is in how they all fit together.
当在项目之间进行优先级排序时，你必须做一个重大决定：我的团队下一步将投资什么？ 正确的方法原来是像完成一个拼图。应用一个严格的流程来找到所有的碎片，答案就在于它们如何组合在一起。
When prioritizing work within a project, you have to make the same decision hundreds of times: is this absolutely necessary to do? The right way to approach this is by accepting the chaotic nature of building products, and then develop a ruthless mindset to make quick decisions about what's absolutely necessary.
当在项目内部进行优先级排序时，你必须做数百次相同的决定：这绝对有必要做吗？ 正确的方法是接受构建产品的混乱 本质，然后培养一种无情的心态来快速决定什么是绝对必要的。
Prioritizing between projects
项目之间的优先级排序
A rigorous process to solve the puzzle: What will my team invest in next?
一个解决难题的严格流程：我的团队下一步将投资什么？
Answering this question may require rigour, but the process isn't complicated:
回答这个问题可能需要严谨，但流程并不复杂：
- Estimate return on investment for each project
估算每个项目的投资回报率 - Apply three constraints: dependencies, timelines, and team composition
应用三个限制：依赖关系、时间线和团队构成 - Put the puzzle together --- sequence projects based ROI + constraints
把拼图拼在一起------基于投资回报率 + 限制对项目进行排序
I'm going to assume most of these concepts aren't new to readers, so we're going to go through them pretty quickly.
我假设这些概念对读者来说大多数都不是新的，所以我们将很快地过一遍。
1. Estimate Return on Investment
1. 估算投资回报率
The basis for all project prioritization is return on investment (ROI), which is measured as the amount of customer value your team creates for a unit of time. Your goal with prioritization is to always be doing the work that maximizes customer value created over time.
所有项目优先级排序的基础是投资回报率（ROI），它衡量的是你的团队每单位时间创造的客户价值量。你进行优先级排序的目标是始终在做最大化随时间创造的客户价值的工作。
In order to prioritize between projects, you need to estimate two data points:
为了在项目之间进行优先级排序，你需要估算两个数据点：
- the amount of customer value that will be produced
将产生的客户价值量 - the amount of time it will take to finish the project
完成项目所需的时间
Once you have this data for each project, you can simply compare them all and then voilà --- you have your priorities.
一旦你有了每个项目的这些数据，你可以简单地比较它们，然后瞧------你就有了你的优先级。
Mechanically this is what you're trying to do
从机制上讲，这就是你试图做的
Of course, it's notoriously difficult to estimate both impact and effort, but assuming you have an equal chance of being wrong each time you estimate, then as a comparative exercise calculating ROI is a legitimate method of project prioritization.
当然，估算影响和努力是出了名的困难，但假设你每次估算都有同等的错误机会，那么作为比较练习，计算 ROI 是项目优先级排序的合法方法。
Pro-tip: double the effort and halve the impact of any estimates, and you'll be much closer to reality.
专业提示：将任何估算的努力翻倍，影响减半，你就会更接近现实。
2. Apply Constraints
2. 应用限制
Since life isn't as orderly as a spreadsheet, there are also constraints that you need to factor into your prioritization decisions. The core constraints you have to deal with are dependencies, timelines, and team composition.
由于生活不像电子表格那样有序，还有限制你需要纳入你的优先级排序决策中。你必须处理的核心限制是依赖关系、时间线和团队构成。
Dependencies
依赖关系
A dependency is created when a unit of work needs to be complete in order for another unit of work to progress.
当一个工作单元需要完成以便另一个工作单元能够进展时，就产生了依赖关系。
Say you're on the mobile team and you want to create a seamless one-tap payments button for customers on their phones. You've identified this is the highest ROI project, so you want to do it asap.
假设你在移动团队，你想为客户创建一个无缝的一键支付按钮。你已经确定这是投资回报率最高的项目，所以你想尽快做。
However, to do that, your company actually needs to have the ability to accept payments in the first place, which another team is working on now. The dependency on the other team finishing means you can't really do anything yet, so the correct prioritization decision is to delay the one-tap feature and do your next highest ROI project.
然而，要做到这一点，你的公司实际上首先需要有能力接受支付，这是另一个团队现在正在做的。对另一个团队完成的依赖意味着你还不能真正做任何事情，所以正确的优先级排序决定是推迟一键功能，做你的下一个投资回报率最高的项目。
Dependencies are everywhere when building products, and it gets worse the more successful your product becomes, as scale creates more complex systems. In larger companies, understanding and working around dependencies are often the most vital dimensions to prioritizing.
构建产品时，依赖关系无处不在，而且你的产品越成功，情况就越糟，因为规模创造了更复杂的系统。在更大的公司中，理解和解决依赖关系通常是最重要的优先级排序维度。
As an aside, most people think startups are fast because they work harder and are more ambitious. The truth is that most of the speed difference comes from having far fewer dependencies (and few customers to upset if something screws up), so it's just easier to get stuff done.
大多数人认为初创公司之所以发展迅速，是因为他们工作更努力、雄心勃勃。实际上，速度差异的大部分原因在于他们的依赖关系更少（而且客户也少，如果出现问题就不会有太多人受到影响），因此更容易完成工作。
Reverse Dependencies
反向依赖
There are times when you have a project that will really help other teams to achieve their goals. You are the dependency in this case.
有时你有一个项目会真正帮助其他团队实现他们的目标。在这种情况下，你就是依赖关系。
If you're optimizing for the company's ROI above your product's--- which you should be --- you'll now need to assess the cumulative ROI of not just your项目，还有你解锁的依赖项目，以便为你的团队做出正确的优先级排序决定。
Whenever I see teams working to unblock other teams they earn a lot of respect from me, and it signals maturity in their product thinking. These teams are the unsung heroes of product公司，是为公司提供最大杠杆的团队。
Timelines
时间线
Timelines are the canonical constraint, one we've all experienced. A particularly serious one is when your startup will run out of cash and die before the highest ROI feature will ship.
时间线是经典的限制，我们都经历过。一个特别严重的情况是，当你的初创公司在最高投资回报率功能发布之前就会耗尽资金并死亡。
When this happens, the correct prioritization decision of course is to do the highest ROI project that is achievable within the timeframe.
当这种情况发生时，正确的优先级排序决定当然是做在时间框架内可实现的最高投资回报率项目。
Team composition
团队构成
Not all teams are equal, and sometimes the composition of the specific people on your team means that you will need to make different prioritization decisions about which project to take on.
并非所有团队都是平等的，有时你团队中特定人员的构成意味着你需要对承担哪个项目做出不同的优先级排序决定。
An example is having a team that is full of brand new people to the company, like a gaggle of interns (no disrespect to interns, 50% of all software is built by them).
一个例子是拥有一个充满公司新人的团队，像一群实习生（无意冒犯实习生，50% 的软件是由他们构建的）。
In these situations you should be wary of prioritizing a project that has a lot of risks to customers, even if it's the highest ROI. Instead, you'll often be better off prioritizing a project that doesn't touch any critical代码或用户体验旅程，因为这样不良后果的严重性就会降低。
Help newbie teams get their feet wet first by shipping small wins. Once they have a few production features under their belt, they can progress towards more complex projects.
通过发布小胜利来帮助新手团队先试水。一旦他们有了几个生产功能，他们就可以向更复杂的项目迈进。
Prioritizing between projects: Complete the puzzle and get to work
项目之间的优先级排序：完成拼图并开始工作
I'm trivializing the amount of work it takes to gather all the information above, but once you have it all, you just have put the pieces together.
我轻视了收集上述所有信息所需的工作量，但一旦你有了所有信息，你只需要把碎片拼在一起。
Prioritizing work within a project
项目内部的优先级排序
A ruthless mindset to determine: Is this absolutely necessary to do?
一种无情的心态来确定：这绝对有必要做吗？
The nature of prioritization is different during the execution of a project. It's chaotic. Decisions are needed everyday, and you don't have time analyze each one as deeply as we did when prioritizing between projects. It's also a more emotional time for a team, as real customers are going to be impacted, and their reputation may feel on the line.
在项目执行期间，优先级排序的性质是不同的。它是混乱的。每天都需要决策，你没有时间像我们在项目之间进行优先级排序时那样深入分析每一个决策。对团队来说，这也是一个更情绪化的时期，因为真正的客户将受到影响，他们的声誉可能会感到受到威胁。
The only way to combat the speed and chaos of building products is to develop a ruthless mindset , one that is constantly aware of the work a team is doing and challenges them on the necessity of that work.
对抗构建产品的速度和混乱的唯一方法是培养一种无情的心态，这种心态不断意识到团队正在做的工作，并质疑该工作的必要性。
Having a ruthless mindset means accepting reality. It's a realization that you will have to make hard choices every day on where to focus. It's a realization that shipping the perfect product is an illusion, and that trade-offs are always required to ship.
拥有无情的心态意味着接受现实。这是一种意识到你将不得不每天就关注点做出艰难选择的认识。这是一种意识到发布完美产品是一种幻觉，发布总是需要权衡的认识。
Having a ruthless mindset is about the will to ship. Stakeholder and customer expectations create enormous pressure on teams, and as a result they are often afraid to ship. They start sweating tiny issues so much that they're frozen into inaction. They start losing sight of what matters, customer value created over time, and start trying to be perfect.
拥有无情的心态是关于发布的意愿。利益相关者和客户的期望给团队带来了巨大的压力，结果他们常常害怕发布。他们开始为微小的问题如此焦虑，以至于被冻结在无所作为中。他们开始忽视重要的东西，随时间创造的客户价值，并开始试图做到完美。
Show me a team that has no bugs at launch, and I'll show you one that should have shipped a long time ago.
给我看一个在发布时没有 bug 的团队，我会给你看一个早就应该发布的团队。
In reality, the chaotic nature of prioritizing work within a project means that defining a process around it is foolhardy. A more productive strategy is to help teams internalize product development concepts that aid them in ruthlessly answering "is this absolutely necessary?" . Here are the one's we'll cover in the remainder of this post:
在现实中，项目内部优先级排序的混乱性质意味着围绕它定义一个流程是愚蠢的。一个更有成效的策略是帮助团队内化产品开发概念，帮助他们无情地回答*"这绝对有必要吗？"*。以下是我们在本文剩余部分将涵盖的内容：
- Building prioritization systems
建立优先级排序系统 - Using product assumptions to make quality vs. speed trade offs
使用产品假设来做出质量与速度的权衡 - The Time Value of Shipping
发布的时间价值
1. Building prioritization systems
1. 建立优先级排序系统
All software is a liability. It has bugs now, and it will develop more over time. When faced with a new bug, if your team can't quickly figure out if they should fix it or not, their ability to focus on the most important work will be constantly disrupted.
所有软件都是一种负债。它现在有 bug，随着时间的推移会产生更多。当面对一个新 bug 时，如果你的团队不能快速弄清楚是否应该修复它，他们专注于最重要工作的能力就会不断受到干扰。
You can't afford to have a prioritization meeting every time a bug pops up, so one of the highest leverage things you can do is to create a system that determines when to fix bugs or when to move on.
你不能每次出现 bug 都开一个优先级排序会议，所以你能做的最高杠杆的事情之一是创建一个系统，决定何时修复 bug 或何时继续前进。
Here's an example of one that I've found productive for my teams:
以下是我发现对我的团队有成效的一个例子：
The X axis represents the frequency that a bug affects users, and the Y axis represents the severity of that bug. A red dot is a bug.
X 轴代表 bug 影响用户的频率，Y 轴代表该 bug 的严重性。红点是一个 bug。
To use this system, work with your team to define what level of severity is too severe (in this case, that users can't pay) and which level of frequency is too frequent (in this case, 5% of users affected). Then, agree on a set of actions given which zone the bug falls, with at least one of those actions being put in the backlog and do nothing.
要使用这个系统，与你的团队合作定义什么级别的严重性是太严重 （在这种情况下，用户无法支付）以及什么级别的频率是太频繁 （在这种情况下，5% 的用户受影响）。然后，就 bug 落入哪个区域采取一系列行动达成一致，其中至少一个行动是放入待办事项列表并不采取任何行动。
If you invest in this, your team will be a bug triaging machine, and the chance of someone working on a低价值 bug will be systematically removed.
如果你在这方面投入，你的团队将成为一个 bug 分类机器，有人处理低价值 bug 的机会将被系统地消除。
2. Using product assumptions to make quality vs. speed trade offs
2. 使用产品假设来做出质量与速度的权衡
You'll often hear about shitty code written by founders in the early days of a product. As the company became successful, this code created nightmares for new engineers joining the team.
你经常会听到关于产品早期创始人写的糟糕代码。随着公司的成功，这段代码给加入团队的新工程师带来了噩梦。
Were the founders poor programmers? Maybe. But more likely than not, they didn't care much about code quality at the time because the product was unlikely to succeed. Instead, they cared about speed and validating their idea.
创始人是糟糕的程序员吗？也许。但更可能的是，他们当时不太关心代码质量，因为产品不太可能成功。相反，他们关心的是速度和验证他们的想法。
In order to ship, every team invariably makes some sacrifices to quality. Teams have to choose when enough is enough, and that comes down to a prioritization decision about what is essential to the quality of a product.
为了发布，每个团队不可避免地会对质量做出一些牺牲。团队必须选择什么时候足够了，这归结为关于什么是产品质量本质的优先级排序决定。
Here's a useful way to guide yourself to the right spot on the spectrum of speed vs. quality: base it around your product assumptions . Product assumptions are fundamental beliefs that you hold about a customer problem, or the solution you're building for them.
以下是一个有用的方法，可以指导你在速度与质量光谱上找到正确的位置：围绕你的产品假设。产品假设是你对客户问题的基本信念，或者你为他们构建的解决方案。
A simple example from the early days of Facebook would have been the problem assumption that people want to connect with each other online . Once that problem was validated, they then thought of product ideas like being able to add another user as a friend, which is a solution assumption about how to solve that problem.
Facebook 早期的一个简单例子是问题假设，即人们想要在网上相互联系 。一旦这个问题得到验证，他们就想到了产品想法，比如能够将另一个用户添加为好友，这是一个关于如何解决该问题的解决方案假设。
If you think about your product, there are three situations you can be in with respect to these product assumptions:
如果你考虑你的产品，关于这些产品假设，你可能处于三种情况：
- The problem you're trying to solve is an assumption
你试图解决的问题是一个假设 - The solution to fulfill a known problem is an assumption
满足已知问题的解决方案是一个假设 - Neither are assumptions (you know exactly what's needed and why)
两者都不是假设（你确切知道需要什么以及为什么）
When you find yourself on the left side of this spectrum, you have an assumption about a customer problem but you don't know if it's real. In this situation, you should be cutting corners to ship something as fast as possible, which minimizes the risk that you'll be trying to solving a problem that doesn't exist.
当你发现自己处于这个光谱的左侧时，你对客户问题有一个假设，但你不知道它是否真实。在这种情况下，你应该抄近路以尽快发布某些东西，这最小化了你将试图解决一个不存在的问题的风险。
On the right end of the spectrum, if there is high confidence in what problem you're solving and how to build the right solution, then you should maximize quality because you know that feature will be successful and will need to scale well into the future.
在光谱的右端，如果你对解决什么问题以及如何构建正确的解决方案有很高的信心，那么你应该最大化质量，因为你知道该功能将会成功，并且需要在将来很好地扩展。
You'll often see companies split teams into those that "experiment" and those that do "core" work. In my opinion, organizational structures like this reflect the inability for most teams to understand the product assumption spectrum, and be able to switch gears towards speed or quality.
你经常会看到公司将团队分为"实验"团队和做"核心"工作的团队。在我看来，这样的组织结构反映了大多数团队无法理解产品假设光谱，并能够转向速度或质量的能力不足。
3. The Time Value of Shipping
3. 发布的时间价值
Software only creates value for customers once it's shipped.
软件只有在发布后才能为客户创造价值。
As such, we should be able to place a value on shipping something faster to customers. This is a concept I wrote about a while ago called The Time Value of Shipping.
因此，我们应该能够对更快向客户发布某些东西进行估值。这是我之前写过的一个概念，称为发布的时间价值。
As an example, a difficult choice product teams often face is whether or not to ship a feature early to 80% of the customer base, while delaying the feature for the last 20%. This choice typically arises when building the final 20% requires a lot of niche functionality, which takes double the time to build (as the first 80%).
例如，产品团队经常面临的一个艰难选择是是否提前向 80% 的客户群发布一个功能，同时为最后 20% 延迟该功能。当构建最后 20% 需要大量小众功能时，通常会出现这种选择，这需要双倍的时间来构建（相对于前 80%）。
Let's break down this choice:
让我们分解这个选择：
Looking at the diagram, we see that the 80% of customers are enjoying an additional period of getting value in option #1, whereas in option #2 they have to wait. So is it obvious to choose #1? Not exactly, it's still a hard choice for the team because:
看图表，我们看到在选项 #1 中，80% 的客户正在享受一段额外的获得价值的时期，而在选项 #2 中他们必须等待。那么选择 #1 是显而易见的吗？不完全是，这对团队来说仍然是一个艰难的选择，因为：
- The 20% of customers that the feature doesn't work for will definitely recognize your choice to not support them, and they'll be pissed. To them, it's worse than if you gave them nothing at all.
- The 80% of customers that the feature does work for don't actually perceive the extra value they received from getting the feature early.
- 该功能对其不起作用的 20% 客户肯定会意识到你选择不支持他们，他们会很生气。对他们来说，这比什么都不给他们更糟糕。
- 该功能对其起作用的 80% 客户实际上并没有感知到他们从提前获得功能中获得的额外价值。
The irony of these two effects is that you will actually have more pissed off customers by making the decision to provide more customer value over time to them*.* Strange times we live in.
这两个效果的讽刺之处在于，通过做出决定向他们提供随时间更多的客户价值 ，你实际上会有更多生气的客户。我们生活在一个奇怪的时代。
Despite the above, when faced with this choice I usually encourage teams to be ruthless and ship it. Here's why:
尽管有上述情况，当面临这种选择时，我通常鼓励团队无情地发布它。原因如下：
- If customers knew the full context and could make the decision for us, the majority of them would want us to ship it.
如果客户知道完整的背景并能为我们做出决定，他们中的大多数会希望我们发布它。 - In the long run, if a team consistently follows this strategy, the number of times a customer will fall on the good side of that 80%|20% will even out, and as a result, relative to a company that always waits for 100%, customers will get exponentially more value over time as the effect of constantly getting features earlier compounds.
从长远来看，如果一个团队始终遵循这一策略，客户落在 80%|20% 好的一边的次数会趋于平衡，因此，相对于总是等待 100% 的公司，客户会随着时间的推移获得指数级更多的价值，因为不断提前获得功能的效应会复合。
Placing a value on shipping faster to customers is one of those concepts that is easy to understand, but hard to act on because of pain that comes with it. Ruthless prioritizers will see through this, and act in the best interests of customers.
对更快向客户发布进行估值是那些容易理解但难以执行的概念之一，因为它伴随着痛苦。无情的优先级排序者会看穿这一点，并为客户的最佳利益行事。
Prioritizing work within a project: Ruthless mindsets are unnatural
项目内部的优先级排序：无情的心态是不自然的
The concepts we've covered are only what experience has taught me are worth internalizing. There are more, and you tweak these with your own based on your experiences.
我们涵盖的概念只是经验教给我值得内化的东西。还有更多，你可以根据自己的经验调整这些。
Sadly, most teams in the industry aren't incentivized to be ruthless prioritizers, despite it being a core meme of product companies.
可悲的是，行业中大多数团队没有被激励成为无情的优先级排序者，尽管这是产品公司的核心模因。
For example, in larger organizations, teams are shipping features all the time and most employees don't even hear about a launch until customers do. In that environment, do you think employees can see that their teammates managed to ship 3x faster than others in their place would have? Likely not. Instead, they only see what's missing in the product, even though all those shortcomings were consciously accepted by their teammates.
例如，在更大的组织中，团队一直在发布功能，大多数员工直到客户知道才听说发布。在这种环境中，你认为员工能看到他们的队友比其他人快 3 倍发布吗？可能不能。相反，他们只看到产品中缺少什么，即使所有这些缺点都是他们的队友有意识地接受的。
In contrast, a perfectly polished product tends to receive a lot of praise internally. Too bad it took two years to ship. Too bad we rarely think about all the customers that churned because they never thought it would come.
相比之下，一个完美打磨的产品往往会在内部获得很多赞扬。可惜花了两年时间才发布。可惜我们很少想到所有那些流失的客户，因为他们从未想过它会到来。
Challenge your team to be better. Challenge them to be ruthless.
挑战你的团队变得更好。挑战他们变得无情。
Prioritization is a craft
优先级排序是一门技艺
Your team's time is the most precious resource a company has at it's disposal, and if part of your job is to direct that time, you need to become great at it. It's a craft, and one that you can deliberately get better at with practice.
你团队的时间是公司拥有的最宝贵资源，如果你工作的一部分是指导这段时间，你需要在这方面变得出色。这是一门技艺，你可以通过练习有意识地变得更好。
I'd like to leave you with one last truth about prioritization: there is always a way to accomplish your goal faster than you currently plan to.
我想给你留下关于优先级排序的最后一个真理：总有一种方法可以比你目前计划的更快地完成你的目标。
Always. You just have to find it. You just have to ask, "How can we do this in half the time? " at the end of that planning meeting*,* and miraculously --- the team will find a way.
总是如此。你只需要找到它。你只需要在规划会议结束时问，"我们如何在一半时间内完成这个？"，奇迹般地------团队会找到一种方法。
After years of shipping products, I have yet to come across a situation where a team was unable to figure out how to create the same customer value with less time invested. I also have never come across a situation where a team ended up prioritizing things perfectly, which reinforces the same idea.
经过多年的产品发布，我还没有遇到过团队无法弄清楚如何在投入更少时间的情况下创造相同客户价值的情况。我也从未遇到过团队最终完美地进行优先级排序的情况，这强化了同样的想法。
If you accept that there's always a way, the only logical thing to do is to be ruthlessly and rigorously prioritizing, whether you're executing a project now, or you're deciding which project to take on next.
如果你接受总有办法，唯一合乎逻辑的事情就是无情地、严格地进行优先级排序，无论你现在正在执行一个项目，还是正在决定接下来承担哪个项目。
Even if your project is an entire country.
即使你的项目是一个整个国家。
Making Good Decisions as a Product Manager
作为产品经理做出好的决策
Brandon Chu
Jul 11, 2017
While product managers may not build the actual product, they do produce something very tangible for a team: decisions .
虽然产品经理可能不会构建实际的产品，但他们确实为团队生产了一些非常具体的东西：决策。
July 23 update: in retrospect and from feedback, this framework applies to any role, not just product management.
7 月 23 日更新：回顾和从反馈来看，这个框架适用于任何角色，不仅仅是产品管理。
These decisions can be about anything: small ones like a line of copy in the docs, to big ones like what the MVP of a new feature should be.
这些决策可以是关于任何事情的：小到文档中的一行文案，大到新功能的 MVP 应该是什么。
The decisions PMs make are the ones that unblock their team so they can continue to build. They don't need to make every decision, but they are responsible for ensuring a decision gets made --- whether by them, their team, or their stakeholders.
产品经理做出的决策是解除团队阻塞以便他们能够继续构建的决策。他们不需要做出每一个决策，但他们负责确保做出决策------无论是由他们、他们的团队还是他们的利益相关者。
Product managers are the hedge against indecision, and it's uniquely our job because we tend to have the most context in a company. Typically, the most important decisions that a PM makes are, in order:
产品经理是对抗优柔寡断的屏障，这是我们独特的工作，因为我们往往在公司中拥有最多的背景。通常，产品经理做出的最重要的决策按顺序是：
- Why a team exists (vision and the impact they aspire to create)
团队为什么存在（愿景和他们渴望创造的影响） - What the general approach is to accomplish the vision (strategy)
实现愿景的一般方法是什么（战略） - What to build now, and what not to build (project prioritization)
现在构建什么，不构建什么（项目优先级排序） - What the smallest thing that can be built is that achieves the impact (MVP)
能够实现影响的最小可构建事物是什么（MVP）
Since we've already discussed these decisions before, and observed a really bad one, in this post we're going to focus on something more general: What does it mean for a PM to be a good decision maker?
既然我们已经讨论过这些决策，并观察过一个非常糟糕的决策，在这篇文章中，我们将关注更一般的事情：对于产品经理来说，成为一个好的决策者意味着什么？
Being a Good Decision Maker
成为一个好的决策者
Intuitively, being right a lot matters.At the same time, and in contrast, there are often factors outside of our control that determine outcomes.
直观上，经常正确很重要。同时，相反地，往往有我们无法控制的因素决定结果。
Maybe you're building an iOS app and then Apple changes their terms of service so your app is in breach. Maybe a law passes that makes your on-demand services illegal in your biggest markets.
也许你正在构建一个 iOS 应用，然后苹果改变了他们的服务条款，所以你的应用违规了。也许通过了一项法律，使你在最大市场上的按需服务非法。
These situations all happen in a flash, are hard to predict, and can negate any good decision you otherwise made. In such an environment, how can one objectively analyze their decisions?
这些情况都发生在瞬间，难以预测，并且可以否定你原本做出的任何好的决策。在这样的环境中，一个人如何客观地分析他们的决策？
I propose that being a good decision maker means doing two things:
我提出，成为一个好的决策者意味着做两件事：
- Making decisions using the right amount of information
使用适量的信息做出决策 - Making decisions as quickly as possible
尽快做出决策
Making good decisions using the right amount of information
使用适量的信息做出好的决策
Deciding how important a decision is, is the most important decision you can make. For people that make decisions for a living, understanding when one is really important vs. not-that-important is the most critical skill.
决定一个决策有多重要，是你能做的最重要的决定。对于以做决策为生的人来说，理解什么时候一个决策真正重要 vs 不那么重要是最关键的技能。
In Amazon's 2016 shareholder letter, Jeff Bezos touches on this concept with what he calls type 1 and type 2 decisions.
在亚马逊 2016 年股东信中，Jeff Bezos 用他所说的第一类和第二类决策触及了这个概念。
Type 1 decisions are not reversible, and you have to be very careful making them.
第一类决策是不可逆的，你必须非常小心地做出它们。
Type 2 decisions are like walking through a door --- if you don't like the decision, you can always go back.
第二类决策就像穿过一扇门------如果你不喜欢这个决策，你总是可以回去。
What Bezos drives at in the letter is that the impact of a decision guides how much effort you need to put into making it. You can be right 99% of the time, but if you're wrong the 1% of times when it really matters, you're not an effective decision maker. The takeaway is that when the stakes are high, you should work a lot harder at making the right decision.
Bezos 在信中强调的是，决策的影响指导你需要投入多少努力来做出它。你可以 99% 的时间都是正确的，但如果你在真正重要的 1% 时间里错了，你就不是一个有效的决策者。要点是，当赌注很高时，你应该更加努力地做出正确的决策。
Although I don't see Type I and II decisions as binary, I do see them as representing the spectrum for a framework for determining "decision importance":
虽然我不把第一类和第二类决策视为二元的，但我确实将它们视为确定"决策重要性"框架的光谱：
Plot your decision against each spectrum to get a gist of the importance of the decision
针对每个光谱绘制你的决策，以了解决策的重要性
This framework breaks down decision importance into three dimensions:
这个框架将决策重要性分解为三个维度：
- Resource investment from a decision
决策的资源投入 - The overall impact of a positive outcome
积极结果的整体影响 - The impacts of a negative outcome (shown more granularly to help you think it through, but the sub-dimensions could be different for you)
消极结果的影响（显示得更细粒度以帮助你思考，但子维度可能对你不同）
The idea here is to plot a decision along these spectrums in order to determine an overall importance. Let's take a look at three examples.
这里的想法是沿着这些光谱绘制决策，以确定整体重要性。让我们看三个例子。
First, changing a "Sign Up" text-link on the homepage to a button .
首先，将主页上的"注册"文本链接改为按钮。
This is clearly a low importance decision. If you're wrong, it's very easy to undo. The impact of being wrong is limited only to the number of users affected during the period of change. The impact of being right is only incremental.
这显然是一个低重要性决策。如果你错了，很容易撤销。错误的影响仅限于在变更期间受影响的用户数量。正确的影响只是渐进的。
Note, this doesn't mean it's not worth doing, it means the decision to do it or not isn't that important, and as we'll see later that should affect the speed at which we make the decision.
注意，这并不意味着它不值得做，它意味着做或不做的决策不那么重要，正如我们稍后将看到的，这应该影响我们做决策的速度。
Another example: changing your company's logo
另一个例子：改变你公司的标志
This is a medium to high importance decision. It might not take a lot of resources to execute, but the impact (both positive and negative) to the company's brand and customer base is huge. Remember when Uber changed their logo and no one could find the app? Or when AirBnB did and no one could stop seeing genitals?
这是一个中到高重要性的决策。执行可能不需要很多资源，但对公司品牌和客户群的影响（无论是积极的还是消极的）是巨大的。还记得 Uber 改变他们的标志，没人能找到应用吗？或者当 AirBnB 改变时，没人能停止看到生殖器？
One more: a "moonshot" project to open up a new market for the company
再一个：一个"登月"项目 为公司开拓新市场
This particular decision is medium to low importance. It's important in that it will consume material resources, but also not important in that failure has no lasting downside.
这个特定决策是中到低重要性。它很重要，因为它将消耗物质资源，但它也不重要，因为失败没有持久的负面影响。
This is a common decision type for tech companies that have reached scale and are looking for new ways to grow. The high investment + low impact of failure + high impact of success creates a risk/reward ratio that is very attractive to companies that can afford to spend the resources, so much so that they often create dedicated teams to repeatably experiment with these types of projects. Think Facebook's Building 8, or Google's X.
这是已经达到规模并正在寻找新增长方式的科技公司的常见决策类型。高投入 + 失败的低影响 + 成功的高影响创造了一个风险/回报比，这对能够负担得起花费资源的公司非常有吸引力，以至于他们经常创建专门的团队来重复实验这些类型的项目。想想 Facebook 的 Building 8，或 Google 的 X。
This framework, or any variation of it, will create common ground for you to compare decisions and articulate the importance of them to everyone you work with. Tweak it based on your company's context, and recognize that defining decision importance informs everything else about how you should approach making the decision. So do it first.
这个框架，或它的任何变体，将为你创造一个共同的基础来比较决策，并向与你合作的每个人阐明它们的重要性。根据你公司的背景调整它，并认识到定义决策重要性会告知你应该如何接近做出决策的其他一切。所以先做这件事。
Once you decide how important a decision is, you should adjust how long you're willing to spend on it.
一旦你决定一个决策有多重要，你应该调整你愿意花多长时间在它上面。
I have a proposition for you, which is that good decision makers are also the ones who make most of their decisions quickly . To get to that conclusion, we're going to unbundle the following statements:
我有一个提议给你，那就是好的决策者也是那些快速做出大部分决策的人。为了得出这个结论，我们将分解以下陈述：
- The less important a decision, the less information you should try to seek to make it.
决策越不重要，你应该尝试寻求的信息就越少。 - Gathering information follows a Pareto principle, meaning you can get 80% of the information quite easily, but getting the final 20% requires a lot of effort.
收集信息遵循帕累托原则，意味着你可以很容易地获得 80% 的信息，但获得最后 20% 需要大量努力。 - Most decisions are not important
大多数决策都不重要
Let's go through each of them.
让我们逐一过一遍。
1. The less important a decision, the less information you should try to seek to make it.
1. 决策越不重要，你应该尝试寻求的信息就越少。
Products, especially those used by many people, are complex systems where predicting all the ramifications of a decision are practically impossible, even when you have 100% of the available information*.* Since we cannot perfectly predict outcomes, this effectively means that all decisions are bets we are making.
产品，特别是那些被许多人使用的产品，是复杂的系统，即使你有 100% 的可用信息，预测决策的所有后果实际上也是不可能的*。* 既然我们无法完美预测结果，这实际上意味着所有决策都是我们在做的赌注。
We choose to make these bets based our confidence in a positive outcome, and that confidence is based on the amount of information we have. The more information we have as a percentage of all available information about a decision, the higher our confidence level should be.
我们选择基于对积极结果的信心来做这些赌注，而这种信心基于我们拥有的信息量。我们拥有的关于决策的所有可用信息的百分比越高，我们的信心水平就应该越高。
"Information" in this context can be anything relevant to the decision. Using our previous sign-up button example, we could research button patterns from other sites as information to support a positive outcome.
在这个上下文中，"信息"可以是与决策相关的任何东西。使用我们之前的注册按钮例子，我们可以研究其他网站的按钮模式作为支持积极结果的信息。
Here's the key question, though: How much information should one be gathering before they make a decision?
然而，关键问题是：在做决策之前，一个人应该收集多少**信息？
Whether consciously or not, few people gather anywhere near 100% of available information before making a decision. What ends up happening is that at some point, every decision maker subconsciously thinks to themselves "I'm ~70% sure adding this green button will increase conversion.", and then they simply make it.
无论是有意识还是无意识的，很少有人在做出决策之前收集接近 100% 的可用信息。最终发生的是，在某个时刻，每个决策者潜意识地对自己说"我~70% 确定添加这个绿色按钮会增加转化率。"*，*然后他们就简单地做了。
It's that line of thought that reveals two things about how decisions actually get made by an individual: first, they assess their confidence level (70%), and secondly, they define a confidence threshold required to make that decision.
正是这种思路揭示了关于个人实际上如何做出决策的两件事：首先，他们评估自己的信心水平（70%），其次，他们定义做出该决策所需的信心阈值。
That confidence threshold is based on the importance of the decision. You may be willing to add the sign-up button with 60% confidence that it will create a positive outcome, but you wouldn't change the company's logo with only 60% confidence. The latter is a more important decision, and therefore the bar for confidence should be higher.
那个信心阈值基于决策的重要性。 你可能愿意以 60% 的信心添加注册按钮，相信它会产生积极结果，但你不会以只有 60% 的信心改变公司的标志。后者是一个更重要的决策，因此信心的门槛应该更高。
To summarize:
总结：
- your confidence level on predicting a decision's outcome is a function of how much information you have about the decision
你对预测决策结果的信心水平是你拥有关于该决策的信息量的函数 - the more important a decision, the higher confidence you require and thus the more information you need
决策越重要，你需要的信心越高，因此你需要的信息越多
We can visualize these points in the model below:
我们可以在下面的模型中可视化这些点：
This reveals something counterintuitive about decision making: your goal shouldn't be to always make the right decision, it should be to invest the right amount of time in a making a decision relative to its importance.
这揭示了关于决策的一些反直觉的东西：你的目标不应该是总是做出正确的决策，而应该是投入适当的时间来做出与决策重要性相关的决策。
The ramifications of subscribing to this are two-fold. The downside is that you will end up making more wrong decisions, but when you do, they're likely not important. The upside is that you will end up making more decisions, which as a PM means you're creating more output .
接受这一点的后果是双重的。 downside 是你会做出更多错误 的决策，但当你这样做时，它们可能并不重要。 upside 是你会做出更多 决策，作为产品经理这意味着你创造了更多产出。
How much more? That's what the next section is about.
多多少？这就是下一节的内容。
2. Information gathering effort follows the Pareto principle
2. 信息收集努力遵循帕累托原则
What's the difference in effort required for gathering 35% of information versus 70%? It's not 2x --- most of the time you will already have a significant amount of the relevant information close by: data about past user behaviour, previous research studies, previous attempts by the company, etc.
收集 35% 信息与 70% 信息所需的努力有什么区别？不是 2 倍------大多数时候你已经有了大量相关的信息在手边：关于过去用户行为的数据、以前的研究、公司以前的尝试等。
The Pareto principle applies here in that you can usually get ~80% of the information you need with little investment, whereas getting 100% will take a lot of effort.
帕累托原则在这里适用，你通常可以用很少的投资获得~80% 你需要的信息，而获得 100% 需要大量努力。
Say you're a PM at Facebook and you're deciding whether or not to get into the peer to peer buying/selling space. As evidenced by Craiglist, Letgo, and others, you know the opportunity is big so you start exploring the need for such a feature on Facebook.
假设你是 Facebook 的产品经理，你正在决定是否进入点对点买卖领域。正如 Craiglist、Letgo 等所证明的，你知道机会很大，所以你开始探索 Facebook 上对这种功能的需求。
You assess the importance, and come up with "medium important" because of the resource investment and the potential legal risks of facilitating transactions and commerce on Facebook.
你评估重要性，并得出"中等重要"的结论，因为资源投资以及在 Facebook 上促进交易和商业的潜在法律风险。
What information would you gather to make this decision?
你会收集什么信息来做出这个决策？
Well, probably the first place you'd look is the existing user behaviour within Facebook Groups. Are communities of people already doing this without having specific features for it? You can probably analyze the names of groups and the content being posted to them in order to identify how many users are already buying/selling.
嗯，可能你首先会看的是 Facebook 群组内的现有用户行为。人们社区是否已经在没有特定功能的情况下这样做？你可能可以分析群组名称和发布到它们的内容，以识别有多少用户已经在买卖。
By looking at the posts made in the groups, you can also probably figure out what is being sold, the composition of pictures being used, and how a transaction is happening even though there's no payment features. To address the legal risk, you can also work with your legal team to research the implications to the company. All this information is readily available.
通过查看群组中发布的帖子，你可能还能弄清楚正在卖什么，使用的图片构成，以及即使没有支付功能交易是如何发生的。为了解决法律风险，你还可以与你的法律团队合作研究对公司的影响。所有这些信息都是现成的。
What you probably won't be able to figure out so easily is: why are people choosing to use Facebook for this instead of the established marketplaces? To find that out you'll likely need to do more qualitative research directly with users, which is going to take a lot of time.
你可能不那么容易弄清楚的是：为什么人们选择使用 Facebook 来做这个，而不是使用已建立的市场？要找出这一点，你可能需要直接与用户进行更多的定性研究，这将需要大量时间。
Do you need to? Is it worth the extra time?
你需要吗？值得额外的时间吗？
Probably not. The readily available information provides ~80% of the context for figuring out if people want the feature and if the company can stomach the legal impact. Although knowing why they're using Facebook for buying/selling will be important knowledge for designing the feature, it's not really needed to decide whether or not to do it in the first place.
可能不需要。现成的信息提供了~80% 的背景，用于弄清楚人们是否想要这个功能以及公司是否能承受法律影响。虽然知道他们为什么使用 Facebook 进行买卖对于设计该功能将是重要的知识，但它并不是真正需要用来决定首先是否要做这件事的。
Generalizing this into a model, we can say that the time (effort) to gather information for decisions follows the Pareto principle:
将其概括为一个模型，我们可以说，为决策收集信息的时间（努力）遵循帕累托原则：
Notice this curve is exactly the same as we showed in the previous section when we showed that the amount of information you need is based on the importance of the decision.
注意这条曲线与我们在上一节中展示的完全相同，当时我们展示你需要的信息量基于决策的重要性。
Merging these two curves together, we can actually model the appropriate speed of making a decision as a function of the importance.
将这两条曲线合并在一起，我们实际上可以将做出决策的适当速度建模为重要性的函数。
The combination of these models reveal something important. The speed of your decision making not linearly correlated to how important you think a decision is, it's exponentially correlated. Incorrectly assessing a low importance decision as high means you waste a significant amount of time gathering excess information.
这些模型的组合揭示了一些重要的东西。你做决策的速度与你认为决策有多重要不是线性相关的，而是指数级相关的。错误地将低重要性决策评估为高意味着你浪费大量时间收集多余的信息。
3. Most decisions are not important
3. 大多数决策都不重要
The model below shows that decision importance follows an inverse power law, where the vast majority of decisions are not important.
下面的模型显示，决策重要性遵循逆幂律，绝大多数决策都不重要。
To save your time, I'm just going to assert that this model is directionally, intuitively, true.
为了节省你的时间，我只是断言这个模型在方向上是直观的、真实的。
We make decisions all day working at product companies --- they are not all be of equal importance, and frankly most are trivial. Should we use the oxford comma, or not? Should we roll out to 5% of users, or 10%? Lunch meeting, or eat fast and meet up in 15?
我们在产品公司整天做决策------它们并非都同等重要，坦率地说，大多数都是微不足道的。我们应该使用牛津逗号吗，还是不使用？我们应该向 5% 的用户推出，还是 10%？午餐会议，还是吃得快一点 15 分钟后见面？
Bringing it all home
总结
Let's review our three statements and the conclusion they form:
让我们回顾我们的三个陈述以及它们形成的结论：
- The less important a decision, the less information you should try to seek to make it.
决策越不重要，你应该尝试寻求的信息就越少。 - Effort in gathering information follows a Pareto principle. Getting 100% of information is exponentially harder than getting 80%.
收集信息的努力遵循帕累托原则。获得 100% 的信息比获得 80% 指数级更难。 - Most decisions are not important
大多数决策都不重要
Therefore, the vast majority of decisions should be made quickly. Overlaying the last two models we covered illustrates this clearly.
因此，绝大多数决策应该快速做出。 覆盖我们涵盖的最后两个模型清楚地说明了这一点。
Good decision makers, are quick decision makers.
好的 决策者，是快速的决策者。
Be a great decision maker
成为一个伟大的决策者
Applying these principles and frameworks are incredibly tough in practice. No one likes to be wrong, and as a PM being wrong is very public and can feel career damaging.
在实践中应用这些原则和框架是非常困难的。没有人喜欢犯错，作为产品经理，犯错是非常公开的，可能会感觉对职业生涯有害。
Understanding that decisions are your output as a PM can help you suppress your fears and focus on impact. If you packed boxes for a living, you wouldn't think packing 3/hr flawlessly is better than 100/hour with a 2% failure rate. So why think that way about your output?
理解决策是你作为产品经理的产出可以帮助你抑制恐惧并专注于影响。如果你以打包箱子为生，你不会认为每小时完美打包 3 个比每小时 100 个、2% 失败率更好。那么为什么对你的产出这样想呢？
If you manage PMs, recognize that PMs that are uber careful and always right usually aren't the ones who are driving the most impact. Impact is driven by those who are driving lots of decisions quickly, and are right when it's really important to be.
如果你管理产品经理，要认识到那些极其谨慎且总是正确的产品经理通常不是那些产生最大影响的人。影响是由那些快速推动大量决策的人驱动的，而且在真正重要的时候他们是正确的。
The sign up button decision should be made fast, almost real time.
注册按钮决策应该快速做出，几乎是实时的。
The Facebook buy/sell marketplace decision needs some time to think through, but it's not the end of the world if you're wrong.
Facebook 买卖市场决策需要一些时间来思考，但如果你错了，也不是世界末日。
You should take your time with the logo decision.
你应该花时间做标志决策。
reference
- MVPM: Minimum Viable Product Manager | by Brandon Chu | 2016
https://blackboxofpm.com/mvpm-minimum-viable-product-manager-e1aeb8dd421 - Applying Leverage as a Product Manager | by Brandon Chu | 2016
https://blackboxofpm.com/applying-leverage-as-a-product-manager-ffad4a99db24 - Ruthless Prioritization. All high functioning teams must... | by Brandon Chu | 2017
https://blackboxofpm.com/ruthless-prioritization-e4256e3520a9 - Making Good Decisions as a Product Manager | by Brandon Chu | 2017
https://blackboxofpm.com/making-good-decisions-as-a-product-manager-c66ddacc9e2b