注：本文为 "产品管理思维模型" 相关合辑。
英文引文，机翻未校。
图片清晰度受引文原图所限。
如有内容异常，请看原文。
Product Management Mental Models for Everyone
面向所有人的产品管理思维模型
Brandon Chu
Aug 20, 2018
Mental models are simple expressions of complex processes or relationships. These models are accumulated over time by an individual and used to make faster and better decisions.
思维模型是对复杂过程或关系的简洁表达。这些模型由个人随时间积累而成，用于做出更快、更好的决策。
Here's an example:the Pareto Principle states that roughly 80% of all outputs comes from 20% of the effort.
举个例子：帕累托原则（Pareto Principle）指出，大约 80% 的产出来自 20% 的努力。
In the context of product management, the model suggests that instead of trying to create 100% of the customer opportunity, you may want to look for how to do 20% of the effort and solve 80% of the opportunity. Product teams make this trade off all the time, and the results often looks like feature launches where 20% of customers with more complicated use cases aren't supported.
在产品管理的语境下，该模型表明，与其试图创造 100% 的客户机会，不如寻找如何用 20% 的努力解决 80% 的机会。产品团队一直在做这种权衡，结果往往表现为功能发布时，20% 具有更复杂用例的客户得不到支持。
Mental models are powerful, but their utility is limited to the contexts they were extrapolated from. To combat this, you shouldn't rely on one or even a few mental models, you should instead be continuously building alatticework of mental models that you can draw from to make better decisions.
思维模型很强大，但其效用仅限于它们被推演出来的特定情境。为了应对这一点，你不应依赖一个甚至少数几个思维模型，而应该持续构建一个思维模型的格子框架（latticework），从中汲取养分以做出更好的决策。
This concept was popularized by Charlie Munger, the famed Berkshire Hathaway vice chairman, in a speech where he reflected on how to gain wisdom:
这一概念由著名的伯克希尔·哈撒韦公司副董事长查理·芒格在一次演讲中推广开来，他在演讲中反思了如何获得智慧：
What is elementary, worldly wisdom? Well, the first rule is that you can't really know anything if you just remember isolated facts and try and bang 'em back. If the facts don't hang together on a latticework of theory, you don't have them in a usable form.
什么是基本的、世俗的智慧？嗯，第一条规则是，如果你只是记住孤立的事实并试图硬塞回去，你就不可能真正知道任何事情。如果事实不能在一个理论的格子框架上相互关联，你就无法以可用的形式掌握它们。
You've got to have models in your head. And you've got to array your experience --- both vicarious and direct --- on this latticework of models. You may have noticed students who just try to remember and pound back what is remembered. Well, they fail in school and in life. You've got to hang experience on a latticework of models in your head.
你必须在头脑中有模型。你必须将你的经验------无论是间接的还是直接的------排列在这个模型格子框架上。你可能注意到有些学生只是试图记住并硬背所记的内容。嗯，他们在学校和生活中都会失败。你必须将经验悬挂在头脑中的模型格子框架上。
What are the models? Well, the first rule is that you've got to have multiple models --- because if you just have one or two that you're using, the nature of human心理学 is such that you'll torture reality so that it fits your models, or at least you'll think it does. You become the equivalent of a chiropractor who, of course, is the great boob in medicine.
这些模型是什么？嗯，第一条规则是你必须有多个模型------因为如果你只使用一两个模型，人类心理学的本质会让你扭曲现实以适应你的模型，或者至少你会认为现实确实符合模型。你就变成了相当于脊椎按摩师的人，而脊椎按摩师当然是医学界的笑柄。
It's like the old saying, "To the man with only a hammer, every problem looks like a nail." And of course, that's the way the chiropractor goes about practicing medicine. But that's a perfectly disastrous way to think and a perfectly disastrous way to operate in the world. So you've got to have multiple models.
就像那句老话说的："对于一个只有锤子的人来说，每个问题看起来都像钉子。"当然，这就是脊椎按摩师行医的方式。但这是一种完全灾难性的思维方式，也是在世界上运作的完全灾难性的方式。所以你必须有多个模型。
This post outlines some of the most useful mental models that I've accumulated in my career in Product Management. As I learn new models, I'll continually update the post.
本文概述了我在产品管理职业生涯中积累的一些最有用的思维模型。随着我学到新的模型，我将持续更新这篇文章。
This is alsonot a post for just product managers, it's for everyone that works on products. Product thinking is not sacred to the role of a PM, in fact, it's evenmore useful in the hands of the builders than PMs.
这也不是 一篇只写给产品经理的文章，而是写给所有从事产品工作的人的。产品思维并非产品经理角色的专属圣物，事实上，它在构建者手中甚至比在 PM 手中更有用。
The mental models we'll cover are structured into the following categories:
我们将涵盖的思维模型按以下类别组织：
-
Figuring out Where to Invest
确定投资方向
-
Designing and Scoping
设计与范围界定
-
Shipping and Iterating
发布与迭代
Figuring out Where to Invest --- the next set of mental models are useful for deciding what your team should build, or "invest in", next.
确定投资方向------下一组思维模型有助于决定你的团队接下来应该构建什么，或"投资于"什么。
1. Return on Investment
1. 投资回报率（Return on Investment）
A finance concept: for every dollar you invest, how much are you getting back? In product, think of the resources you have (time, money, people) as what you're "investing", and the return as impact to customers.
一个金融概念：你每投资一美元，能收回多少？在产品领域，将你拥有的资源（时间、金钱、人员）视为你的"投资"，将回报视为对客户的影响。
How it's useful
如何应用
The resources available to a product team are time, money, and [the number and skill of] people. When you're comparing possible projects you could take on, you should always choose the one thatmaximizes impact to customers for every unit of resources you have.
产品团队可用的资源是时间、金钱和[人员的数量与技能]。当你比较可能承担的项目时，你应该始终选择那个最大化每单位资源对客户影响的项目。
2. Time value of shipping
2. 发布的时间价值
Product shipped earlier is worth more to customers than product shipped at a later time.
更早发布的产品对客户而言比稍后发布的产品更有价值。
How it's useful
如何应用
When deciding between problems/opportunities to invest in, you can't just compare the benefits of different features you could build (if you did, you would always choose the biggest feature).
在决定投资于哪些问题/机会时，你不能只比较你可以构建的不同功能的好处（如果你这样做，你总会选择最大的功能）。
Instead, to make good investment decisions, you also have to consider how quickly those features will ship, and place more value on features that will ship faster.
相反，为了做出良好的投资决策，你还必须考虑这些功能多快能发布，并对更快发布的功能赋予更高价值。
3. Time Horizon
3. 时间范围（Time Horizon）
Related to theTime Value of Shipping, the right investment decision changes based on the time period you are optimizing for.
与发布的时间价值相关，正确的投资决策会根据你优化的时间周期而变化。
Given a long enough time horizon, the cost of a 3 month vs. 9 month build is insignificant.
给定足够长的时间范围，3 个月与 9 个月构建的成本差异微不足道。
How it's useful
如何应用
Choosing to ask*"How can we create the most impact in the next 3 months?"* or*"How can we create the most impact in the next 3 years?"* will result in dramatically different decisions for your team.
选择问*"我们如何在接下来的 3 个月内创造最大影响？"或"我们如何在接下来的 3 年内创造最大影响？"*将为你的团队带来截然不同的决策。
It follows then that aligning with your team and利益相关者 about what time horizon to optimize for is often the first discussion to have.
因此，与团队和利益相关者就优化哪个时间范围达成一致，往往是要进行的第一个讨论。
4. Expected Value
4. 期望值（Expected Value）
Predicting the future is imperfect. Instead, all decisions create probabilities of multiple future outcomes. The probability-weighted sum of these outcomes is theexpected value of a decision.
预测未来是不完美的。相反，所有决策都会产生多种未来结果的概率。这些结果的概率加权总和就是该决策的期望值。
How it's useful
如何应用
When considering impact of a project, map out all possible outcomes and assign probabilities. Outcome variability typically includes the probability it takes longer than expected and the probability that it fails to solve the customer problem.
在考虑项目影响时，列出所有可能的结果并分配概率。结果的可变性通常包括耗时超过预期的概率以及未能解决客户问题的概率。
Once you lay out all the outcomes, do a probability-weighted sum of the value of the outcomes and you'll have a better picture on the return you will get on the investment.
一旦你列出了所有结果，对结果的价值进行概率加权求和，你就能更清楚地了解你将获得的投资回报。
Designing and Scoping ---the next set of mental models are useful for scoping and designing a product after you've chosen where to invest.
设计与范围界定------下一组思维模型有助于在你选定投资方向后，界定范围并设计产品。
5. Working Backwards (Inversion)
5. 逆向工作（Working Backwards / Inversion）
Instead of starting at a problem and then exploring towards a solution, start at a perfect solution and work backwards to today in order to figure out where to start.
不要从问题出发然后探索解决方案，而是从一个完美的解决方案出发，逆向工作回到今天，以确定从哪里开始。
Note that working backwards isn't universally better, it just creates a different perspective.
注意，逆向工作并非普遍更好，它只是创造了一种不同的视角。
How it's useful
如何应用
Most teams tend towork**forwards, which optimizes for what is practical at the cost of what's ultimately impactful.
大多数团队倾向于正向工作，这以牺牲最终影响力为代价来优化实用性。
Working backwards helps you ensure that you focus on the most impactful, long term work for the customer because you're always reverse-engineering from a perfect solution for them.
逆向工作有助于确保你专注于对客户最具影响力、最长期的工作，因为你始终在为他们的完美解决方案进行逆向工程。
Note that working backwards isn't universally better, it just creates a different perspective. It's healthy to plan using both perspectives.
注意，逆向工作并非普遍更好，它只是创造了一种不同的视角。用两种视角进行规划是健康的。
6. Confidence determines Speed vs. Quality
6. 信心决定速度 vs. 质量
The confidence you have in i) the importance of the problem your solving, and ii) the correctness of the solution you're building, should determine how much you're willing to trade off speed and quality in a product build.
你对以下两点的信心：i）你解决的问题的重要性，ii）你构建的解决方案的正确性，应该决定你在产品构建中愿意在速度和质量之间进行多少权衡。
How it's useful
如何应用
This mental model helps you to build a barometer to smartly trade off speed and quality. It's easiest to explain this by looking at the extreme ends of the spectrum above.
这个思维模型帮助你建立一个晴雨表，以明智地权衡速度和质量。通过观察上述光谱的两端最容易解释这一点。
On the right side : you have confidence (validated through customers) that the problem you're focused on is really important to customers,and you know exactly what to build to solve it. In that case, you shouldn't take any shortcuts because you know customers will need this important feature forever, so it better be really high quality (e.g. scalable, delightful).
右侧 ：你有信心（通过客户验证）你专注于的问题对客户确实非常重要，而且你确切知道该构建什么来解决它。在这种情况下，你不应该走任何捷径，因为你知道客户将永远需要这个重要功能，所以它最好具有非常高的质量（例如可扩展、令人愉悦）。
Now let's look at the left side : you haven't even validated that the problem is important to customers. In this scenario, the longer you invest in building, the more you risk creating something for a problem that doesn't even exist. Therefore, you should err on launching somethingfast and getting customer validation that it's worth actually building out well. For example, these are the types of situations where you may put up a landing page for a feature that doesn't even exist to gauge customer interest.
现在看左侧 ：你甚至还没有验证这个问题对客户是否重要。在这种情况下，你投入构建的时间越长，你为一个甚至不存在的问题创造东西的风险就越大。因此，你应该倾向于快速发布某样东西，并获得客户验证，确认它值得真正好好构建。例如，在这些情况下，你可能会为一个甚至不存在的功能建立一个落地页，以衡量客户兴趣。
7. Solve the Whole Customer Experience
7. 解决完整的客户体验
Customer experiences don't end at the interface. What happens before and after using the product are just as important to design for.
客户体验不会在界面处结束。使用产品之前和之后发生的事情同样重要，需要设计。
How it's useful
如何应用
When designing a product, we tend to over focus on the in-product experience (e.g. the user interface, in software).
在设计产品时，我们倾向于过度关注产品内的体验（例如软件中的用户界面）。
It's just as important to design the marketing experience (how you acquire customers and set their expectations for the product before they use it), and the support/distress experience (how your company handles the product failing).
设计营销体验（如何获取客户并在他们使用产品前设定对产品的期望）以及支持/困境体验（你的公司如何处理产品故障）同样重要。
Creating great distress experiences, in particular, are amazing opportunities to earn long term customer trust. For example, Amazon earns the most trust from you as a customerwhen you have to return something.
特别是，创造出色的困境体验是赢得长期客户信任的绝佳机会。例如，亚马逊在你作为客户不得不退货时赢得你最多的信任。
8. Experiment, Feature, Platform
8. 实验、功能、平台
There are three types of product development: Experiments, Features, and Platforms. Each have their own goal and optimal way to trade-off speed and quality.
有三种类型的产品开发：实验、功能和平台。每种都有自己的目标以及权衡速度和质量的最佳方式。
How it's useful
如何应用
By recognizing the type of product development your project is, you will define more appropriate goals for each type, and you will right-size the speed and quality trade off that you make.
通过识别你的项目属于哪种产品开发类型，你将为每种类型定义更合适的目标，并适当调整你所做的速度和质量权衡。
Experiments are meant to outputlearning , so that you can invest in new features or platforms with customer validation. If you optimize for learning, you will consider doing things that otherwise wouldn't be palatable: for example using hacky code that you intend to throw away, and faking sophisticated software when it's just humans doing it behind the scenes.
实验旨在输出学习成果，以便你可以在客户验证的基础上投资于新功能或平台。如果你为学习而优化，你会考虑做那些在别的情况下可能难以接受的事情：例如使用你打算丢弃的临时代码，以及在只是人类在幕后操作时假装复杂的软件。
In contrast to experiments, platforms are forever. Other people will build features on top of them, and as such making changes to the platform after it's live is extremely disruptive.
与实验相反，平台是永恒的。其他人将在其之上构建功能，因此平台上线后对其进行更改极具破坏性。
Therefore, platform projects need to be very high quality (stability, performance, scalability, etc.) and they need to actually enable useful features to be built. A good rule of thumb when building platform is to build it with your first consumer, i.e. have another team simultaneously building a feature on your platform while you're developing it --- this way, you guarantee the platform actually enables useful features.
因此，平台项目需要非常高的质量（稳定性、性能、可扩展性等），并且它们需要真正能够支持构建有用的功能。构建平台时的一个好经验法则是与第一个消费者一起构建它，即在你开发平台的同时让另一个团队在你的平台上构建功能------这样，你就能保证平台真正能够支持有用的功能。
9. Feedback Loops
9. 反馈循环（Feedback Loops）
Cause and effect in products are the result of systems connected by positive and negative feedback loops.
产品中的因果关系是由正反馈循环和负反馈循环连接的系统所产生的结果。
How it's useful
如何应用
Feedback loops help us remember that some of the biggest drivers of growth or decline for a product may be from other parts of the system.
反馈循环帮助我们记住，产品增长或下滑的一些最大驱动因素可能来自系统的其他部分。
For example, say you're the payments team and your KPI is to grow total credit card payments processed. You have a positive feedback loop with the user acquisition team because as they grow users, you have more potential users that will pay with credit cards. However, you have a negative feedback loop with the cash payments team, who are trying to help users more easily to transact through cash.
例如，假设你是支付团队，你的 KPI 是增长处理的信用卡支付总量。你与用户获取团队有正反馈循环，因为随着他们增长用户，你有更多潜在用户将使用信用卡支付。然而，你与现金支付团队有负反馈循环，他们正试图帮助用户更轻松地通过现金交易。
Knowing these feedback loops can help you change strategy (e.g. you may choose to work on general user acquisition as the best way to grow payment volume), or understand negative changes in your metrics (e.g. credit card payment volume is down, but it's because the cash payments team is doing really well, not because the credit card products suck).
了解这些反馈循环可以帮助你改变策略（例如，你可以选择致力于一般用户获取作为增长支付量的最佳方式），或理解指标中的负面变化（例如，信用卡支付量下降，但这是因为现金支付团队做得很好，而不是因为信用卡产品糟糕）。
10. Flywheel (recursive feedback loop)
10. 飞轮（递归反馈循环）
A state where a positive or negative feedback loop is feeding on itself and accelerating from it's own momentum.
一种状态，其中正反馈循环或负反馈循环自我滋养，并因其自身动量而加速。
How it's useful
如何应用
Flywheels are a related concept to feedback loops, but are important for managing platforms and marketplaces. For example, imagine you run Apple's iOS app platform. You have two users: app developers, and app users.
飞轮是与反馈循环相关的概念，但对管理平台和市场非常重要。例如，假设你运营苹果的 iOS 应用平台。你有两类用户：应用开发者和应用用户。
The flywheel is the phenomenon where more app users吸引 more app developers (because there is more opportunity to sell), which in turn attract more app users (because there are more apps to buy), which in turn attract more app developers, and so on. As long as you nurture the flywheel, not only will you grow, but you'll grow at an accelerating rate.
飞轮是这样的现象：更多的应用用户吸引更多的应用开发者（因为有更多的销售机会），这反过来吸引更多的应用用户（因为有更多的应用可购买），这反过来吸引更多的应用开发者，如此循环。只要你培育飞轮，你不仅会增长，而且会以加速的速率增长。
If you're managing a flywheel, you have to do everything you can to keep it spinning in the positive direction, because it's just as powerful the other way. For example, if there are so many apps on the platform that new apps can't get discovered anymore, app developer growth will slow and break the flywheel --- you need to solve that.
如果你在管理一个飞轮，你必须尽一切努力让它保持向正方向旋转，因为它反向旋转时同样强大。例如，如果平台上有太多应用以至于新应用无法被发现，应用开发者增长将放缓并打破飞轮------你需要解决这个问题。
Building & Iterating ---the next set of mental models are useful for when you're building, operating, and iterating an existing product.
构建与迭代------下一组思维模型适用于你构建、运营和迭代现有产品时。
11. Diminishing Returns
11. 收益递减（Diminishing Returns）
When you focus on improving the same product area, the amount of customer value created over time will diminish for every unit of effort.
当你专注于改进同一产品领域时，每单位努力随时间创造的客户价值将会减少。
How it's useful
如何应用
Assuming you are effectively iterating the product based on customer feedback and research, you will eventually hit a point where there's just not that much you can do to make it better. It's time for your team to move on and invest in something new.
假设你正在基于客户反馈和研究有效地迭代产品，你最终会达到一个点，在那里你能做的让它变得更好的事情已经不多了。是时候让你的团队转向并投资于新事物了。
12. Local Maxima
12. 局部最大值（Local Maxima）
Related todiminishing returns , the local maxima is the point where incremental improvements creates no customer value at all, forcing you to make a step change in product capabilities.
与收益递减相关，局部最大值是增量改进完全无法创造客户价值的点，迫使你在产品能力上做出阶跃式改变。
How it's useful
如何应用
This mental model is tightly related to diminishing returns, with the addition of hitting a limit where it literally makes no material difference to keep improving something.Iteration now serves no purpose, and and the only way to progress is toinnovate.
这个思维模型与收益递减紧密相关，增加了一个限制，即达到继续改进某样东西实际上不会产生实质性影响的极限。迭代 现在已无意义，进步的唯一方式是创新。
This concept was recently popularized by Eugene Wei's viral post Invisible Asymptotes, which covers an example like this that Amazon foresaw which led them to create Prime.
这个概念最近因 Eugene Wei 的病毒式传播文章《Invisible Asymptotes》而流行，该文涵盖了亚马逊预见到的类似例子，这促使他们创建了 Prime 会员服务。
13. Version two is a lie
13. 第二版是谎言
When building a product, don't bank on a second version ever shipping. Make sure the first version is a complete product because it may be out there forever.
构建产品时，不要指望第二版会发布。确保第一版是一个完整的产品，因为它可能会永远存在。
When software was sold on shelves, teams had to live with version 1 forever.
当软件在货架上销售时，团队不得不永远与第 1 版共存。
How it's useful
如何应用
When you're defining the first version of your product, you will accumulate all sorts of amazing features that you dream of adding on later in future versions. Recognize that these may never ship, because you never know what can happen: company strategy changes, your lead engineer quits, or the whole team gets reallocated to other projects.
当你定义产品的第一版时，你会积累各种你希望在未来版本中添加的惊人功能。认识到这些可能永远不会发布，因为你永远不知道会发生什么：公司战略变化、你的首席工程师离职，或整个团队被重新分配给其他项目。
To hedge against these scenarios, make sure that whatever you ship is a "complete product" which, if it was never improved again, would still be useful to customers for the foreseeable future. Don't ship a feature that relies on future improvements in order to actually solve the problem well.
为了对冲这些场景，确保你发布的任何东西都是一个"完整的产品"，如果它再也不被改进，在可预见的未来对客户仍然有用。不要发布一个依赖未来改进才能真正解决问题的功能。
14. Freeroll
14. 免费博弈（Freeroll）
A situation where there is little to lose and lots to gain by shipping something fast.
一种情况，快速发布某样东西几乎没有损失，但有很多收获。
How it's useful
如何应用
Freerolls typically emerge in product when the current user experience is so bad that by making any reasonable change based on intuition is likely to make it much better. They are different than fixing bugs because bugs refer to something that's not working as designed.
免费博弈通常在产品的当前用户体验如此糟糕时出现，以至于基于直觉做出任何合理的改变都可能让它变得更好。它们与修复错误不同，因为错误指的是未按设计工作的东西。
If you're in a situation where your team is thinking,"Let's just do something... we can't really make it any worse" , you likely have a freeroll in front of you.
如果你处于团队在想 "我们就做点什么吧......我们不可能让它变得更糟" 的情况，你面前很可能就有一个免费博弈。
(r/CrappyDesign on Reddit is a treasure trove of such situations)
（Reddit 上的 r/CrappyDesign 是这类情况的宝库）
15. Most value is created after version one
15. 大部分价值在第一版之后创造
You will learn the most about the customer after you launch the product, don't waste the opportunity to build on those learnings.
你在发布产品后将学到最多关于客户的知识，不要浪费基于这些认知进行构建的机会。
How it's useful
如何应用
Everything is a hypothesis until customers are using the product at scale. While what your team invests in "pre-launch learning" --- the customer interviews, prototype testing, quantitative analysis, beta testing, etc. --- can give you a massive leg up on the probability of being right, there are always behaviours and edge cases that emerge once you ship the feature to 100% of customers.
在客户大规模使用产品之前，一切都是假设。虽然你的团队在"发布前学习"中投入的内容------客户访谈、原型测试、定量分析、Beta 测试等------可以大大提高正确的概率，但一旦你向 100% 的客户发布功能，总会有行为和边缘情况出现。
As a percentage of customer insight learned, you will gain the majority of learningafter launch. To not investing accordingly by iterating the product (sometimes drastically), doesn't make sense with that in mind.
作为所学客户洞察的百分比，你将在发布之后获得大部分学习成果。考虑到这一点，不通过迭代产品（有时是大幅度地）进行相应投资是不合理的。
16. Key Failure Indicator (KFI)
16. 关键失败指标（Key Failure Indicator, KFI）
Pairing your Key Performance Indicators (KPIs) with metrics youdon't want to see go in a certain direction, to ensure you're focused on healthy growth.
将你的关键绩效指标（KPIs）与你不希望看到向某个方向发展的指标配对，以确保你专注于健康的增长。
How it's useful
如何应用
Teams often choose KPIs that directly reflect the positive outcomes they're looking for, without considering the negative ways that those outcomes could be achieved. Once they start optimizing for those KPIs, they actually create output that is net bad for the company.
团队经常选择直接反映他们所寻求的积极结果的 KPI，而不考虑实现这些结果的负面方式。一旦他们开始为这些 KPI 进行优化，他们实际上创造的产出对公司而言是净负面的。
A classic example is a team thinking they're successful when doubling sign-up conversion on the landing page, only to observe (far too late) that the number of total customers isn't growing because the conversion rate dropped by 60% due to the same change.
一个经典例子是，一个团队认为他们在落地页上将注册转化率翻倍时是成功的，结果（太晚地）观察到总客户数没有增长，因为同一变化导致转化率下降了 60%。
KFIs keep your team's performance in check, and make sure that you only create net-healthy outputs for the company.
KFI 让你的团队绩效受到约束，并确保你只为公司创造净健康的产出。
Examples of popular KPI <> KFI pairings are :
流行的 KPI <> KFI 配对示例：
-
Grow revenue while maintaining gross margin
增长收入，同时保持毛利率
-
Grow adoption of feature A without taking away adoption of feature B
增长功能 A 的采用率，而不减少功能 B 的采用率
-
Grow adoption of feature A without increasing support load
增长功能 A 的采用率，而不增加支持负载
A latticework, not a checklist
格子框架，而非清单
It may be unsatisfactory to many readers, but as far as I can tell there is no methodology for using these mental models. If you try and use them as a checklist --- going through each and seeing if they apply them --- you will end up doing to mental gymnastics that will confuse and frustrate you and those around you.
对许多读者来说这可能不尽如人意，但据我所知，使用这些思维模型并没有方法论。如果你试图将它们作为清单使用------逐一检查并看它们是否适用------你最终会进行让你自己和周围人困惑和沮丧的心智体操。
Instead, they simply become part of your latticework, helping you make better decisions about product, and giving you the language to communicate the why behind complex decisions to your team.
相反，它们只是成为你格子框架的一部分，帮助你做出更好的产品决策，并为你提供向团队传达复杂决策背后原因的语言。
As you accumulate more models, ideally through experience, the better you will get.
随着你积累更多模型，最好是通过经验，你会变得越好。
The First Principles of Product Management
产品管理的第一性原理
Brandon Chu
Jan 7, 2018
Some of the best PMs I know make their decisions based on first principles. A first principle is a "basic, foundational proposition or assumption that cannot be deduced from any other proposition or assumption.".
我所认识的许多优秀产品经理都基于第一性原理来做决策。第一性原理是指 "一个基本的、基础性的命题或假设，它不能从任何其他命题或假设中推导出来"。
An example of one that we use for our developer platform team are that "all platform features should be like Lego blocks" , meaning that developers should be able to use any combination of features when building an app. Features should be interoperable, just like Legos.
我们为开发者平台团队使用的一个例子是 "所有平台功能都应该像乐高积木一样"，这意味着开发者在构建应用时应该能够使用任意组合的功能。功能之间应该像乐高一样可互操作。
First principle thinking helps PMs because as companies scale, communicating the rationale behind historical, current, and future decisions can be simplified in a way that their team and stakeholders can rally around. This enables people around the PM to move quickly in the same direction, decouple, and make smart trade offs without their presence.
第一性原理思维对产品经理有帮助，因为随着公司规模扩大，沟通历史、当前和未来决策背后的理由可以被简化，使得团队和利益相关者能够围绕这些理由团结起来。这使得产品经理周围的人能够在同一方向上快速行动、解耦，并在没有产品经理在场的情况下做出明智的权衡。
What about first principles for the craft of Product Management?
那么产品管理这门技艺的第一性原理呢？
If first principles can help a PM align their team around what's most important in a product, I believe they can also serve PMs in thinking about the craft of product management itself.
如果第一性原理能够帮助产品经理让团队围绕产品中最重要的东西保持一致，我相信它们也可以帮助产品经理思考产品管理这门技艺本身。
That's what this post is about: what are the foundational propositions and assumptions of product management that cannot be deduced?
这就是这篇文章的主题：产品管理中那些无法被推导的基础性命题和假设是什么？
Left Side, Right Side
左脑，右脑
The first principles of Product Management can be reduced to:
产品管理的第一性原理可以归结为：
A. Maximize impact to the mission: develop a product strategy that maximizes the impact to an organization's mission given a set of inputs.
A. 最大化对使命的影响： 在给定一组输入的情况下，制定能够最大化对组织使命影响的产品战略。
B. Accomplish everything through others: PMs do not directly build or operate the product, instead they enable those around them to do it better.
B. 通过他人完成一切： 产品经理不直接构建或运营产品，而是使周围的人能够更好地完成这些工作。
These two principles represent the left and right sides of your brain. The left is defined by logic, research, and rigour. The right is defined by creativity, intuition, and empathy.
这两个原理代表了你大脑的左右两侧。左侧由逻辑、研究和严谨定义。右侧由创造力、直觉和同理心定义。
Great product managers fuse these two principles into all their decisions and everything they do should derive from them.
优秀的产品经理将这两个原理融合到他们的所有决策中，他们所做的一切都应该源于这些原理。
In retrospect, most of my previous posts are simply derivatives of these two principles. Making Good Decisions as a PM is about principle A, Ruthless Prioritization and Applying Leverage as a PM were about principle B. MVPM is a bit of both. I wish I had written this first, but frankly I needed to learn it. Let's dig in.
回顾过去，我之前的文章大多只是这两个原理的衍生。Making Good Decisions as a PM 是关于原理 A 的，Ruthless Prioritization 和 Applying Leverage as a PM 是关于原理 B 的。MVPM 则两者兼而有之。我真希望先写这篇文章，但坦率地说，我需要先学会它。让我们深入探讨。
Principle A: Maximize impact to the mission
原理 A：最大化对使命的影响
The focus of all employees in a company should be to fulfill the company's mission, whether that mission is to earn billions, create social good, or both.
公司所有员工的关注点都应该是实现公司的使命，无论这个使命是赚取数十亿、创造社会价值，还是两者兼有。
To this end, the vast majority of people in a company are directly working towards providing a product/service to customers: they are building the product (engineers and designers), taking it to market (marketing and sales), or helping existing customers (support).
为此，公司中的绝大多数人都在直接致力于向客户提供产品/服务：他们在构建产品（工程师和设计师）、将其推向市场（营销和销售），或帮助现有客户（支持）。
Product management does nothing to directly build or operate the product for customers. Instead, its core responsibility is to look ahead and inform the builders/operators of the product what the right path is to achieve the goal. That path is also called the product strategy, and the best ones are those that maximize impact to the mission.
产品管理并不直接为客户构建或运营产品。相反，其核心职责是展望未来，并告知产品的构建者/运营者实现目标的正确路径。这条路径也被称为产品战略，而最好的战略是那些能够最大化对使命影响的战略。
Defining the product strategy is a massive responsibility... how does a PM do it? By looking at three inputs:
定义产品战略是一项重大的责任......产品经理是如何做到的呢？通过审视三个输入：
- What the goal is
目标是什么 - What the environment around them is signalling
周围环境在传递什么信号 - What people, money, and time constraints exist
存在哪些人员、资金和时间限制
PMs use these inputs to form an opinion on the right path that will lead to fulfillment of the mission.
产品经理使用这些输入来形成对正确路径的观点，这条路径将通向使命的实现。
1. What the goal is
1. 目标是什么
Everything starts with the goal. If you don't know where you're supposed to go, you shouldn't even move because you're just as likely to end up further away.
一切都始于目标。如果你不知道应该去哪里，你甚至不应该移动，因为你同样可能离目标更远。
One of the biggest issues I see with PMs is that they don't take the time to really understand the goal. They may be able to recite the mission statement, but do they understand its foundations? I'm talking about the customer assumptions that led to it, the moral/ethical/design boundaries the company intends to stay within to achieve it, and the vision of the world's future that it is supposed to live in.
我在产品经理身上看到的最大问题之一是，他们没有花时间真正理解目标。他们可能能够背诵使命宣言，但他们理解其基础吗？我指的是导致这一目标的客户假设、公司打算在实现目标时保持的道德/伦理/设计边界，以及它所应该存在于其中的世界未来愿景。
Great product managers incessantly ask hard questions to leadership to understand the nuances --- the first principles --- that went into defining the mission they follow. The deeper one can understand it, the more precise their path to the goal will be.
优秀的产品经理不断向领导层提出尖锐的问题，以理解定义他们所追随使命的细微差别------第一性原理。一个人理解得越深，他们通往目标的路径就会越精确。
PMs also need to know how other teams are also contributing to the effort. Especially in large companies, aligning across all teams ensures that collisions are avoided and --- far better --- find opportunities for teams to combine efforts and accelerate progress.
产品经理还需要了解其他团队如何为这项工作做出贡献。特别是在大公司中，跨所有团队保持一致可以确保避免冲突------更重要的是------找到团队合作加速进展的机会。
Only once a PM is sure they know their company's goal, and the goals of other teams around them, are they ready to effectively setup their own team's goals, which must ladder up clearly to the broader mission.
只有当产品经理确信他们了解自己公司的目标，以及周围其他团队的目标时，他们才准备好有效地设定自己团队的目标，这些目标必须清晰地向上支撑更广泛的使命。
2. What the environment is signalling
2. 环境在传递什么信号
Most plans start out as a straight line to the goal, but the path never ends up as one. It's impossible to see all the obstacles ahead, and sometimes the goal is so far away you can't always tell if you've drifted off course. To hedge against this, PMs have to listen to their environment to detect, anticipate and course correct the path.
大多数计划开始时都是通往目标的直线，但路径最终从来不是直线。不可能看到前方所有的障碍，有时目标如此遥远，你无法总是判断是否已经偏离了航线。为了防范这一点，产品经理必须倾听环境，以检测、预测并纠正路径。
There are two main classes of environment signals you want to seek:
有两类主要的环境信号你需要寻找：
Customer signals are the qualitative and quantitative data sets you accumulate on how customers are using the product. This data is the "ping" from the goal, and when you hear that ping get stronger, you know you aren't veering too far off course.
客户信号 是你积累的关于客户如何使用产品的定性和定量数据集。这些数据是来自目标的"回声"，当你听到这个回声变得更强时，你就知道你没有偏离航线太远。
Market signals are the "asteroid warnings" that represent shifts in the world that will affect your path. They are the changes in the competitive, political, and socioeconomic landscapes that affect your company and customers.
市场信号 是代表将影响你路径的世界变化的"小行星警告"。它们是影响你公司和客户的竞争、政治和社会经济格局的变化。
Constantly listening to the world outside your company walls is a critical input to great product management. And what you hear from customers is the ultimate validation of your achievement of the goal.
不断倾听公司围墙外的世界是优秀产品管理的关键输入。而你从客户那里听到的声音是你实现目标的最终验证。
3. What people, money, and time constraints exist
3. 存在哪些人员、资金和时间限制
How far a rocket ship can go is constrained by the fuel it holds, the quality of its crew, and its time-constrained ability to leverage gravitational boosts using from other celestial bodies like Jupiter. Similarly, product teams are constrained by the money, people, and time they have to launch a product. On any given mission, a product team will be constrained by all three of these.
一艘火箭船能飞多远受到其携带的燃料、船员质量以及其利用木星等其他天体进行引力助推的时间限制能力的制约。同样，产品团队受到发布产品所需的资金、人员和时间的限制。在任何给定任务中，产品团队都会受到这三者的限制。
People on a product team often represent the biggest constraint. Too often, that constraint is only thought of as the number of people working on a product (which it can be), but vastly more important are actual skill and experience levels of the people on the team.
产品团队中的人员往往代表最大的限制。很多时候，这种限制只被理解为从事产品工作的人数（这确实可能是限制），但更重要的是团队中人员的实际技能和经验水平。
Just like you wouldn't put the rookie class of NASA on its first mission to Mars, there are product scopes that are beyond the ability of some teams. This isn't their fault, and says nothing of their eventual abilities, but it is something that PMs critically need to understand when figuring out the path forward. To be clear, this applies to the PMs themselves, as well. They need the self awareness to know when they're biting off more than they can chew. We'll cover much more on people later in this post.
就像你不会让 NASA 的新手班级执行首次火星任务一样，有些产品范围超出了某些团队的能力。这不是他们的错，也不代表他们最终的能力，但这是产品经理在确定前进路径时迫切需要理解的事情。需要明确的是，这也适用于产品经理自己。他们需要有自我意识，知道什么时候自己在贪多嚼不烂。我们将在本文后面更多讨论人员。
Money is a constraint that relates to the ability of a team to hire the right people (salaries), enable them to work (overhead like office space), operate the product (servers and support), and distribute it (marketing).
资金 是一种与团队雇佣合适人员（薪资）、使他们能够工作（办公空间等开销）、运营产品（服务器和支持）以及分发产品（营销）能力相关的限制。
It would be silly to spend all of your money on salaries to hire the best team, but then not have an office for them to work in, or not have a single dollar to pay for marketing and thus very few customers will find the product.
把所有的钱都花在薪资上以雇佣最好的团队，但然后没有办公室供他们工作，或者没有一分钱用于营销，因此很少有客户能找到产品，这将是愚蠢的。
Most companies have abstracted away the overhead, operating, and marketing cost complexities from PMs (so that they can focus on产品和 distribution), but it's important that PMs understand that capital isn't limitless. In lieu of these luxuries, PMs need to consider all the money impacts when building their strategy.
大多数公司已经将开销、运营和营销成本的复杂性从产品经理那里抽象掉了（以便他们能够专注于产品和分发），但产品经理理解资本不是无限的是很重要的。在没有这些奢侈条件的情况下，产品经理在制定战略时需要考虑所有的资金影响。
Time is the ultimate constraint because unlike the other two, once it's exhausted you cannot get more of it. Time represents reality. It's the reality that products that haven't shipped have yet to produce any value. It's the reality that competitors are taking market share everyday. It's the reality that your company will run out of money next month.
时间 是最终的限制，因为与其他两者不同，一旦耗尽你就无法获得更多。时间代表现实。它是尚未发布的产品尚未产生任何价值的现实。它是竞争对手每天都在夺取市场份额的现实。是你的公司下个月将耗尽资金的现实。
PMs must manage time. They must ensure that that they don't miss big windows of opportunity, make the right tradeoffs, and utilize time as a healthy way to foster execution on their team.
产品经理必须管理时间。他们必须确保不错过大好机会窗口，做出正确的权衡，并将时间作为一种健康的方式来促进团队的执行。
The right path (product strategy) is at the intersection of the inputs
正确的路径（产品战略）位于输入的交汇处
When PMs know the goal, understand the environment, and respect the constraints, they have the necessary inputs to build a great product strategy, which sits somewhere in the intersection of those inputs.
当产品经理了解目标、理解环境并尊重限制时，他们就拥有了制定优秀产品战略所需的输入，该战略位于这些输入的某个交汇处。
My reductionist analogy may imply this is easy, but let me be clear that forming a good strategy is very, very difficult. In fact, despite being confident enough to write this post, I am not confident that I can always find the right strategy in practice. It's just fucking complex.
我的简化主义类比可能暗示这很容易，但让我明确一点，制定一个好的战略非常非常困难。事实上，尽管我有足够的信心写这篇文章，但我并不确信我在实践中总能找到正确的战略。它就是他妈的复杂。
The other dimension that I hope comes through from this section is that PMs need incredible breadth to effectively synthesize these inputs into strategy. Knowing enough about engineering, UX, data, finance, organizational design, operations, research, marketing, etc. makes your ability to synthesize these inputs more effective, and thus your strategy will have a higher likelihood of being successful.
我希望从本节中传达的另一个维度是，产品经理需要令人难以置信的广度来有效地将这些综合输入转化为战略。对工程、UX、数据、财务、组织设计、运营、研究、营销等了解足够，会使你综合这些输入的能力更有效，从而使你的战略有更高的成功可能性。
I feel many PMs get intimidated by this reality and react by specializing in a domain and/or outsourcing the thinking from a domain to another team (e.g. "marketing will figure out how to distribute it"). I really think this type of thinking是 counterproductive, and will limit your potential. As scary as it sounds, it is important that you try to learn everything. Temper the fear that comes with this with the acknowledgement that, at the same time, it is impossible to know it all.
我觉得许多产品经理被这一现实吓倒，并通过专注于一个领域和/或将一个领域的思考外包给另一个团队（例如"营销会弄清楚如何分发它"）来应对。我真的认为这种思维是适得其反的，会限制你的潜力。尽管听起来很可怕，但尝试学习一切确实很重要。用承认同时不可能知道所有事情来缓和随之而来的恐惧。
Principle B: Accomplish everything through others
原理 B： 通过他人完成一切
In the rocket ship analogy, who did you think the PM was? Were they the person who planted the flag on planet Goal, or were they one of the astronauts on the ship?
在火箭船的类比中，你认为产品经理是谁？他们是在目标星球上插旗的人，还是飞船上的宇航员之一？
The answer is neither. The PM was actually Mission Control back on Earth. Their job was to support the astronauts who were actually risking their lives for the mission (okay building product isn't that serious, but you get the point). As a PM, you cannot --- absolutely cannot --- forget that you accomplish everything through others.
答案都不是。产品经理实际上是地球上的任务控制中心。他们的工作是支持那些真正为任务冒着生命危险的宇航员（好吧，构建产品没有那么严重，但你明白我的意思）。作为产品经理，你绝对不能------绝对不能------忘记你通过他人完成一切。
Sorry. You're not even on the spaceship 🚀.
抱歉。你甚至不在飞船上 🚀。
Wait, why do so many PM articles promote that PMs should be "jacks of all trades, and do whatever it takes, including coding, marketing, and designing"?
等等，为什么那么多关于产品经理的文章提倡产品经理应该是"多面手，做任何必要的事情，包括编码、营销和设计"？
A "doing whatever it takes" mentality doesn't make you a good product manager, it makes you a good employee. When a PM is coding, writing support documents, or designing the product, they're (presumably) doing so because it's blocking the critical path to shipping. They're acting out their values as an employee of the company, not as a PM.
"做任何必要的事情"的心态不会让你成为一个好的产品经理，它只会让你成为一个好的员工。当产品经理在编码、编写支持文档或设计产品时，他们（大概）这样做是因为这阻碍了发布的关键路径。他们是在践行作为公司员工的价值观，而不是作为产品经理。
Everyone --- not just PMs - should aspire to have this mentality. If an engineer happens to also be good at marketing and that's what's blocking the team, they should jump in and help. But that doesn't make them a better engineer. The reason PMs often find themselves building-a-bunch-of-stuff is because, as the only member of a team who's not supposed to build, it's rational that they should be the first to volunteer when things fall behind, but that's very different than saying it's part of their job as a PM.
每个人------不仅仅是产品经理------都应该渴望拥有这种心态。如果一名工程师恰好也擅长营销，而这正是阻碍团队的事情，他们应该跳进去帮忙。但这不会让他们成为更好的工程师。产品经理经常发现自己构建很多东西的原因是，作为团队中唯一不应该构建的成员，当事情落后时，他们应该第一个自愿帮忙是合理的，但这与说这是他们作为产品经理工作的一部分是非常不同的。
Accomplishing everything through others is an irreducible first principle of product management, so to explore it deeper, we're going to completely change the analogy.
通过他人完成一切是产品管理的一个不可约简的第一性原理，所以为了更深入地探讨它，我们将完全改变这个类比。
Product Managers are like coaches of a sports team
产品经理就像运动队的教练
There is no better analogy for how a PM should think of their role than the coach of a team sport like basketball, volleyball, football, etc. Here's why the parallels are so strong...
对于产品经理应该如何看待自己的角色，没有比篮球、排球、足球等团队运动的教练更好的类比了。这就是为什么这种类比如此强烈......
Coaches don't play
教练不上场比赛
A coach doesn't play. They are hired to support a team, and do so by helping them increase their individual and collective potentials. They are measured - by the team and owners alike - by winning. Generally, if a team doesn't win, the coach is fired, not the players.
教练不上场比赛。他们被雇用来支持一支球队，通过帮助他们提高个人和集体潜力来做到这一点。他们通过胜利来衡量------被球队和老板 alike。一般来说，如果球队不赢，教练会被解雇，而不是球员。
A PM doesn't build, market, or support anything. We are hired to support a team in achieving our company's goals. We do this by enabling the team to maximize their individual and collective potentials by aligning everyone on a product strategy (principle A) and fostering a healthy team dynamic. Generally, if the team doesn't build something great, the product manager should be fired, not the team.
产品经理不构建、营销或支持任何东西。我们被雇用来支持团队实现公司的目标。我们通过使团队能够最大化其个人和集体潜力来做到这一点，方法是让每个人在产品战略上保持一致（原理 A）并培养健康的团队动态。一般来说，如果团队没有构建出伟大的东西，产品经理应该被解雇，而不是团队。
A coach's style is dependent on the relative skill of the coach and the players
教练的风格取决于教练和球员的相对技能水平
When I first wrote that PMs are like sports coaches, what did you visualize?
当我第一次写产品经理就像体育教练时，你想象到了什么？
Not all coaching relationships are equal
并非所有的教练关系都是平等的
Do you see the coach as a parent and the team as kids? Or are the players like Lebron, telling the coach what to do? How about the wrist wrapping assistant coaches?
你把教练看作父母，把团队看作孩子吗？还是球员像勒布朗一样，告诉教练该做什么？或者是缠腕带的助理教练？
For example, if you're a PM straight out of college and you join a product team of seasoned engineers, why in the world would you play a leadership role? You shouldn't --- you don't have the experience to back it up. But that doesn't mean you can't be useful.
例如，如果你是一名刚毕业的产品经理，加入了一个由资深工程师组成的产品团队，你为什么要扮演领导角色呢？你不应该------你没有经验来支撑这一点。但这并不意味着你不能发挥作用。
PMs need strong self awareness to recognize when to lead, partner, or support their team.
产品经理需要有强烈的自我意识，以识别何时领导、合作或支持他们的团队。
In the framework above, "skill" is shorthand for the sum of the abilities, experience, accomplishments, and work ethic of the people. Here's how I've applied it in my career:
在上面的框架中，"技能"是人员能力、经验、成就和职业道德总和的简写。以下是我如何在职业生涯中应用它的：
When I'm the PM on a team of fresh grads, I will take a very direct leadership approach. I will prescribe the frameworks, goals, and even how to organize the execution of the project. This makes sense, I've shipped projects and they haven't.
当我是一个由应届毕业生组成的团队的产品经理时，我会采取非常直接的领导方式。我会规定框架、目标，甚至如何组织项目的执行。这很合理，我发布过项目，而他们没有。
When I'm working with a team of equal skill to myself, I will default to collaboration on all key decisions,并渴望获得每个人对战略和执行的认同。需要明确的是，产品经理应该在所有情况下都渴望合作，但这种相对技能动态最需要它。
Finally, when I'm working with a team that's more experienced and accomplished than myself, I will revert to an assistant coach or trainer mindset. I will ask, how can I be helpful? What can I take off your plate that's low leverage? I'll play a pure support role. For example, I will start by asking the experienced team about their vision, and then follow it up with lots of questions to get down to their first principles and strategy. Then, I'll synthesize all this information into a document and align with them to ensure it represents their vision. At that point, I'm just as free to align the company with this strategy as if I had developed it myself. I can still do my job.
最后，当我与一个比我更有经验和成就的团队一起工作时，我会回归到助理教练或培训师的心态。我会问，我能帮什么忙？我能从你的盘子里拿走什么低杠杆的事情？我会扮演纯粹的支持角色。例如，我会先询问有经验的团队他们的愿景，然后用很多问题跟进，以深入了解他们的第一性原理和战略。然后，我会将所有这些信息综合成一份文件，并与他们保持一致，以确保它代表了他们的愿景。在那时，我可以像自己制定了这个战略一样自由地将公司与这个战略对齐。我仍然可以做我的工作。
Note that in all cases, the PM is still responsible for the development of the product strategy, but how they get there can be very different.
请注意，在所有情况下，产品经理仍然负责产品战略的制定，但他们如何达到目标可能非常不同。
Without a doubt, not understanding this dynamic of relative skill between the team and the PM, is the number one reason that PMs fail. They misread the situation, fall into the trap of thinking PM equals mini-CEO by default, and immediately lose trust with their team, which takes ten times as long to win back.
毫无疑问，不理解团队和产品经理之间相对技能的这种动态，是产品经理失败的第一大原因。他们误判了形势，陷入了默认认为产品经理等于迷你 CEO 的陷阱，并立即失去了团队的信任，而赢回信任需要十倍的时间。
When the team wins, the players are celebrated, not the coach
当团队获胜时，庆祝的是球员，而不是教练
People rarely talk about the coach when a team wins. The same should be true for product teams. If your team does incredible work, they deserve the spotlight --- don't steal it.
当团队获胜时，人们很少谈论教练。产品团队也应该如此。如果你的团队做出了令人难以置信的工作，他们应该得到聚光灯------不要抢走它。
Coaches need to know what every player does to be effective
教练需要知道每个球员做什么才能有效
No one can coach a team if they don't even know how the game is played. You need to have empathy and respect for all the work individuals on your team undertake.
如果他们甚至不知道如何比赛，没有人能执教一支球队。你需要对团队中每个人承担的所有工作抱有同理心和尊重。
This is more useful than simply having a deeper understanding about what's easy versus hard to build. It's also about understanding what is fun and intellectually stimulating work vs. mundane and repetitive work. No team is inspired doing the same type of work they've done before. That's when work becomes about a paycheque, and subsequently when the work itself is less creative and inspired.
这比仅仅对什么容易构建与什么难构建有更深入的理解更有用。这也是关于理解什么是有趣且能激发智力的工作与平凡且重复的工作。没有团队会受到激励去做他们以前做过的相同类型的工作。那时工作就变成了关于薪水，随后工作本身就变得缺乏创造力和灵感。
For a PM, respecting this encourages you to create the project conditions that enable people on the team to grow and accomplish the mission for the company. When you create these conditions, the outcome is deep ownership and emotional investment from everyone.
对于产品经理来说，尊重这一点鼓励你创造项目条件，使团队中的人员能够成长并为公司的使命做出贡献。当你创造这些条件时，结果是每个人深入的所有权和情感投入。
When a captain emerges, coaches step back and let them lead
当队长出现时，教练退后让他们领导
It's clear that Lebron James is the captain. His team listens to him... maybe not Wade
很明显勒布朗·詹姆斯是队长。他的团队听他的......也许韦德不听
As a team member, it's one thing to hear about how you're not executing from your coach, it's another thing entirely to hear it from someone putting in the same work as you. As a coach, when a player on your team emerges as a leader; someone who holds the rest accountable and challenges them to be better, you have the foundations for the highest performing type of team.
作为一名团队成员，从你的教练那里听到你没有执行是一回事，从与你付出相同工作的人那里听到则完全是另一回事。作为一名教练，当你的团队中有一名球员成长为领导者；一个让其他人负责并挑战他们变得更好的人，你就拥有了最高绩效团队的基础。
In product teams, this person is typically an engineering or UX lead. When this happens, count your blessings and then work to further elevate their influence on the team. Make them a coach, too, and your co-founder.
在产品团队中，这个人通常是工程或 UX 负责人。当这种情况发生时，庆幸你的福气，然后努力进一步提升他们在团队中的影响力。也让他们成为教练，以及你的联合创始人。
Typically, in this dynamic PMs will continue to lead strategy, while the captain drives execution, however PMs should also be open to "giving up" strategy as well, if it keeps the captain engaged and makes them feel true ownership. This is where you need to suppress your ego. It is so rare to find people who want to be leaders, so if the captain emerges, do whatever you can to capitalize on it (but hold them accountable, too).
通常，在这种动态中，产品经理将继续领导战略，而队长推动执行，然而，如果这能让队长保持参与并让他们感受到真正的所有权，产品经理也应该对"放弃"战略持开放态度。这是你需要压制自我的时候。很难找到想要成为领导者的人，所以如果队长出现，尽你所能利用这一点（但也要让他们负责）。
Coaches ensure the team is training and in a peak state of performance
教练确保团队正在训练并处于最佳表现状态
Coaches don't spend all their time looking at video replays and strategizing with the team, they're also ensuring the team practices regularly so they can perform at their peak.
教练不会把所有时间都花在观看录像回放和与团队制定战略上，他们还确保团队定期练习，以便能够在巅峰状态下表现。
The parallel for product teams are product development processes. Whether you're hardcore agile/scrum, "process-less" (note: a process exists whether you choose to acknowledge it or not), or something in between --- the coach is responsible for ensuring the team commits to a process that enables them to do their best work. Note that the optimal process will be different for each team and coach dynamic.
对于产品团队来说，对应的是产品开发流程。无论你是硬核敏捷/Scrum、"无流程"（注意：无论你选择承认与否，流程都存在），还是介于两者之间------教练负责确保团队致力于一个能够使他们发挥最佳工作的流程。请注意，最佳流程对于每个团队和教练动态都会不同。
Coaches nurture the energy levels and mental state of the team
教练培养团队的能量水平和心理状态
This is an uncomfortable ownership concept for many PMs, but whenever I see a team that doesn't seem excited about the work or looks burnt out, I'll put pressure on the PM to foster a healthier dynamic.
这对许多产品经理来说是一个不舒服的所有权概念，但每当我看到一个团队似乎对工作不兴奋或看起来精疲力竭时，我会向产品经理施压，要求他们培养更健康的动态。
This is difficult of course, because people are complicated. We are all motivated to do our best work by different things: some of us need encouragement, some need to be challenged, some need a friend, and some need all three at different times. PMs need to find a way to understand what makes individuals on their team tick --- the first principles of their being --- and then build meaning and purpose from work on top of those principles.
这当然很困难，因为人很复杂。我们都被不同的事物激励着去做最好的工作：有些人需要鼓励，有些人需要被挑战，有些人需要一个朋友，有些人在不同时期需要这三者。产品经理需要找到一种方法来理解是什么让他们团队中的个人运转 ------他们存在的第一性原理------然后在这些原理的基础上从工作中建立意义和目的。
This concept can come off as self aggrandizing (get out of my head PM!!! ), but it is the right one for a coach and PM to have. Creating an energized and committed team is fundamental to success, and achieving it repeatably is the pinnacle of good PM'ing and leadership in general.
这个概念可能显得自我膨胀（从我的脑子里出去，产品经理！），但这对于教练和产品经理来说是正确的。创造一个充满活力和承诺的团队是成功的基础，而可重复地实现这一点是优秀产品管理和一般领导力的巅峰。
The thing about first principles is that nothing else matters in the long run
关于第一性原理的事情是，从长远来看，其他什么都不重要
Exploring the first principles of Product Management reveal that it demands equal effort from the left and right brains. It's equal parts art and science. It's equal parts hyper-rational and hyper-emotional.
探索产品管理的第一性原理揭示，它需要左右脑同等的努力。它是艺术和科学的同等部分。它是超理性和超情感的同等部分。
It's the polarity of these two ways of thinking that make the craft of product management complex, exciting, and frustrating all at once.
这两种思维方式的极性使产品管理这门技艺同时变得复杂、令人兴奋和令人沮丧。
Success for PMs means respecting both of these principles equally. Create a product strategy that maximizes impact to the mission, and have a coach's mentality to accomplish that mission though the people around you.
产品经理的成功意味着同等尊重这两个原理。制定一个能够最大化对使命影响的产品战略，并拥有教练的心态，通过你周围的人来完成这个使命。
reference
- Product Management Mental Models for Everyone | by Brandon Chu | 2018
https://blackboxofpm.com/product-management-mental-models-for-everyone-31e7828cb50b... - The First Principles of Product Management | by Brandon Chu | 2018
https://blackboxofpm.com/the-first-principles-of-product-management-ea0e2f2a018c