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

by Matt Lemay

Another great way to spread curiosity is to cross-pollinate knowledge and skills among your colleagues. If you’re working with a team of designers and developers, ask them what other skills they’d like to learn. Maybe you have a designer who wants to learn more about frontend development. Or a web developer who wants to better understand the UX patterns of mobile apps. Make it as easy as possible for people to learn from one another as part of their day-to-day job.

Formal practices like this make it clear that you are explicitly valuing curiosity and knowledge sharing among your team.

I’ve been truly amazed to see how a team’s work transforms when they are tasked with presenting to their colleagues once a week—people work harder, collaborate more closely, and begin asking questions about their own work in anticipation of those they will receive from their colleagues. The assumption that, for example, people in marketing couldn’t possibly care about a highly technical product is replaced by the question “How can we present this highly technical product to all of our colleagues in a way that seems interesting?”

Every organization is different, every team is different, and every individual is different. As a product manager, it is your responsibility to communicate, align, and translate between people who might have wildly diverging skill sets, goals, and agendas. The only way to do this is by taking an open, genuine, and curious interest in the work that they do. Learning about specialized skills directly from the people who use those skills within your organization is always more valuable than learning about them from a book or a Wikipedia page. Indeed, every single channel of open and curious communication that you can establish is an important step toward the success of your team.

Your Checklist

Reach out to folks in your organization and say, “I’m curious to learn more about the work that you do.”

Be vigilant about getting to know people outside of your immediate team. Take the time to understand their goals and motivations ...

Be particularly vigilant about reaching out to the folks who you are most afraid will undermine...

Cultivate a growth mindset and open yourself up to learning from people whose skills and ...

Embrace “the gift of being wrong” by choosing the plan that best meets your organization’s goals,...

Present multiple options to avoid locking horns in a yes–...

If you find yourself getting defensive in a meeting or conversation, buy yourself some time by saying, “OK, great,” and the...

If you feel compelled to take an action that might be motivated by defensiveness or anxiety, write down that act...

Be willing to take a clear-eyed look at your product’s limitations and recognize that they are no...

Consider reframing the “why” questions as “could you show...

Avoid saying, “I’m too busy to deal with that right now” and other things that might implicitly discourage your team from...

Encourage your colleagues to learn from one another and pair up folks who want to learn a...

Organize “demo days” and other opportunities for product teams to share and discuss their work wi...

The title of this chapter is in many ways a joke. But for working product managers, it is also deadly serious. The biggest mistakes I’ve made as a product manager, and the biggest mistakes I’ve heard about from many other product managers, involve failing to communicate things that seem either too politically dangerous or too inconsequential to openly address.

For most working product managers, this scenario is not hypothetical. It happens all the time, and it keeps happening, even when you swear a million times over that you will never let it happen again. 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.

In practice, however, the day-to-day work of comprehensive communication can prove very difficult. Choosing to communicate in the moment is much more challenging than choosing to communicate in the abstract.

If there’s such a thing as a Ten Commandments of product management, it is Ben Horowitz’s “Good Product Manager/Bad Product Manager”, a document Horowitz composed as a kind of ad hoc training for Netscape product managers way back in the days of the first internet boom. “Good Product Manager/Bad Product Manager” is a short and simple document, but it accomplishes something very important: it lays out in exceptionally clear terms the day-to-day expectations for product managers at that particular organization at that particular time. “Do this, not that.” Every company should have a document like “Good Product Manager/Bad Product Manager” that spells out the responsibilities of the job in clear, instructive, behavioral terms—and explicitly names the behaviors that are to be avoided.

When we orient ourselves toward our team’s business and user goals, the upside of asking the obvious seems…well, obvious. If it turns out everybody was already aligned in the first place, we can move forward even more secure in our shared understanding. And if it turns out everybody was not aligned, we can openly address any miscommunications before they become a much bigger problem.

Because product managers rarely have direct organizational authority, it can be tempting to couch any requests in the “nicest” possible terms—especially requests for things like staying late to release a product or redoing work that was already completed. But being ambiguous about what you’re asking for (and whether you’re asking at all) is not nice. It is a deflection of responsibility, a passive-aggressive attempt to get the result you want without being the “bad guy.”

For many years, I used self-deprecation to slither out of situations in which I felt like people might be mad at me. When I was coming to my team with a tough deadline or a request for new work, I would often say something like “Guess what, here comes the PRODUCT MANAGER with another FUN DEADLINE FOR EVERYBODY!” It felt like a good way to alleviate the tension and to show that I was “one of the team.” And most of the time, it got at least a little chuckle.

But the long-term effect it had on the team was neither good nor particularly funny. By using self-deprecation to spare my own feelings, I was doing absolutely nothing to communicate to my team why I was asking them to meet a tough deadline or revisit something that they thought was already finished. My goal was not to get the team aligned around our purpose but rather to end the conversation as quickly as I possibly could. I was communicating, intentionally or not, that the work I was asking for was meaningless—because if I took responsibility for conveying its meaning, I would be the person asking for the work. And nobody likes the person asking for the work.

Product managers are often counseled to take full and unequivocal responsibility for anything that goes wrong on their team. “If something goes wrong,” I was told earlier in my career, “it’s your fault—whether or not it’s really your fault.” I took this counsel firmly to heart and embraced my Product Martyrdom.

If something went wrong on my team, I could simply declare, “YUP, MY FAULT, I’M THE WORST,” and get on with my day. This was actually much easier than initiating and facilitating an honest conversation about how the entire team may have contributed to a subpar outcome and what steps we could take to deliver better outcomes in the future.

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. Nothing runs more counter to our guiding principle of making yourself obsolete than casting yourself as the sole personal receptacle for all your team’s misste...

Over the last several years, I’ve often heard the directive “assume positive intent” deployed in the service of reinforcing this line and depersonalizing difficult conversations. And sure enough, “assume positive intent” is certainly a healthier directive than “Assume personal blame for anything that goes wrong, even if you don’t really believe it’s your fault.”

For better or worse, people with good intentions can do a lot of harm, and people with bad intentions still stumble into positive actions from time to time. Broadly speaking, I have found it helpful to focus these conversations on outcomes as opposed to intentions.

If we take ourselves out of the picture as individuals and look at the whole system, we see that our intentions are often largely irrelevant. Our job is to improve systems in the hopes of delivering consistently better outcomes for our business and our users.

A few years into the practice of avoiding self-deprecation, I’ve had to get much better at facilitating open conversations with my team about what’s really going on and what we can actually do about it. I certainly find myself fielding more challenging questions about why we’re doing what we’re doing or how I made a particular decision. But my experience answering these questions has helped me become a better product manager and, hopefully, a less defensive person as well.

Early in my product management career, I genuinely believed that I could keep myself out of trouble by making sure that every step I took received perfunctory “approval” from somebody in a position of authority. Before finalizing my team’s quarterly roadmap, I would make sure to present it in a meeting to company leadership. And before turning design mocks into working software, I would send those mocks to any stakeholders who I thought might be particularly opinionated about the look and feel of our product.

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

I’ve found it helpful to include at least one meaningful choice or one open-ended question in any meeting or email where you are asking for feedback or approval. An email that says, “Attached, please find our roadmap for next quarter. Let me know if you have any questions,” might create the outward appearance of transparency and collaboration, but it doesn’t protect you from any “What the hell is that and why haven’t I seen it before?” responses when you actually start delivering against that roadmap. 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?” (We’ll discuss the importance of sending specific and time-bound asks via email and chat in Chapter 13, “Try This at Home: The Trials and Tribulations of Remote Work”.)

In conversations with multiple stakeholders, the center of gravity around “Looks fine” grows all the more compelling and irresistible. As awkward as it is to disagree with one person in a one-on-one conversation, it can be exponentially more awkward to disagree with 10 people in a 10-person conversation. “Looks fine” will always be the path of least resistance—unless you do the difficult work of adding a whole lot of resistance to that very path.

The idea behind disagree and commit is pretty simple: any decision made in a group setting should conclude with affirmative commitment to a path forward from everybody involved. And the process of getting to that commitment should necessitate bringing forward questions, concerns, and disagreements that would have otherwise gone unspoken.

Now, let’s imagine a second meeting that operates under the rules of “disagree and commit”: each person in the meeting must provide specific, affirmative commitment before a decision is made, and each person is responsible for raising any questions or disagreements that might stop them from providing that commitment. After thoughtfully walking through competitive analysis, usage projections, and revenue goals, you conclude with a strong recommendation that the feature be included in the free tier. “OK,” you tell the assembled stakeholders, “we’re going to try doing something a little bit different this time. This is a big decision for the team, and I want to make sure that we’ve gotten all the information that y’all have out on the table. So I’m going to go around and ask each of you, one by one, to say ‘I commit’ if you’re committed to moving forward with the approach we’ve outlined. And if you can’t commit, tell me why, and we’ll figure out what to do from there.”

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. As with any best practice, the way you implement disagree and commit will change based on your team and your organization. Here are some tips for trying it out:

Introduce disagree and commit before you use it. Because disagree and commit is a formalized best practice—and one with the likes of Intel and Amazon behind it—you can introduce it as an agreed-upon procedural experiment. This is important because it will help avoid any situations in which people might feel like you are implementing disagree and commit as a kind of passive-aggressive personal criticism directed toward any particularly noncommittal members of your team.

Interpret silence as disagreement. In most meetings, silence is interpreted as implicit agreement. Somebody suggests a path forward, concludes their pitch with “Any questions?” and if nobody responds, it’s more or less a done deal. With disagree and commit, nothing short of affirmative commitment is accepted, which means that silence amounts to disagreement. Be very clear with participants: “If you are silent, I am going to assume that you are disagreeing with me. Let’s go through and have each person share their thoughts and concerns.” The first time you try this, it might be one of the...

In larger meetings, try doing a quick pulse check. In larger meetings—especially large meetings held over video chat—I’ve often found it helpful to move toward the conclusion of a meeting with a quick “Can everybody who’s committed to this approach give me a thumbs-up?” Even if only one or two people respond tentatively, this gives you a chance to dig in ...

Set goals, test, and learn. 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. T...

Rather than trying to get everybody to reach consensus, you could say, “What if we commit to trying two-week development cycles, then touch base in a month to see whether this decision is helping us meet our team goals or we want to try something else?” This ensures that a decision happens, and it creates a shared sense of accountability for measuring its success and adjusting course moving forward.

Don’t completely misinterpret the entire point of this and say, “Well, it doesn’t matter if you agree because we’re doing disagree and commit!” 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.

I was working with a small consultancy in California that builds products for media conglomerates. We were having a meeting to discuss internal processes, and the question came up of how to handle client emails that come in after working hours. This had clearly been a source of tension among the team, and most people fell silent when the question was posed directly.

For many product managers, overcommunication comes naturally—that’s part of what drew them to product management in the first place. From this perspective, people who are less inclined to ask a lot of questions, speak up in meetings, or provide detailed written responses can often seem like “bad” communicators.

As a product manager, it is critical for you to remember that not everybody is going to share your style of communication. Be open and curious with those who might initially strike you as bad communicators. Here are a few general styles of communication I’ve often encountered, to help you start from a place of understanding and empathy:

Visual communicators Some people cannot grasp a concept until they have seen it visualized. As a person who primarily uses words to communicate, it took me a long time to accept this. I would often become frustrated and just find myself using more words when my meticulously composed messages were met with blank stares. If you are not a visual communicator, visual communicators on your team can offer you a great opportunity to refine and focus your own thinking by quickly sketching out or visually prototyping your ideas.