英文原文来自：https://medium.com/the-black-box-of-product-management/the-black-box-of-product-management-3feb65db6ddb

产品经理的黑盒子

当存在的合理性受到质疑时，产品经理显得很可悲

BY Brandon Chu 翻译： Kevin嚼薯片

所有产品经理都经历过被这样提问，如同这是产品经理世界里的一个重要的仪式：

“产品经理到底是做什么的？”

我能理解设计师和开发工程师为何问这样的问题。从他们角度来看，我也会有所不解，因为产品经理的工作非常零散，而从不显示出一点点规律。

当我第一次从事产品经理工作时，我甚至不知道我做的就是这个职业。相反，我是一个创始人，并只是意识到我只是在“创业”。

之后，当我去面试产品经理的工作时，这些面试官告诉我其实我在做的正正是产品经理的工作。我被招收了。在这个职位的早期，我曾被问过上面这个被说烂的问题。但我没有感受被冒犯；事实上，我会感到好奇，所以我开始去阅读跟产品经理相关的东西。互联网上有很多这样的说法：

• 我不是项目经理，如果有人有这样的推断，我会感到很生气。

• 我本应该去负责决定是什么和为什么的职责。

• 我应该是一个梦想家，代表用户的声音，把控项目完成的人，之类的。

我把所有的精力放在这里。在头几个月，我每周都会重读《优秀的和糟糕的产品经理》这本书——我的产品经理领域的圣经。

然后我不断发布产品。很快，我觉得这很有用。

多年之后，我开始管理其他产品团队。其他的产品经理会期待我去做出一些定义，好让他们能回应以上的质疑。我会提供一些好的文章以及我多年的经验供各位品尝。

我现在在我的第三个作用Shopify产品,我又一次发现自己对什么是我真正反思假设。Shopify是一个真正的工程文化,很少有产品经理的大小相对于公司。的角度来看,我公司员工1:10的比例经前综合症。Shopify(包括董事)接近接触。

我现在在Shopify（加拿大电子商务公司）是我第三个产品相关的角色，我又一次发现自己对我真正在做的事情会进行反思并形启发式。Shopify是一个有真正工程师文化的公司，而由于公司规模，却只有很少的产品经理。整体来看，我上家公司招聘产品经理的比例是1:10。在Shopify（即便包括产品总监）也只是接近1:80。

在我入职第一周时，一个工程师问了我“那个问题”。

在这里工作的另一好处是能观察另一种如何有效地构建和发布产品的方法。Shopify的工程师和设计师非常有才华、有主见和有独立性，让自己,学会有效地与他们合作迫使我改变我对工作的理解。

也迫使我找到不应该改变的是什么，并在这一过程中，推动我去从是什么上升到为什么。这篇文章不是探讨Shopify，也不是探讨如何成为一个有效的产品经理。 它是探讨产品经理存在的原由。

为什么需要产品管理

产品经理是公司需要展现的两个指数级增长能力副产品。

1. 速度： 公司需要在一个技术创新速度不断加快的行业中生存下来。

2. 规模： 公司产品、团队组织、用户，都随着公司不断成长而越来越复杂。

速度一个指数级的能力，因为相比过去，现在每段时间所发生的变化越来越多。规模也是类似的，相比过去，每个新增功能、每个员工、每个用户，都在让系统变得越来越复杂。

产品经理作为一个岗位已经是目前主流软件公司的通识，因为软件通常需要快速发布和规模化。

速度

互联网改变着软件产品触达买家市场的方式。每年发布一次和用盒子包装放在架子上销售的时代已经一去不复返。在过去的二十年，很多团队都是写代码、部署上线、然后让用户一瞬间获取更新。

软件开发会有最低的入门要求。接近高级的编辑语言，和能给开发者赋能的流行开源库。于此同时，建立一个产品功能的基本支持和部署成本已经降到基本为零。

这意味着世界上的每一个难题，都可能同时有数百个独立团队正在解决中。

从这个角度来说，速度有两层含义：你能用软件开发为市场买家带来价值的速度，以及由于竞争压迫导致企业需要为了生存下去而快速发展。

规模

50人以内的创业团队很少有产品经理岗位是因为复杂性仍在可控范围内。CEO和联合创始人仍然有能力去协调公司走向和保持创业公司的自由度。

但随着公司发展，并在功能不断增加、用户不断多样化、团队不断成长的情况下，复杂性就会出现。并且呈指数级增长。

例如，你认为20人的创业团队需要有多少会议？

公司规模；可能的会议数量

这个图展示了我们为什么会陷入到指数级增长的概念中。

公司需要解决的问题也变得复杂。随着团队解决的问题的等级越高，他们会同时产生数以百计的衍生问题，都急需得到解决。但是公司无法解决所有的问题。面对数以百计要解决的问题，能迅速地选择要聚焦的问题点是一个公司的最重要的策略。

混乱的混合物

当你同时考虑速度和规模对公司的影响时，很容易得出没有一个能全面考虑公司情况的人会导致公司脱轨的概念。最终，承担这个角色的是CEO，但当他们的工作已经饱和时，还有谁能填补这一空白？

为什么是产品经理

_当然，产品是需要一些监管的——这点是很明确的。为什么不直接给_每个人去培养管理产品的技能，为什么需要雇佣一个特定的角色去做？

狭义的理由是管理一个产品比你想象中更难，需要多年的经验才能胜任。广义的理由是：

优秀的产品开发是非常难的

产品经理的核心竞争力是真正地理解产品开发。即如何确定哪些问题需要解决以及如何与团队合作去解决问题。

任何经历过几次产品发布的人都知道要抛弃条条框框，像下面这样的一个线性的产品开发过程，简直是一个不可能的事情。

问题-市场-商业-设计-开发-销售-配送

即使你把反馈回路包含在这些步骤里，去与团队一起通过一个整洁的步骤清单去工作的想法是有问题的。它不符合这个技术快速发展的世界。

世界变化太快以至于我们只能用三个月前的研究去工作。

我认为现代产品开发是一个跨学科的系统，在一个网络中兑现用户的愿望。 产品经理是在这个网络中建立沟通桥梁的API。

产品开发；一个跨学科系统；

每个节点代表一个专业领域，每个都足以成为一个职业去掌握。速度和规模已经成为公司产品开发质量的一个重要决定因素：有太多需要去了解，只有这样团队才能有效地交付产品。

产品开发的过程就是这个系统随着时间演变的过程。

产品开发过程

从问题识别到产品发布的过程中，产品经理都带领着这个系统，确保网络中的每个节点都知道其他环节的进度，同时用户也越来越渴望知道正在开发的产品是什么。

最后，组织规模化会形成多个团队。一个有效的产品开发系统需要协调和集中这些团队来实现公司的愿景。

协调多个团队来实现公司的愿景。

作为产品开发的API，产品经理通过确保不重复工作来提升公司效率，并共享基础设施来赋能其他团队快速推进。

产品经理是跨学科的

产品经理花费年时间来发展能负责该系统所需的技能。这是一种跨学科的、有广度且深度的学习方法。

在我的职业生涯中，我做过这些：编程、界面设计、用户体验研究、金融建模、业务发展、支集、文案写作、会计、法律、合同谈判、报告、营销、博客、问答、和产品复制。

但我没有一个是专家级的，在某些方面我只达到了边界级。我只知道足够的知识能使我作为一个API，但不会去涉足太深（用一个很好的方式）。这是产品经理技能集合的精髓所在，它让创始人很难精确地了解他们所带来的价值。

产品经理知道每个规程的足够知识来负责整个产品开发系统。

产品经理的跨学科意识使他们能够以任何语言进行交流，从而有效地将信息传递到整个团队。

他们还处于评估整个系统变化影响的最佳位置。最近我和Shopify的CEO进行了一次谈话，对我很受益。

“伟大的产品人明白世界运作方式的改变对记录的文件所产生影响。他们能够实时感知到这种影响。”

— Tobi Lütke

非常正确。

在一个以速度为王，且呈指数变化的世界里，在行动之前达成共识往往是一种奢侈想法。团队需要在日常基础上作出关键的决定以保持速度，而这些决策会对在利益相关者之间会产生重大的交易或冲突。

推动这些决策的不是别的，而正是产品经理的工作。

为什么黑盒会持续存在

不同于工程师和设计师的工作非常容易量化，而很难在短期内观察到产品经历所产生的价值，产品管理的模糊性也将要持续一段时间。

或许有一天，产品管理可能会有研究生学位和明确的职业道路，但不是现在。在那之前，企业将继续扩大规模，世界将继续变得更快，迟早“我们需要有人来管理这个”。

如果你是一个产品经理，不要在下一次有人挑战你的存在时感到心痛。拥抱质疑（毕竟你是一个PM），对自己的目标有信心。

如果你觉得这篇文章有价值，请在文章底部为我的文章点和打赏。

The Black Box of Product Management

PMs get sad when you ask them why they exist

BY Brandon Chu

There is a rite of passage in the product management world, where all PMs have experienced being asked:

“What does a product manager do, anyway?”

I empathize with designers and engineers for asking this question. In their shoes, I would be just as skeptical, because a product manager’s activities are fragmented, and don’t reveal the true discipline beneath.

When I first started in product management, I didn’t even know I was doing it. Instead, I was a first time founder and thought I was just “doing startup”.

Later, when I interviewed for a PM job, some much more qualified people told me that I was, in fact, doing product management. I got the job. Early into that role, I was asked the infamous question above. I wasn’t offended; in fact, I was just as curious as them, so I started reading (and reading) about product management. The internet said many things:

• I wasn’t a project manager, and I should be offended if someone infers that

• I was supposed to own the what and the why

• I should be a visionary, the voice of the customer, Mr. get shit done, etc.

I soaked it all in. I re-read Good Product Manager, Bad Product Manager —_my bible of product management—_weekly, for the first few months.__

And then I shipped, and shipped some more. And pretty soon I felt useful.

Years into that job, I started managing other product teams. Other PMs were now looking to _me _to define expectations, so that _they _could now respond to questions of why they existed. I offered a cocktail of the best posts I’d read, and examples of the experiences I’d had over the years.

I’m currently at Shopify in my third role in product, and again I find myself rethinking assumptions about what it is I truly do. Shopify is a true engineering culture, and has very few product managers relative to the size of the company. For perspective, my last company had 1:10 ratio of PMs to employees. Shopify (including directors) is closer to 1:80.

An engineer asked me “the question” the first week I was there.

One of the best things about working here has been observing an alternative approach to how products can be built and shipped effectively. Shopify engineers and designers are incredibly talented, opinionated and independent, and learning to effectively work with them has forced me to change the way I perceive my craft.

It’s also forced me to figure out what shouldn’t change, and in doing so, push me to abstract away the _what _in favour of the why. This post isn’t about Shopify, nor is it about the how to be an effective product manager. It’s about why product management exists.

Why Product Management

Product Management is the by-product of two exponential forces being exerted on a company.

1. Speed: The company exists in an industry where the rate of technological innovation is accelerating

2. Scale: Growth in the company’s product, organization, and customers are creating complexity

Speed is an exponential force because with every period of time, more change is occurring than in the last. Similarly with scale; every extra feature, employee, or user is adding more complexity to the system than the last.

The reason product management as a career has been popularized in predominantly software companies, is because software is inherently fast and scalable.

Speed

The internet changed how software products were delivered to the market. Long gone are the days of annual releases and cardboard boxes on shelves. For the last two decades, teams have been writing code, deploying it, and giving updates to all their customers instantaneously.

Software development itself has a lowered bar of entry. Approachability of high level programming languages, and the prevalence of open source libraries has super charged developers with unprecedented productivity. At the same time, the infrastructure costs of building a functional product and deploying it has dropped to basically zero.

This means that every large problem in the world likely has hundreds of independent teams working to solve it.

In this way,_speed _has two meanings: both how quickly you can get something to market with software development, and (critically) how competition forces companies to go faster to survive.

Scale

The reason why sub 50-person startups rarely have product managers is that the complexity is still manageable. The CEO and co-founders are still able to coordinate the company towards a focused problem and unleash the power of a scrappy startup upon it.

But as the company grows, complexity emerges as more features are added, customers become more diverse, and the team grows. And that complexity grows exponentially.

For example, how many meetings do you think a 20-person startup can have?

[The answer shows why we suck at conceptualizing the exponential](https://gist.github.com/Brandonmchu/c77a70b9fdb309f2728d# file-gistfile1-txt).

The problem the company solves grows in complexity as well. As teams solve high level problems, they spawn hundreds of derivative problems, all begging to be solved. The catch is the company can’t solve them all. Faced with hundreds of problems to solve, choosing where to focus quickly becomes the most important decision a company makes.

A Cocktail of Chaos

When you consider the simultaneous impacts of speed and scale on a company, it’s easy to conceptualize how things will eventually derail without someone thinking holistically about the company. Ultimately, that role is for the CEO, but when they’ve reached their multi-tasking limits, who else can fill the void?

Why Product Managers

Sure, products need some oversight - got it. Why not just train everyone to be able to manage the product, why hire a specific role?

The short answer is that it’s harder than you think to manage a product, and it takes years of experience to become capable. Here’s the long answer:

Good product development is hard

The core competency of a product manager is truly understanding product development. That is, how to identify which problem to solve and how to work with a team to solve it.

Anyone who’s been through a few launches knows that despite the textbooks, a linear product development process like the one below is a fairy tale.

Even if you included feedback loops between the steps, the idea of neat and tidy sequential steps, where functional teams work together through a checklist is flawed. It simply does not fit into a world where technology is progressing exponentially.

The world changes too quickly for us to build on research we had even three months ago.

I view modern product development as a system of interconnected disciplines, working in a network, to deliver on a user’s desire. Product managers are the API that facilitates communication in this network.

Each node represents a broad bucket of domain expertise, each with enough depth that people dedicate careers to master them. This is an important quality of product development in a company where speed and scale have reached critical mass: there’s too much to know, so only a team can effectively deliver a product.

The process of product development is how this system moves through time.

Product managers shepherd this system from problem identification through to product launch, ensuring that each node in the network is aware of the progression of the others, and that users increasingly want what is being developed.

Finally, organizational scale brings with it multiple teams. And an effective product development system coordinates and focuses those teams towards the company’s vision.

As the product development APIs, product managers support company wide efficiency by ensuring no duplication of effort, and sharing infrastructure to enable other teams to go faster.

Product managers are multidisciplinary

Product managers spend years to develop the skills required to be responsible for this system. It’s a multidisciplinary, breadth over depth approach to learning.

In my career, I’ve done all of: programming, UI design, UX research, financial modelling, business development, support, copy-writing, accounting, legal, contract negotiation, reporting, marketing, blog posts, FAQs, and product copy.

I’ve been an expert in none, and achieved borderline competence in some. I knew _just enough _of each to be useful as an API, but never enough to be dangerous (in a good way). That’s the quintessential quality of a product manager’s skill set, one that makes it hard for builder types to grok exactly what value they bring.

PMs know just _enough _of each discipline to be responsible for the entire product development system.

A product manager’s multidisciplinary awareness enables them to communicate in whatever language is necessary to effectively deliver information across the team.

They’re also in the best position to assess the impact of change across the system. A recent conversation I had withShopify’s CEO, expressed this pretty succinctly to me.

“Great product people understand how a change in the way the world works will impact the log files. And they can perceive that impact in real time.”

— Tobi Lütke[paraphrased]

Exactly right.

In a world where speed is king and the world is changing exponentially, having time to develop consensus before action is often a luxury. Teams need critical decisions made on a daily basis in order to maintain speed, and those decisions have major trade offs and/or conflicting interests among stakeholders.

Driving those decisions is no one else’s job but the product manager’s.

Why the Black Box Will Persist

Whereas the work of engineers and designers are easier quantified, because it’s difficult to observe a PMs impact over the short run, the ambiguity around Product Management will remain for some time.

One day, there may be graduate degrees and definite career paths to product management, but not today. Until then, companies will continue to scale, the world will continue to get faster, and sooner or later_“we need someone to manage this”_will get proposed.

If you’re a PM, don’t get butt-hurt the next time someone challenges your existence. Embrace ambiguity (you’re a PM, after all) and have confidence in your purpose.

作者：Kevin嚼薯片

关键字：产品经理

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！