What exactly does a product manager do all day, anyhow?

A look at a few consistent themes that unite the work of product management across job titles, industries, business models, and company sizes.

By Matt LeMay
September 29, 2017
Early Egyptian juggling art Early Egyptian juggling art (source: Oxymoron on Wikimedia Commons)

The answer to the question “what does a product manager do” depends on a lot of things. At a small startup, you might find a product manager cobbling together product mock-ups, scheduling check-in points with contract developers, and conducting informal interviews with potential users to distill and diagnose needs. At a medium-sized technology company, you might find a product manager running planning meetings with a team of designers and developers, negotiating product roadmaps with senior executives, and working with their colleagues in sales and customer service to understand and prioritize user needs. At a large enterprise organization, you might find a product manager rewriting feature requests as “user stories,” requesting specific data from their colleagues who work in analytics or insights, and attending a lot of meetings.

In other words, if you are working as a product manager, you will probably find yourself doing a lot of different things at different times—and what exactly those things are can change at a moment’s notice. However, there are a few consistent themes that unite the work of product management across job titles, industries, business models, and company sizes:

Learn faster. Dig deeper. See farther.

Join the O'Reilly online learning platform. Get a free trial today and find answers on the fly, or master something new and useful.

Learn more

You have a lot of responsibility, but little authority

Did your designers and developers miss a launch deadline? That is your responsibility. Did the product you manage fail to meet its quarterly goals? That’s your responsibility as well. As a product manager, you are the person who is ultimately responsible for the success or failure of your product—regardless of how well-supported that product might be by the rest of the organization.

Working in a position of high responsibility is challenging enough—but to further complicate matters, product managers rarely have any direct organizational authority. Is there a designer on your product team who’s showing up late to meetings? An engineer whose attitude is proving toxic to the team at large? These are your problems to solve—but you can’t solve them with the bludgeon of “because I said so” or “you’re fired.” You must lead through influence, not authority—which requires developing an entirely different set of skills and approaches.

If it needs to get done, it’s part of your job

“But—that’s not my job!” is a phrase rarely uttered by successful product managers. Regardless of whether or not it falls neatly into the boundaries of your written job description, you are responsible for doing whatever needs to get done in order to ensure the success of your team and your product. This might mean coming in early to bring coffee and breakfast to an overworked product team. It might mean insisting that you get face-to-face time with a senior executive to resolve some ambiguity around your team’s goals. And it might mean calling in a favor from elsewhere in the organization if you and your team simply don’t have the capacity to do what’s needed on your own.

If you work as a “product manager” at a very early stage startup, you might find yourself spending most of your time doing work that feels like it has very little to do with “product management” at all. Product managers I’ve known at early-stage startups have found themselves working as ad hoc community managers, HR leads, UX designers, and office managers. If it needs to be done, and it isn’t anyone else’s job, then—surprise!—it’s your job. Even at large enterprise companies, there will almost certainly be times when you need to step up and do something that is “not your job.” And, since you are likely being held responsible for the performance of your team and your product, “that wasn’t my job” plays as well at a Fortune 50 corporation as it does at a five-person startup.

You are in the middle

As a product manager, much of your job comes down to translating between the needs, perspectives, and skill sets of your stakeholders and customers. This would be challenging enough if your only goal was to synthesize this information into an actionable product plan. But as a product manager, you also sit in the middle of the people who hold these needs, perspectives, and skill sets. You have to understand their communication styles, their sensitivities, and the differences between what they say and what they mean.

Even if you are working at a highly “data-driven” organization, you still cannot escape from human complexity. In fact, the more insistent an organization is that it is “objective” or “data-driven” or “meritocratic,” the more likely you are to find yourself navigating a tangled web of unspoken resentment and unresolved conflict. Others might be able to keep their heads down and “just do their work”—but making connections is your work, so you are in it.

While product managers may find themselves doing all kinds of different work, there are a few consistent themes that also define what this role is not, often to the great consternation of people who see product management as a high-status, visionary role.

You are not the boss

I’ve often seen the role of product manager described as the “mini-CEO” of a product. Unfortunately, most of the product managers I’ve seen act like a “mini-CEO” are more interested in the status of the role than they are in the responsibility. Product managers who walk in acting like a big boss almost always lose the respect of their team, and eventually find themselves powerless to actually meet their goals. Product management punishes arrogance with a swift and brutal justice that is…well, pretty great, actually.

You are not actually building the product yourself

For some people, “product management” evokes visions of brilliant inventors and tinkerers, toiling away to bring their game-changing idea to the masses. If you like to be the person actually building things with your hands, you might find yourself deeply frustrated by the connective and facilitative nature of product management. Furthermore, what feels like a good-natured wish to get into the weeds of technical and design decisions might come off as infuriating micromanagement to the people actually tasked with building the product you manage.

You can’t wait around until somebody tells you what to do

As I learned on my first day as a product manager, it’s exceptionally rare that you will be given clear guidelines and instructions in this role. Larger companies—especially larger companies like Facebook and Google—are more likely than other companies to have a well-defined set of expectations around the product manager role that are comparatively easier to jump into. But even at those companies, you will have your work cut out for you figuring out what you should do, who you should talk to, and discovering the “unknown unknowns” that are unique to your organization and context.

If you’re unclear about a directive coming down from senior leadership, you can’t sit around waiting for them to clarify it. If you see something in a mock-up that you think will be a problem, you can’t wait until somebody else catches it. Just as you need to get out ahead of identifying the work that needs to be done, you also need to get out ahead of any disconnects in communication or understanding that might harm your project or your team, and be relentless about resolving them.

What is the profile of a great product manager?

Some organizations are well-known for favoring a certain “profile” for product management candidates. Amazon, for example, looks for MBAs. Google, on the other hand, prefers candidates with a computer science degree from Stanford. Generally speaking, the “classic” profile for a product manager is either a technical person with some business savvy, or a business-savvy person who will not annoy the hell out of developers.

While there are plenty of product managers who fit this profile to some degree, some of the very best product managers I’ve met—including product managers who cut their teeth at Amazon and Google—don’t fit any “classic” profile. The truth is, great product managers can come from anywhere. Some of the best product managers I’ve met have backgrounds in music, politics, non-profits, theater, marketing—you name it. Generally speaking, they are people who like to solve interesting problems, learn new things, and work with smart people.

Great product managers are the sum of their experiences, the challenges they’ve faced, the people they’ve worked with—and they are constantly evolving and adapting their own practice to meet the needs of the specific organization they are working with.

When I consult with organizations that are looking to identify internal candidates for PM roles, I often ask a few people to draw out a diagram of how information travels within the company—not a formal org chart, just an informal sketch of how people communicate with each other. Without fail, a few people continuously show up smack in the middle—these people are the information brokers, the connectors, the expansive thinkers who are actively seeking out new perspectives. These people rarely fit the “traditional” profile of a PM—in many cases, they are entirely non-technical. But these are the people who have already proven their capability at difficult but critical connective skills, and have often shown the initiative to take on this kind of work without much recognition.

What is the profile of a bad product manager?

While great product managers rarely fit a single profile, bad product managers are quite consistent. There are a handful of patterns they tend to fall into that are easy enough to recognize and diagnose:

The Jargon Jockey

The Jargon Jockey wants you to know that what you’re describing is really more of a level six product horizon. The Jargon Jockey is appalled that you haven’t heard of Arie van Bennekum—one of the signers of the Agile manifesto! The Jargon Jockey defines words you haven’t heard with other words you haven’t heard—and seems to use those words and terms more and more when there’s a high-stakes disagreement playing out.

The Steve Jobs Acolyte

The Steve Jobs Acolyte Thinks Differently™. The Steve Jobs Acolyte likes to lean back in chairs and ask big, provocative questions. The Steve Jobs Acolyte would like to remind you that people didn’t know that they wanted the iPhone, either. The Steve Jobs Acolyte doesn’t want to build a faster horse. The Steve Jobs Acolyte wouldn’t say that your customers are stupid—at least, not exactly—but they are definitely not visionaries like the Steve Jobs Acolyte.

The Hero Product Manager

Have no fear, the Hero Product Manager is here with an amazing idea that will save the whole company. The Hero Product Manager is not particularly interested in hearing why this idea might not work, or that it’s already been discussed and explored a million times. Did you hear about what the Hero Product Manager did at their last company? They pretty much built the whole thing single-handedly, or at least the good parts. And yet, the people at this company just never seem to give the Hero Product Manager the resources or support they need to deliver on all those amazing promises…

The Product Martyr

FINE, the Product Martyr will do it. If the product didn’t launch on time or didn’t meet its goals, the Product Martyr takes complete and unequivocal responsibility for screwing everything up (again). The Product Martyr says it’s no big deal that they pick up coffee for the whole team every morning, but the way they place the Starbucks tray down on their desk seems just a liiiiiiiiittle more emphatic than it needs to be…

The Nostalgic Engineer

The Nostalgic Engineer would way rather be writing code than stuck in all these meetings. Did you know that the Nostalgic Engineer used to write code? Really good code, too, before there was all this “jquery” nonsense. The Nostalgic Engineer is happy for the product team to work on whatever they think is most fun. Did the Nostalgic Engineer mention that they would rather be writing code than be stuck in this stupid meeting? No offense, of course.

These patterns are shockingly easy to fall into—and I’ve definitely fallen into all of them at one point or another in my career. Why? Because by and large, they are driven not by malice or incompetence, but by insecurity. Product management can be a brutal and relentless trigger for insecurity, and insecurity can bring out the worst in the best of us.

Because product management is a connective and facilitative role, the actual value product managers bring to the table can be very hard to quantify. Your developer wrote 10,000 lines of code. Your designer created a tactile, visual universe that wowed everybody in the room. Your CEO is the visionary who led the team to success. Just what did you do, exactly?

This question—and the urge to defensively demonstrate value—can lead to some epic acts of unintentional self-sabotage. Insecure product managers might start making big, awkward public displays of their contributions (the product martyr). They might start speaking in gibberish to prove that product management is a real thing that is really complicated and important (the jargon jockey). They might even start devaluing their own work for the sake of showing that they could be doing higher-status work if they wanted to (the nostalgic engineer).

For product managers, the value you create will be largely manifest in the work of your team. The best product managers I’ve met are the ones whose teams use phrases like “trust them with my life” and “make me feel excited to show up for work in the morning.” If you’re starting to feel insecure about your work, then talk to your team and see what you can do to better contribute to their success. But don’t let insecurity turn you into a bad product manager—and please, please, don’t quote Steve Jobs in a meeting or job interview.

Post topics: Design