People often ask me what a product manager does. I get this question from engineers who want to broaden their skillset, business school students interested in tech and product development, and new college grads thinking about their first jobs out of school. Occasionally, I hear from management consultants and finance professionals interested in product management.
The first question they ask is, what does a product manager actually do? To be frank, I used to wonder the same thing. During my years as a software engineer, I never quite understood what my PM actually did. I saw some PMs write specs after the feature or code had been built (value added!). Other PMs basically ran bug triage or release management. I remember a triage meeting in which me and my dev lead had come to war room to ask for approval to fix a bug late in the beta stage. “War room” was the meeting in which the trio leads (Eng, PM, Test) would decide which bugs are severe enough to fix, and which can be punted. This was an operating system team, and every bug fix has a regression risk factor associated with it. During beta and later, if the team did not get into a “Won’t fix” or “punt” mode, the product would never converge, so it was common in later phases to not get approval for minor fixes. In this meeting, a PM completely unrelated to my team was tapping away at her laptop without paying attention while we explained to the room why this fix was not puntable and why the regression risk was extremely low. When it came time for the directors to make a decision, she glanced up, made a generic “This seems too risky” comment, and then went back to her laptop. It was clear that she had absolutely no idea what the feature and bug were about. If that’s all PMs did, it was definitely not a job I wanted!
It was not until business school and a stint in management consulting, that I realized what a company with a good PM culture is like, and what a PM should be doing to add value to their teams. There are a number of roles that product management sometimes fills, but should not be the core of the job.
Myths on what a PM does
Solely project management. Every PM will do some project management either as an integral part of the job, or as a gap filler. Similarly, things like “scrum” and “kanban boards” are not the PM’s core responsibility. The TPM or the engineering manager should do this on their own. At some companies, project management is a specialized role, sometimes called a “Program Manager” (PgM) or a “Technical Program Manager” (TPM). Note that at Microsoft, a “Program Manager” maps to a “Product Manager” role at most other tech companies. Mature teams have dedicated TPM/PgM organizations. On newer teams, the PM will often fill the project management role (although a savvy PM will push this to the engineering manager). On all teams that I have seen, the PM should own project management with cross-functional teams (business development, legal, marketing, privacy). The key point is that project management alone should not suck up the PM’s entire bandwidth.
Release management should not fall on the PM either. At some companies, a subset of PMs are “Release PMs” and are primarily responsible for overall team schedules, bug bars, code release processes, etc. Release management should be covered by TPMs/PgMs.
Note taking. Some engineering teams that have never worked with an effective PM before assume that the PM is there to take notes for them. Run away as fast as you can from such teams! At some point in your career, you may work with an engineering team that does not appreciate the value that a PM brings to the table. Learning how to gain the respect of such a team is an important skillset, but ideally, you will work with engineers who understand and appreciate your contributions as a PM. PMs taking notes for engineers is not an efficient use of company resources.
Marketing. At Apple, product managers are actually marketing managers in most teams. The PM role at Apple is very different from the canonical modern PM role that was created at Google in the early aughts.
A lot of traditional advice on product management state that the PM’s job is to “do whatever needs to be done to ship the product”. That might mean project management, note taking, engineering management, getting donuts, and more. This is certainly true and I have done all of the above to make sure my engineering teams can focus and ship. I’ve hand delivered cake and beers from the microkitchen to my engineers’ desks when they’ve been in crunch mode. The buck for a product launch stops with the PM and PMs who think note taking or project management is “beneath” them are not PMs you want on your team. However, the key difference is that these tasks are not what a PM is rewarded for. As a team grows and scales, the company’s return on investment in the PM is higher if the PM can scale herself by building / hiring / delegating these tasks.
So what should a PM do instead?
In my mind, an individual contributor PM has four “big boulder” responsibilities. I’ll talk about a manager PM’s responsibilities in a different post.
- Vision
- Strategy
- Leadership
- Execution
Vision
It is the PM’s job to set a compelling vision for their engineering team. This sounds fluffy and unnecessary, but it is critically important to align large organizations. The vision is what individuals buy into. It is how you get people motivated and excited to come into work every day. It is how you get through the inevitable set backs, schedule delays, organization politics (inevitable at every company, no matter how small), poor market reception, and more.
How does one set a compelling vision? This is a hard skill to develop. I’ve personally found it to be the skill that comes least naturally to me. I have had to work at it, and it’s a work in progress. As you progress in your career though, it becomes progressively more important.
Strategy
Strategy is also the PM’s job. The definition of strategy varies from company to company. I always find it amusing when someone says something like “What is our strategy for this sprint?”. Strategy, in my definition, is a set of immutable principles or a “guidebook” that enables an organization to achieve its vision. A well-set strategy should be durable to short term ups and downs or market changes. A team that changes its strategy in response to every competitor’s every minor announcement, does not have a strategy (and probably does not have a vision they believe in either).
Leadership
It sounds cliched, but an IC PM is a leader in the larger organization. They do not have direct reports, but the engineering teams, cross-functional teams, partners, and even your boss, will look to you for leadership. What does leadership mean for an IC PM? This is a subject for multiple posts, but it always involves a few key things. The PM should provide stability and confidence to the team. The PM should either made decisions quickly or escalate to the right stakeholder who is able to make the decision. The PM should build a team culture of “everybody grab a shovel” by being the first in the shovel line. These are the times when it is important for the PM to gap-fill any job not being covered by someone else.
Execution
Execution means the day-to-day tasks you do to “run” the strategy in order to achieve the vision. Writing product requirement documents (PRDs), running user studies with the UXR team, gathering market data with the marketing team, running partner meetings with the BD team, building consensus with the engineering team and partner engineering teams across the company, and so on all fall under this bucket. 70% of your time as an IC PM will fall in this bucket, but it is important to not let it take 100% of your time. As you progress in your career, you get more rewarded for the vision, strategy, and leadership, and execution becomes table stakes. This means you still have to knock execution out of the park, it’s just that you don’t get promoted for awesome execution (yes, life is hard).
In future posts, I’ll talk about each of these big boulders and how to excel at them.