Product Management in Practice: A Practical, Tactical Guide for Your First Day and Every Day After

by Matt Lemay

real-world guidance would be very, very hard to come by.

Product management in theory is very different from product management in practice. In theory, product management is about building products that people love. In practice, product management often means fighting for incremental improvements on products that are facing much more fundamental challenges.

In theory, product management is about triangulating business goals with user needs. In practice, product management often means pushing relentlessly to get any kind of clarity about what the business’s “goals” actually are.

In theory, product management is a masterfully played game of chess. In practice, product management often feels like a hund...

Successful product management is much less a question of titles, tools, or processes than it is of practice.

More often than you’d probably imagine, even C-suite product leaders don’t have nearly as much influence as they’d like over how their organizations think about product development more broadly. As we will discuss at length later in this book, hand-wringing about how your organization “doesn’t do product right” is more often than not a huge waste of time—and a stressful one at that.

Product managers are much more likely to share “war stories” than “best practices” and are more likely to talk about the mistakes they’ve made than the meteoric successes they’ve achieved.

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 amb...

“The skill of actually figuring out what you need is probably as important as what you do after you figure it out.”

the stewards of a value exchange between a business and its customers.

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...

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.

“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.

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.

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.

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.

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.

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.”

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.

Get out ahead of potential miscommunications and misalignments, no matter how inconsequential they might seem in the moment.

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.

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.

A product manager must be able to: Communicate with stakeholders Organize the product team for sustainable success Research the needs and goals of the product’s users Execute the day-to-day tasks required for the product team to meet its goals

The guiding principle for communication is “clarity over comfort.” The choice between clarity and comfort is a real one, and one that we are often faced with at the most important moments of our career.

Here are a few questions you can ask yourself to evaluate your communication skills: Am I asking the necessary questions and facilitating the necessary conversations to make sure my team has clarity on what we are doing and why? Am I proactively reaching out to other product teams and managers if I believe that coordination will help deliver better user and business outcomes? Am I responding promptly and thoughtfully to stakeholders who reach out to me? When exploring potential solutions, am I consistently presenting multiple options and walking stakeholders through the trade-offs of each one?

product managers who excel at organization see the question “What should we be working on right now?” as a sign that something is broken.

When something goes wrong, organization-minded product managers don’t just ask, “How can I solve this problem right now?” but also, “How can I make sure this doesn’t happen again?”

The guiding principle for organization is “Make yourself obsolete.” Product managers who excel at organization work with their teams to organize people, processes, and tools into self-sustaining systems that do not require their moment-to-moment participation or oversight.

Here are a few questions you can ask yourself to evaluate your organization skills: If I were to go on vacation for a month, would my team have the information and processes in place to prioritize and deliver without my day-to-day participation? If I were to ask anybody on my team, “What are you working on and why?” would they all have immediate and consistent answers? If somebody on any other team wanted to know what my team was working on, would they be able to easily access that information in an up-to-date, understandable format? If a particular process or system (or lack thereof) is not working for my team, am I proactively working with my team to change that process or system? Or, if we are not in a position to directly change that process or system, am I proactively working with my team to change how we interact with that process or system?

The guiding principle for research is “Live in your user’s reality.” Every product has a user—whether it’s a consumer, another business, or an engineer utilizing an API.

The most successful product managers I’ve met understand not only how users interact with their product but also how the product fits into users’ broader reality. When these product managers evaluate a competitor’s product, they ask, “What might this product mean to our users,” not, “How can we achieve feature parity?”

Here are a few questions you can ask yourself to evaluate your research skills: Is my team learning directly from our users/customers at least once a week? (This is Teresa Torres’s most excellent definition of continuous discovery.) Is every product decision my team makes informed by both business goals and user needs? Is my team regularly using both our product and competing/adjacent products to better understand our users’ needs and behaviors? Do the user needs and goals articulated by my team actually reflect the needs and goals of our users, or just what the business wants those needs and goals to be?

Here are a few questions you can ask yourself to evaluate your execution skills: Is my team starting with the customer and business impact we seek to drive and then evaluating and prioritizing multiple ways to achieve that impact, as opposed to starting with features and retroactively justifying them by estimating impact? Are my team’s strategic goals and objectives front and center during tactical conversations and activities (like sprint planning, story writing, etc.)? Am I prioritizing my own time in a way that reflects the goals and priorities of my team? If I do not have the capacity to do the work that my team needs without burning myself out, am I communicating that directly to my manager?

“I’m curious to learn more about the work that you do” is the most powerful sentence at your disposal as a product manager, whether it’s your first day or you’ve been working in the field for decades.

Learning about hard skills from the people tasked with applying those skills ensures that you will learn about the specific hard skills that are most important to your organization right now—and that you’re doing so in a way that directly strengthens your bond with technical folks.

If you only talk to people when you need something from them, nobody will be particularly happy to hear from you. Build relationships with people before you need something from them, and those relationships will be there for you when you need them.

The people you reach out to each have their own networks of trust—people they talk with “off the record” and from whom they are willing to call in favors when needed. By reaching out to folks in your organization beyond the people you are working with every day, you’re building a far-reaching network that might lead you to places you never expected.

Large companies have a veneer of formality that startups usually don’t, but that doesn’t mean that things are linear or predictable. Startups are often much more candid about their challenges: “This is messed up; let’s fix it.” At a large company, it can take months to get people to open up and speak candidly about the challenges they’re facing.

Part of the challenge at a big company is that the higher-ups usually aren’t the people who understand what’s really going on.

I needed to have core partnerships with folks within editorial, design, engineering—these very established orgs within the bigger organization.

I was genuinely surprised by how much of my on-the-ground work as a product manager at a large organization happened through back channels. I thought that all the action would be taking place in a big conference room—but really, it’s all about getting people’s buy-in outside of those formal settings, which I didn’t expect.

If you are going to succeed as a product manager, you must be willing to engage deeply with people whose knowledge and expertise in a specific area greatly exceed your own.

(In fact, you’re much more likely to succeed as a product manager if you stop trying to figure out who the “smartest person” might be in any room.)

When I have sought to defend my team against executive interference, I’ve created a dangerous divide between their work and the business’s goals (we’ll talk about this more in Chapter 5). When I have sought to defend my decisions against probing questions, I have missed out on critical information that would have made those decisions better. And when I have sought to defend myself against the feeling—real or imagined—that I am underrecognized or underappreciated by my colleagues, it has made me appreciably worse at my actual job.

There’s been a lot of talk about how saying no is key to product management, but the best product managers I work with never have to say no—they just provide a set of options and help their teams (and especially their team and company leadership) choose the best one according to their goals and objectives.

Even the most experienced and even-keeled product managers will still sometimes find themselves digging into a yes–no argument or refusing input and feedback from stakeholders who possess mission-critical information. The challenge is to get to a place where you can recognize your own defensive reactions, acknowledge that they are unlikely to lead to better outcomes for yourself or your team, and bring yourself back to a place of openness and curiosity as best you can.