If I could sum up what a product manager does, it’d probably be:
Strategy tends to pose questions, then answer them:
You might think of this as covering the surface area of the problem domain. For the most part, this takes domain expertise, critical thinking and clear communication (which I wrote about here).
It involves a generative process of hypothesizing anything which could be relevant to the task at hand, followed by a selective process of curating what’s most important.
Most “strategic” work begins with brainstorming sessions, diagrams and outlines sketched onto paper, countless emails back-and-forth, and written memos formalizing a course of action.
Execution, on the other hand, is not about asking or answering questions, but rather implementing what has already been asked and answered.
Execution is highly technical, low-level and deeply involved with domain-specific tooling. It’s about realizing what has already been specified.
When it comes to software products, execution tends to involve:
For the most part, product managers don’t execute directly.
Instead, they facilitate execution.
Developers, for example, might have concerns about the technical feasibility of what’s required. They may not understand the specifications completely. Or they may write code in such a way that creates dangerous dependencies and accumulates technical debt.
A product manager needs to answer questions that developers have, or anticipate problems before they arise.
Now you might wonder: how could a product manager possibly understand the code (“development”), guide the interface design (“design”), survey and work with users (“UX”), and help market the product (“marketing”)?
Typically, product managers have certain specialties. There are:
Technical product managers tend to have engineering backgrounds. UX product managers tend to have design backgrounds. And product marketers tend to have marketing backgrounds.
This of course doesn’t mean that product managers are doing all the engineering, design and marketing, respectively. But they must be deeply familiar with them in order to understand the domain-specific problems which inevitably arise.
More commonly, product managers serve as a fallback for team members doing actual execution.
If developers, designers and marketers don’t know exactly how to do something, the product manager is responsible for figuring it out. Sometimes, this means changing the requirements to something more straightforward. Other times, it means coming to a creative solution that people in the weeds may not have thought of.
In every case, the product manager is ultimately responsible for delivering.
If there are technical bottlenecks, the technical product manager needs some way to solve them. If users are dissatisfied with the product, the UX product manager needs some way to solve them. And if people don’t discover or understand the product, the product marketer needs some way to reach them.
Another way to think of the product manager is doing all the stuff that others think is out of their purview.
Should the developer be creating S3 accounts, purchasing SSL certs, or trying to figure out exactly what a designer wants? Should a UX designer be purchasing Adobe licenses, or coordinating with developers on exactly which API fields go where?
Here, product managers fill in the gaps and, ultimately, deliver.