PMs get sad when you ask them why they exist
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.
Product Management is the by-product of two exponential forces being exerted on a company.
- Speed: The company exists in an industry where the rate of technological innovation is accelerating
- 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.
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.
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 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?
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:
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 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 with Shopify’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.
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.