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

by Matt Lemay

For example, I tend to have much better conversations when I say something like “That looks awesome! Could you show me how your team came up with the idea?” as opposed to “Why are you building that?” This framing puts the asker in the position of a student, not an inquisitor.

The potential downside of undercommunicating is cavernous and terrifying. The potential downside of overcommunicating is, realistically, a few eye rolls and maybe some snarky comments. Since you can never be sure of the exact right amount of communication called for in any situation, you are always better off erring on the side of overcommunicating. In theory, at least, this is an easy one.

When you are a product manager, there will be times when you need to ask people to do things that they don’t want to do. If these things are mission critical for your team’s success, help your team understand why and work with them to figure out what other tasks can be deprioritized. And if they are not mission critical for your team’s success, ask yourself whether you are thoughtfully prioritizing your team’s time or just saying yes to anything that seems vaguely important.

Yes, as a product manager, you are ultimately responsible for the outcomes delivered by your team. But this is not a responsibility you can bear alone. If you take everything that goes wrong as your own personal failure, you are depriving your team of a critical opportunity to learn and grow.

If I feel the urge to make a self-deprecating comment, I ask myself: “If somebody on my team interrupted me to say, ‘Hey, no need for that. You’re doing a great job, and we respect your opinion,’ would I be relieved or annoyed?” If the answer is “relieved,” then I try to facilitate an open retrospective with my team to see if there are some other underlying issues that might be causing me to feel a lack of confidence in my work. If the answer is “annoyed,” then I ask myself what difficult question or conversation I might be trying to deflect through self-deprecation, and I try to muster the courage to proactively bring that question or conversation to my team.

While I was ostensibly seeking feedback from these stakeholders, I was really looking for a simple gesture of approval—a checked-off box that would effectively cover my ass in the event that things went sideways later.

stakeholders—especially executive stakeholders—are very busy people, and that quick nod in a meeting or “Got it, thanks,” email doesn’t necessarily mean they were paying attention to your point of view, let alone meaningfully engaging with it. In the world of product management, anything short of affirmative and specific buy-in is incredibly dangerous. And no two words better embody disengaged, ambiguous, and vague non-buy-in buy-in than “Looks fine.”

By contrast, you are much more likely to get engaged responses from an email that says, “Attached, please find our roadmap for the next quarter. As you will see, we are considering two different options for sprints 6–8. Could you please let us know by the end of day Friday which one you believe would be more relevant to your team’s goals?”

disagree and commit doesn’t resolve all the disconnects and miscommunications that can occur in an organization, but it can help surface those disconnects and miscommunications in a more timely and productive manner.

So, what if people simply won’t commit to a path forward? This is, believe it or not, a great sign. It means that the people in the room are engaged enough that they will not commit to something that they think is wrong. One way to move this conversation forward is to establish success criteria and plan to revisit the decision later.

I almost can’t believe I have to write this, but in a few cases, people have taken the idea of disagree and commit to the ridiculous extreme of flat-out barking at their colleagues, “IT DOESN’T MATTER IF YOU AGREE WITH ME—WE ARE DOING DISAGREE AND COMMIT.” Remember that the purpose of disagree and commit is to surface hesitations, concerns, and questions that might otherwise go unspoken. If your implementation of disagree and commit berates would-be dissenters into submission, you are doing it wrong.

In his book Death by Meeting (Jossey-Bass), Patrick Lencioni makes a great point about meetings: if people approach them with a bad attitude, no amount of procedural tweaking is likely to make them better. The same holds true for email and other forms of asynchronous communication. If you train your colleagues to think of your emails as a nuisance, they will treat your emails like a nuisance. If you complain about being “overwhelmed” with incoming messages, your colleagues will probably think twice before looping you into a conversation that may prove critical for your team’s success.

You were hired to be a communicator, while somebody else may have been hired because they’re really good at math or have great relationships with vendors. Communication is your job, and you can’t expect everyone else to be good at it. My two favorite questions are “What are your goals?” and “What are you optimizing for?” I use them often and with great sincerity, and my product manager life (and non–product manager life!) is much better off because of it.

the most important decisions you make as a product manager will often come down to this simple question: are you willing to bring up something that might seem obvious, uncomfortable, or both? The more fearless you are about starting these conversations—and the more space you create within your team and organization for these conversations to play out—the more successful you and your team will be.

For better or worse, senior stakeholders often have access to important high-level information about the business that you simply do not. Based on this information, they might override your priorities or shift those priorities when you’re midway through a project. They might even wield the bludgeon of “because I said so” if they can’t reveal the sensitive details of conversations that are playing out between themselves and other senior stakeholders. In short, senior stakeholders will always win the poker game. Your mission, should you choose to accept it, is to ensure that your business and your users win along with them.

But I’ve cooled on the word influence in the past several years, largely because I have seen too many product managers attempt to “influence” senior stakeholders toward a predetermined path by cherry-picking information, omitting risks and assumptions, or overpromising around both timelines and outcomes. In many of these cases, successfully “influencing” senior stakeholders is seen as a win, even if that “win” yields dubious results for the business and its users.

One of the things that I feel has contributed the most to my career as a product manager is having the courage to push back and to have challenging conversations.

Help senior leaders understand that the decisions they make aren’t made in isolation—help them see the “invisible” work that they don’t think about when they decide that they want a new feature. Give them options and make them aware of the trade-offs of each approach. Always make sure that the decision is in their hands—that they have ownership. That way, it’s not an us-versus-them situation—it’s just us.

But when there’s a fundamental mismatch between what the business wants and what your team wants, you can’t resolve it by ignoring the business in the name of “protecting” your team.

nothing that you are telling a senior stakeholder in a “big” meeting should ever be a surprise, ever. There are many reasons why it is always a good idea to individually walk senior stakeholders through a new idea before you present it in a group setting. But, to return to the heavy-handed metaphor at the heart of this chapter, a senior stakeholder is always going to win the poker game. And if you’ve taken the time to ensure that every senior stakeholder in the room is invested in an idea that is truly beneficial for the business and its users, then the odds are very good that, whichever senior stakeholder wins this particular hand, the business and its users will win along with them.

If you build something that your boss and your boss’s boss like but falls short of delivering any real value to your users, then you are failing to follow one of our guiding principles of product management: “live in your user’s reality.”

Working with senior stakeholders is a particularly challenging and high-stakes part of a product manager’s job. There can be times when these stakeholders—especially founders and executives—seem to have an incredible amount of control over your fate and destiny. But remember, executives are people too, and they can fall into the same traps of self-doubt and defensiveness that you do. Help them make the best decisions they can, learn from their experiences, and stay patient and curious.

When working with senior stakeholders, don’t set out to “win.” Help empower them to make great decisions and demonstrate that you can be a valuable and supportive thought partner.

Don’t let company politics drown out the needs of your user. Let user needs guide your decision-making, and bring the user’s perspective to life in meetings with senior leaders.

Early on in my career as a product manager, I straight-up threw a fit when a UX designer I worked with suggested that we create some user personas: Yeah, um, I don’t have to make up a bunch of fake users because I understand our real users, thank you very much. For all of my attempts to sabotage and undermine the efforts of my persona-peddling colleague, I actually wound up finding this tool quite helpful. Yes, we were building for “fake” people (composited from interviews with real people). But having anybody other than ourselves in mind, and having the ability to distinguish broadly between different sets of user needs, helped us make better decisions and ultimately deliver better products.

Much of this tension comes from the simple fact that product managers must balance user insights with business goals, executive whims, delivery timelines, and all the other things that make “user centricity” so challenging in practice. From a researcher’s point of view, this can leave product managers looking like deadline-obsessed, customer-ignoring corporate toadies.

Reducing product management to a set of repeatable best practices means wishing away all of the messy, unpredictable, and truly unavoidable human complexity that must be navigated in the role. Product managers who rely too much on best practices become deeply incurious about the people they work with—and sometimes even the product they’re working on.

Nearly every published case study about “best practices” concludes with a business equivalent of “and they lived happily ever after,” “and the business sold for a bazillion dollars,” “and the company exceeded its Q4 revenue goal by $700k,” or “and the team achieved 100% adoption of a scaled Agile framework.” But in real-world organizations, there is no “happily ever after.” The business that was sold for a bazillion dollars might be completely dismantled by its new owners, the company that exceeded its revenue goal might go out of business in a year, and the team that achieved 100% adoption of a scaled Agile framework might be using that framework to deliver completely worthless features.

Initial conversations about best practices are often full of optimism and hope. But as these best practices inevitably run up against an organization’s existing habits and rhythms, this quickly gives way to fatalism and frustration. Why aren’t these best practices working for us? Whose fault is this? Who doesn’t get it?

The very things that make an organization unique wind up being seen as unstoppable impediments to change, rather than guiding the ways in which change is implemented.

Most case studies about “best-in-class” companies are, to put it bluntly, recruiting propaganda. Companies that are competing for product and engineering talent have very little reason to paint an accurate picture of their workplace situations, let alone an even remotely negative-leaning one.

“Focus on the product, the team, and your mental health—and don’t worry so much about whether your organization is doing product management ‘the right way.’”

There might be times in your career where you go from a more empowering environment to a more constrained environment. There might be times in your career where you need to completely rebuild a team’s trust. There might even be times in your career where what looks like a “promotion” on paper actually feels like a step backward in terms of your responsibilities. It’s natural to get lost in the downside from time to time, but this often is where the sneaky, fun part of product management happens. Long after these imperfect moments in your career, you will see how you made an impact even when you didn’t feel like you were empowered to operate at your full capabilities.

The truth is that all organizations have some fixed constraints to work within. Those constraints might be a function of their business model, their scale, or the attitudes and experiences of their leaders. And the sooner you acknowledge and understand those constraints, the sooner you can do your best work within them. Recognizing that your particular organization’s fixed constraints are unlikely to change—or at least that you are unlikely to change them—allows you to refocus your attention on all the things you and your team can do to deliver value to your users. I’ve come to think of this process as “falling in love with reality.”

All that energy you’re putting into raising the ceiling is energy that you are not putting into delivering value to your users. And while that low ceiling may very well mean that you can’t deliver as much value as quickly or efficiently as you’d like, there is likely room to deliver a whole lot more value before you find yourself completely boxed in.

once you fall in love with reality, the work of product management gets so much easier. When you give up on the idea that there is such a thing as doing product management “perfectly,” or even doing product management “right,” you can begin to focus on how you do product management effectively within your own unique context and constraints. (And yes, there are always constraints.)

Sure, no working product manager I know has ever used a business model canvas to fully invent a new product from scratch in a real-world organization. But many product managers I know have used the ideas from a business model canvas to focus and sharpen their thinking in advance of a product ideation session. Similarly, no working product manager I know has ever told me that their organization is taking a perfectly by-the-book approach to “minimum viable product,” a core concept from Eric Ries’s book The Lean Startup (Currency) that has become ubiquitous in the world of product development. But many have told me that the conversation around “minimum viable product” helped their organization ask some really important questions about how often they are learning from their customers and how they are defining “done enough.”

It’s about really just iterating on your process constantly. When it doesn’t work, you figure out why it doesn’t work, and you try something else. It’s always a process to get to your process.

Avoid the temptation to solve the problems that seem the most familiar to you, as opposed to the problems that are having the most impact on your team and your users.

Similarly, the reasons why Agile doesn’t work often have more to do with common sense than with fiddly distinctions between frameworks. For executives who are used to control and predictability, the notion of “responding to change over following a plan” can be scary. For teams who have historically enjoyed working on large projects with minimal day-to-day scrutiny, frequent releases can seem like a terrible idea. These are human issues, and talking candidly and nondogmatically about them will always be more fruitful than chiding others for not “getting it.”

When changing your team’s Agile practices and ceremonies, I’ve found it very helpful to document the reason behind the change, the nature of the change itself, and the intended purpose of the change. I recommend creating a simple template for capturing such changes, which might include the following prompts: We’ve been doing the following Agile practice or ceremony: …because we thought it would help us achieve the following goals: Here’s what actually happened: So, for the next iteration of work, we are changing it in this way: We hope that making this change will help us achieve our goals in the following ways:

Yes, in theory, the product manager often “owns” the roadmap. But in practice, that ownership is never easy, absolute, or uncontested. In fact, the product managers who seek absolute and unilateral “ownership” of the roadmap as a document are the very ones who prove least effective at helping their teams deliver the actual software described in that roadmap.

One of the best pieces of advice I ever received as a working product manager was to think of roadmaps as a strategic communication document, not as a hard-and-fast plan for what will be executed and when. Unfortunately, I immediately misinterpreted this advice to mean that everybody already understood that the roadmap was not a hard-and-fast plan for what will be executed and when.

your team and your organization need to have an explicit and shared understanding of what a roadmap means and how it is to be used.

Here are a few guiding questions to help you get started with creating a clear sense of how your organization intends to use its roadmap: How far into the future should our roadmap go? Does our roadmap make a distinction between “short-term” and “long-term” plans? Who has access to the roadmap? Is it customer facing? Public facing? How often is the roadmap reviewed and by whom? How are changes to the roadmap communicated and how often? What could somebody within the organization reasonably expect if they see a feature on the roadmap three months from now? What could somebody within the organization reasonably expect if they see a feature on the roadmap one year from now?

One helpful step I’ve seen many teams take is to write a “roadmap readme” that serves as the first page of any roadmap document that travels throughout the organization.

most people in most organizations are accustomed to seeing information laid out on a Gantt chart, and you will likely have more success trying to make those Gantt charts better than you will trying to convince people to abandon them altogether.

Good product managers think of product specs as a way to capture and synthesize the shared strengths and expertise of their team. Their product specs are often messy works in progress full of unanswered questions that they can work through in close collaboration with their colleagues. They make sure that the people building the product are engaged and invested in how and why the product is built. If somebody questions their product spec, they see it as an opportunity to make the product better, not as a personal attack.

Writing a long and detailed spec might help you feel like you’re doing a lot of work toward building a product, but it isn’t always the right work.

In other words, bringing incomplete things to your team doesn’t just mean that you are working together to solve a problem—it means that you are continually and collaboratively reshaping the problem as you work together to solve it. How cool is that?