Chapter 1. The Practice of Product Management

I recently asked Pradeep GanapathyRaj, VP of product at Sinch and former head of product management at Yammer, what he wished that every new product management hire understood about their responsibilities. Here are his answers:

Bring out the best in the people on your team.
Work with people outside of your immediate team, who are not directly incentivized to work with you.
Deal with ambiguity.

To his third point, he added, “The skill of actually figuring out what you need is probably as important as what you do after you figure it out.”

Perhaps the most striking thing about these answers is that none of them are about product, per se. Many people are drawn to product management by the promise of “building products that people love.” And, sure enough, delivering products that provide real value to real people is one of the most important (and rewarding!) aspects of product management. But the day-to-day work of delivering those products usually involves less building than it does communicating, supporting, and facilitating. No matter how much expertise a product manager might have in software development, data analytics, or go-to-market strategy, their success can only be realized through the shared efforts of the people around them—people who each carry their own complex and oft-inscrutable needs, ambitions, doubts, and limitations.

In this chapter, we discuss the real-world practice of product management, addressing a few common traps that product managers fall into when their expectations of the role don’t line up with the reality.

What Is Product Management?

These days, it can seem like there are as many working definitions of product management as there are actual product managers. All of these definitions are helpful for understanding how particular individuals and organizations think about product management. Many of these definitions contradict each other in subtle but appreciable ways. And not a single one of these definitions even begins to capture the breadth of day-to-day experiences that a single product manager is likely to encounter over the course of their career.

In a sense, product management is best understood not by a single “correct” definition but rather by the very impossibility of such a definition. In navigating the ever-growing discourse around product management, I’ve found it helpful to think less about “definitions” than about descriptions, with the understanding that any descriptive text about product management will be rooted in its author’s unique perspective and experiences.

One description of product management that I find particularly instructive comes from Melissa Perri’s excellent book Escaping the Build Trap (O’Reilly). In this book, Perri describes product managers as the stewards of a value exchange between a business and its customers. When you think about just how large, important, and complex a task that is, you start to get a good sense of why product management can be so challenging.

So what exactly is the day-to-day work of delivering on that challenge?

The answer to that question 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 prospective users. 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 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 colleagues who work in analytics or insights, and attending a whole lot of meetings.

In other words, if you are working as a product manager, you will probably find yourself doing lots 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:

You have lots of responsibility but little authority.

Did your team miss a launch deadline? That is your responsibility. Did the product you manage fail to meet its quarterly goals? That’s also your responsibility. As a product manager, you are the person who is ultimately responsible for the success or failure of your product—regardless of how well the rest of the organization supports that product.

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 team who strongly disagrees with the direction of the product? 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 threats or orders—nor can you solve them by yourself.

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 it falls neatly into the boundaries of your written job description, you are responsible for doing whatever needs to get done 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 navigating tense conversations with a senior executive to resolve ambiguity around your team’s goals. And it might mean calling in a favor from elsewhere in the organization if your team simply doesn’t have the capacity to do what’s needed on its 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 officially part of your job. And, because you are held responsible for the performance of your team and your product, “That wasn’t my job,” plays as well at a Fortune 500 corporation as it does at a five-person startup.

To make this even more challenging, most of the things you will need to get done as a product manager are not things you can do alone. You do not have the luxury of disappearing for a few weeks, reading a bunch of books, and returning fully skilled up and ready to singlehandedly deliver a product. You will need to ask for support, guidance, and hard work from the people around you—often people outside of your immediate team, who might have no obvious reason to help you out.

You are in the middle.

Product managers tend to find themselves in the middle of everything—translating between business needs and user goals, mediating conflicts between engineers and designers, and connecting high-level company strategy with day-to-day product decisions. Successful product management expresses itself in hundreds of daily interactions with the people who represent these far-flung perspectives, skill sets, and objectives. You must learn to navigate their communication styles, their sensitivities, and the differences between what they say and what they mean.

Even at organizations that are highly structured and systematized, or that claim to be impartial and “data driven,” it is inevitable that at some point you will 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 between messy, real-world people is your work.

What Is Not Product Management?

Product management can be many different things, but it is not everything. Here are a few consistent—and for some people, consistently disappointing—realities of what product management is not:

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 this honorary distinction than they are in its responsibility. Yes, as a product manager, you are responsible for the success or failure of your product. But, for you to meet this responsibility, you are entirely dependent upon the trust and hard work of your team. That trust can be easily squandered if you carry yourself like a big important boss.

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 ideas 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 who are tasked with building the product you manage.

This absolutely does not mean that you should take zero interest in your product team’s technical and design decisions. Taking a genuine interest in the work of your colleagues is one of the most important things you can do as a product manager. But product management often poses a particular challenge to those who come from the “Never mind, I’ll just go do it myself,” school of problem solving. If you, like me, are the kind of person who absolutely hated group projects in school and sought to take on as much work as possible for yourself, product management is likely to teach you difficult yet important lessons about trust, collaboration, and delegation.

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 those that have a longer history with product management, are more likely to have well-defined expectations around the product manager role. 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 how you can effectively communicate with the specific people on your team.

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. It is your job to identify, evaluate, prioritize, and address anything that might affect your team’s ability to deliver on its goals—whether or not you’re explicitly told to do so.

What Is the Profile of a Great Product Manager?

Some organizations are well-known for favoring a certain profile among product management candidates. Amazon, for example, has historically preferred MBAs. Google, on the other hand, has been known for preferring candidates with a computer science degree from Stanford. (The extent to which either of these companies still harbors these preferences is the subject of frequent debate.) 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.

Although 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, nonprofits, theater, marketing—you name it. 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, and the people they’ve worked with. They are constantly evolving and adapting their own practice to meet the specific needs of their current team and organization. They are humble enough to recognize that there will always be new things to learn and curious enough to constantly learn new things from the people around them.

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. They rarely fit the “traditional” profile of a product manager, and, in many cases, they are entirely nontechnical. But these are the people who have already proven that they have the interest and the inclination to do the challenging connective work that is key to successful product management.

What Is the Profile of a Bad Product Manager?

Although great product managers rarely fit a single profile, bad product managers are quite consistent. There are some bad product manager archetypes that seem to show up in nearly every kind of organization:

The Jargon Jockey: The Jargon Jockey wants you to know that the approach you’re describing might make sense if you were working in a hybrid Scrumban methodology but is simply unacceptable to a certified PSM III Scrum Master. (If you had to look any of that up, the Jargon Jockey is shocked by your incompetence—how did you even get this job?) The Jargon Jockey defines words you haven’t heard with other words you haven’t heard and seems to use those words 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 users 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 Overachiever: The Overachiever gets s*** done. Did you know that the Overachiever’s team shipped fifty features last year? And did you hear about the time that the Overachiever led their team through three consecutive all-nighters to keep a major product release on schedule? The Overachiever is revered by company leadership as a go-getter who can deliver lots of stuff, but it’s not entirely clear what that stuff actually achieved for the business or its users. And you can’t help but notice that the folks on the Overachiever’s team seem pretty stressed out…that is, the folks on the Overachiever’s team who haven’t already quit.
The Product Martyr: Fine! The Product Martyr (Figure 1-1) 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 Product Martyr says repeatedly that they’ve put this job ahead of everything else in their life, and yet they seem outraged and overburdened every time you come to them with a new question or concern.

These patterns are shockingly easy to fall into—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 all of us.

Because product management is a connective and facilitative role, the actual value product managers bring to the table can be very difficult 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 begin speaking in gibberish to prove that product management is a real thing that is really complicated and important (the Jargon Jockey). They might (and often do) lead their teams down a path of exhaustion and burnout just to prove how much stuff they did (the Overachiever). They might even start to make big, awkward public displays of just how much they are personally sacrificing in order to do all that stuff (the Product Martyr).

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 those who truly believe that their team’s success is their own success. These are the product managers whose teams use phrases like “I would trust that person with my life” and “That person makes me feel excited to show up for work in the morning.” If you’re starting to feel insecure about your work, 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.

No, You Don’t Have to Work 60 Hours a Week to Be a Product Manager

In the last six months, a number of people have told me, “I’d love to be a product manager, but I’ve heard you need to work sixty hours a week to do that job well.” Early in my career I would have vehemently agreed with this sentiment, maybe even offering an obnoxious addendum like “Sixty hours if you’re lucky!” But I have matured past that belief, and I believe that our discipline has largely matured past it as well.

When I reflect on my time as a 60-hour-a-week product manager, the truth is that most of those hours were driven by inexperience, insecurity, and the inability to prioritize my time effectively. I had no idea what I was doing, and I was afraid that other people would see that I had no idea what I was doing, so I set about doing as much as I could as loudly and visibly as I could (hence, my journey from wide-eyed newbie to Overachiever to Product Martyr). Not only was this approach disastrous for my mental health, it was also profoundly harmful to my team, who were left wondering if they should still be in the office at 8 p.m. while I was still there loudly sighing and clacking away at my keyboard.

During my most effective and impactful years as a product manager, I was working from 10 to 4 most days—and yes, this was at a fast-paced, high-growth startup. With the help of some extremely talented colleagues (and an extremely good therapist), I was able to prioritize the tasks that were helping my team achieve its goals and stop worrying so much about whether my colleagues thought I was working hard enough. It turns out that nobody (aside from myself) was keeping meticulous tabs on how late I stayed in the office on a given Friday night or how quickly I responded to a Sunday morning Slack message.

Anybody who has done the hard work of learning to set boundaries and prioritize their time will be, and should be, put off by the idea that any job will require them to work an unreasonable and unhealthy number of hours. And the field of product management desperately needs more people who have done the hard work of learning to set boundaries and prioritize their time. The idea that long hours are an inextricable part of the job discourages talented people from entering the field, and it discourages those already in the field from learning how to prioritize their time and set reasonable and healthy expectations for their teams. Let’s get over it.

What About Program Managers? Product Owners?

Nearly every time I teach a workshop about product management, the first question I get asked is some version of “What’s the difference between a product manager and a (program manager/product owner/solution manager/project manager)?”

It’s not hard to understand why this question is top-of-mind for so many people. As the constellation of similar-sounding product and product-related titles continues to grow, clarity around role and purpose can be harder and harder to find. If you’re a product manager on a team that’s suddenly hiring a program manager—what does that mean for you? Is your job being rendered obsolete? Is somebody else going to be doing the same work as you? And, not to be tacky but, hey, who’s getting paid more?

When I started doing product coaching and training, I did my best to definitively answer these questions using a combination of past experience and frantic googling. I would say with great confidence, “Well, in most situations, the product manager is the person who’s accountable for the business outcomes the team delivers, and the product owner is the person who’s in charge of managing the team’s day-to-day activities.” Nods of recognition! Sweet relief! A specific, concrete answer!

It only took a couple of weeks for me to find myself working with an organization that defined these roles in the exact opposite way. As I started to give my boilerplate answer to this very same question, an executive interrupted me and said, “Um, we actually define it kind of the opposite here. After all, why would we call the person who manages the team’s activities the product owner, and the person who owns the product’s outcomes the product manager?” Needless to say, “Because that’s what it said when I googled it” was not a great answer.

Since that fateful day, I have found myself providing a very different, much less immediately satisfying answer: “It varies enormously from organization to organization and from team to team. Some organizations define the difference one way, and others define it the exact opposite way. Talk with the folks at your organization to find out how they think about the role and what their specific expectations are for you.” Fewer nods, less relief.

I’ve started thinking about the ever-expanding list of “pro**** ******er” titles as Ambiguously Descriptive Product Roles (ADPRs), in the interest of having a banner concept to encompass the myriad job titles that likely won’t tell you all that much about your day-to-day activities and responsibilities. For ADPRs whose teams include other ADPRs, I find myself offering the following, similarly disappointing advice: “Sit down with your fellow ADPRs, figure out what needs to be done, and figure out how you’re going to do it together. Focus on your shared efforts, rather than trying to establish absolute nonoverlapping clarity around your titles.” As an ADPR, you will likely never have absolute clarity about what exactly your job entails. Ask lots of questions, work closely with your team, and stay focused on doing the most impactful work you can.

I find myself offering the same advice when asked about specialized ADPR titles such as “growth product manager” or “technical product manager.” I have deeply mixed feelings about the increasing specialization of product manager roles. At best, this trend could help create a little more clarity around what is expected of people working in a specific role at a specific company. At worst, it could become another source of false certainty that obscures the inherent generalism of product roles. (I’ve already overheard my first “Well, that person has only worked as a growth product manager—do you think they’d be able to cut it as a regular product manager?” conversation, and I fear there are many more to come.)

Long story short: every single product job on every single team at every single company is a little different. The sooner you truly embrace this, the sooner you can get to the hard work of doing your specific product job as best you, specifically, can.

Summary: Sailing the Seas of Ambiguity

No matter how many books you’ve read (including this one), how many articles you’ve scrolled through, or how many conversations you’ve had with working product managers, there will always be new and unexpected challenges in this line of work. Do your best to remain open to these challenges and, if possible, enjoy the fact that the ambiguity around your role means that you are likely to learn lots of entirely new things.

Your Checklist

Accept that being a product manager means that you are going to have to do lots of different things. Don’t become upset if your day-to-day work is not visionary and important seeming, so long as it is contributing to the goals of your team.
Be proactive about seeking out ways that you can help contribute to the success of your product and your team. Nobody is going to tell you exactly what to do all the time.
Get out ahead of potential miscommunications and misalignments, no matter how inconsequential they might seem in the moment.
Don’t get too hung up on the “typical profile” of a successful product manager. Successful product managers can come from anywhere.
Don’t let insecurity turn you into the caricature of a bad product manager! Resist the urge to defensively show off your knowledge or skills.
Measure your success by the impact you’re having on your business, your users, and your team—not how many hours you’re working.
Stop looking for a single “correct” definition of any Ambiguously Descriptive Product Role (such as product manager, product owner, or program manager). Acknowledge the uniqueness of each product role on each team and ask a lot of questions to understand what’s expected of you specifically.
If your team has multiple Ambiguously Descriptive Product Roles (say, a product manager and a product owner), work with your fellow ADPRs to align on your shared goals and figure out how best to work together toward achieving those goals.