🎩 What’s a Product Manager, Anyway?
This article was originally published at iterator.substack.com
Glance around the web and you might find a lot of articles on product management (PM). Product roles seem to be on more people’s radar in recent years, so unpacking it seems like an evergreen topic.
I’ve gotten my fair share of questions about it since landing a PM role so I thought I’d write a primer. I’ll be linking resources along the way for those that want to dive a bit deeper.
I. What It Is
Product Management is a lot of things. On a high level, I like to think of it as the strategy and execution of a product for the benefit of the customer. The customer should be the driving force for the choices made on how to improve the product, since they are the ones using it: there’s no use in building something that won’t be used. The strategy encompasses deciding what to build and why, while the execution involves the how.
Another way of thinking about PM is as the intersection of User Experience, Technology, and Business:
- User Experience (UX) deals with how the customer interacts with the product. Not just how it looks, but how natural it feels to use.
- Technology is often the enabler for great products. Not just in software, but sometimes in hardware or services.
- There are a lot of other duties for a PM, from ideating and testing to marketing and sales. Safe to say that the Business bucket is quite large.
With a lot of ways to describe the role of a PM, I thought I’d write an example scenario:
A PM has an idea for a new product, or a new feature within an existing product (let’s just call it a product for simplicity’s sake). Reaching out to users should be one of the first things they do so they can make sure this new product will be useful and used by the end users ( these don’t always overlap).
After talking to users and realizing that the product might be worthwhile, the PM can further investigate what exactly would be needed to implement it, and who could help make it. See, PMs rely on other specialists to bring a product to life: while they are generalists themselves and have a foundational understanding of what’s needed, it’s these specialists who make the product real. PMs coordinate them in a cross-functional team and ensure everyone’s heading in the right direction.
There are a lot of roles that can be represented in a product team, as thoroughly explained by Will Lawrence. Here are a few I often interact with:
- User Research
- User Experience
- User Interface Design
- Development
- Quality Assurance
- Marketing
- Others (Sales, Legal,…)
I mentioned above that the PM noticed that a product might be worthwhile, but one can never be 100% sure until a fully fleshed out product is being used and paid for by a large number of people. The fact of the matter is that there are a lot of hypotheses and assumptions in making a product, and the journey of validating and refuting these is crucial to a successful product being launched. In that vein, it’s always best to take small steps so that the least amount of resources are spent in testing these assumptions.
By this point, the PM would want to get stronger evidence in favor of the product. They might build anything from a proof of concept, which can be a small exercise, up to a minimum viable product, which is the leanest version of a product that tests the core of a concept with real users. The right one to build depends on the product development stage, the resources available, or the scope to be tested.
Afterwards, the PM should pay very close attention to the feedback coming from the end users. This can help the PM further refine the offering and make sure users are gaining value from the product. A lot of work happens in this feedback cycle, and the improvements made here can make a world of difference to the users.
I should mention that the scenario above is only a tiny window into the work of a PM. Since the product field isn’t as regulated as others, there’s a lot of latitude in what a PM can work on: the product type, its stage in the product lifecycle, or the type of company can heavily influence the work that a PM does.
For example, a fintech PM can have different priorities than an ecommerce PM. A PM working on a pre-launch product will be focused on different tasks than a PM working on a mature product. And different product cultures can place different emphasis on the user experience vs. the engineering prowess of the product, for example. What tends to remain constant is the PM bringing the voice of the customer into the product’s planning and development.
In fact, PMs can have such broad responsibilities that sometimes it’s safer to assume that they should do anything that doesn’t fall under the purview of any other team member. Ken Norton put it beautifully as “bringing the donuts”, a read I couldn’t recommend enough.
II. What It Isn’t
That being said, PMs aren’t the “CEO of the product”. It’s an analogy that proves itself useful to the uninitiated, but falls short once you take a closer look. PMs don’t do a lot of things that fall under the purview of CEOs, like handling human resources or poring over financial statements.
PMs are also not the boss of their team. The interesting thing about cross-functional teams is that everyone reports to their functional supervisor (e.g. engineers to their engineering manager). This is where we get to one of the unique details about PMs: they have to lead by influence rather than authority. It’s their job to convince everyone that their direction is the right one, or let themselves be convinced by the subject matter experts. At the end of the day, PMs are also individual contributors to the team.
On a different note, PMs are often confused with the following:
- Project Management
While the golden triangle of scope, cost, and time are usually on most PMs’ minds, PjM is more about managing the resources needed for a project to happen than driving the strategy and execution of said project.
- Program Management [1]
Managing multiple projects with a commgon thread. See above.
- Product Owner
Coordinating the execution of a digital project. It’s a part of what a PM does, but it’s definitely not all there is to it.
There’s a lot more to these comparisons, but suffice it to say that these other roles don’t focus on directly bringing value to the customer in the same way a PM does. [2]
III. Why It Matters
Hopefully the importance of product management has made itself apparent by now. What I should also mention is that while the duties of a PM are non-negotiable for a successful product, teams can and do succeed without one. In those cases, these duties are taken up by different members of the team. This can work well in the beginning, but with enough scale and momentum the need for a dedicated PM can make itself known.
On a closing note, the job of a PM can be incredibly diverse and fulfilling, which is why there’s been an increasing interest in knowing more about it. In this newsletter I’m hoping to bring more of it to light, so feel free to subscribe for more on this and other topics.
[1] - The exception to this is Microsoft: they call everyone a Program Manager and one needs to look closely at the job description to suss out which one they mean. It’s not clear why they stick with this method.
[2] - It doesn’t make these roles any less important, though.
