Alexi

By Brandon ChuFollow
GM, Platform @shopify. Still a PM at ❤️
Translator：Alexi

You’ve probably seen this diagram before. It elegantly shows that product management is the intersection of a diverse skill set.
你也许之前看过这个图标。它优雅的展示了产品管理人员是需要多种技能综合的。

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.
在地球上没有足够的时间来学习这三个圈，所以这个图是有用的，它最终不切实际。

What would have been far more helpful was to know what actually comprises that intersection:
更有帮助的是弄清这个交互处的实际组成是什么：

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.
我写下这些为了年轻的自己，为了产品经理新人，对于更多有经验的产品经理更能获得提升。为了保持图片的对称性，技能被划分为各个学科部分。我讲解三个关键的概念/技能，其中一个你没必要了解。我会尽可能多地使用通俗易懂的语言，为那些对任何话题都不感冒的人而写。

1. The Stack（堆栈）

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)
快速学习方法：请一位工程师带你提升高水平的“堆栈”。记录每一个技术的名字。快速谷歌这些术语将教会你选择的每种技术的一些高级好处和权衡，以及它们如何协调工作。保持高水平，因为你很容易陷入危机（将“权衡+优势+对比“添加到你的搜索查询中）

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（系统架构）

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:
快速学习的方法：让一个工程师画出你的产品架构，你会得到这个：

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（数据模型与它的接口们）

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依旧让你与外部组件通信。当你在谷歌地图上喊优步，谷歌地图正在和优步的一个组件交流中。大多数的应用拥有公共的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（你不需要关注的地方）

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.
编程。不要误解我，我喜欢编程并且它能让你更棒，但是除非是高技术的产品，你并不需要它而成为一个有用的产品经理。如果你发现你在编程作为一名产品经理，那么你可能要问自己如果你正在做高水平的工作量，否则你就是不清楚你应该做其他什么事情。话虽这么说，我觉得构建一个app将其交付在生产环节至少是一件值得和有趣的经历。

1. Project Management（项目管理）

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.
无聊，我知道。我也讨厌它，但是它真的很重要。如果你不能很好地运行一个项目，你就永远不会成为一个好的PM。

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:
话虽这么说，你可以投资一些软件专业的东西来加速你的学习曲线：

• 1.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.
  了解产品开发的基本知识，这样你就能理解你的团队。学习版本控制，协作开发，质量保证过程，高层次的，如何以及何时将代码部署到产品中的用户。

• 2.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.
  学习折磨软件开发团队的普遍问题，其他人已经开发出了一些方法来尝试和解决这些问题。你会遇到像敏捷、迭代和看板这些事情。

• 3.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（建模的作用）

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
  从长期来看，成本削减、通货膨胀和竞争等市场力量是如何发挥作用的？

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（收集和分析数据）

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需求或者使用拖放页面基于数据基础结构在你的公司。不管怎样，你都需要花费精力学习可用的工具。谷歌他们。

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（你不需要关注的地方）

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老东西。我不会把它称为屁话（笑 译者还打算考），但是这不是软件行业的成功方法。理解愿景，找到一个值得解决的问题去实现它，建立一个假设来解决它，并尽快和真实用户一同验证。否定、再来。

PS：用户体验放到下一篇，单独译。