Chapter 4. The Art of Egregious Overcommunication

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.

Sometimes, things can seem both dangerous and inconsequential. For example, suppose that you’re in a meeting with your team and a developer rattles off a detail about a product that feels ever so slightly different from something you discussed in a separate conversation with executive leadership. You start to fidget in your seat. You’re pretty sure that the developer on your team just misspoke. After all, your team has been working off the same product spec that you walked through with the executive leadership team. In any case, it’s just a minor difference. And the last thing you want to do in this moment is to pause the conversation, put a developer on your own team in an uncomfortable position, and draw attention to your own potential mistakes. It’s just a tiny thing. Nobody will notice. It would make no sense if this turned out to be a big deal! It’s fine.

Cut to two weeks later. Your team is presenting a demo of this product, and a member of the executive leadership team begins to make a sour face. Her nose scrunches up and her eyes narrow. She mouths the words “What is that?” juuuuuust distinctly enough for your heart to completely stop. Head shaking back and forth, she interrupts your developer midsentence: “I’m sorry, but this looks very different from what I signed off on. I’m very confused right now.” Your team stops in its tracks. Everyone’s eyes turn to you. After the string of expletives in your head concludes, you say to yourself, “You were afraid this was a big deal, it is a big deal, and now it’s too late.”

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. This chapter provides some tactical guidance for making egregious overcommunication a part of your product management practice.

Asking the Obvious

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.

My very favorite part of “Good Product Manager/Bad Product Manager” says quite simply: “Good product managers err on the side of clarity versus explaining the obvious. Bad product managers never explain the obvious.”

When I began working as a product manager, I wondered what exactly this meant—why would explaining “the obvious” be important? The answer, it turns out, is that the things that seem obvious to you might not be obvious to anybody else. In fact, other people might have drawn vastly different conclusions that seem equally “obvious” to them. For that reason, things that seem obvious often carry the most potential for disastrous miscommunication.

Being the first person to call into question something that seems obvious or self-explanatory can feel deeply uncomfortable. It takes courage to chime in and say, for example, “Just to make sure we’re all on the same page, when we talk about the ‘launch date’ next week, our current plan is to do a small, closed beta launch to a group of about fifty users so we can gather some data before rolling anything out to a broader group.” Even if the response you get is a unified chorus of “Yes, of course, we all knew that,” I guarantee that at least one other person is quietly thinking, “Whew, I sure am glad somebody spoke up, because I definitely did not know that.”

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.

Don’t Deflect, Be Direct

Several years ago, I received an unexpected text message from my manager at about 9 p.m. on a Thursday night. It read, “Hey, would be really great if we could get that new release of the iPhone app submitted to the App Store tonight!”

I was confused. Was this an urgent demand? A friendly but low-priority request? Was I being asked to do something right now? Or was I simply being shown a 113-character window into this person’s vision of a better world? In most situations, I probably would have just dragged my Product Martyr-y self to my computer, grumpily submitted the app, and sent back a tellingly overenthusiastic message like “OF COURSE—NO PROBLEM!!”

But this time, I was actually out at a concert, a solid hour away from my computer. (And yes, shame on me for checking my phone during a concert.) Unable to fall back into my usual routine of passive-aggressive overwork, I stepped out and called my manager.

“Hey, I’m really sorry, but I’m actually at a concert right now. If you need me to go home and submit the app, though, I can totally do it.”

The voice on the other end of the line was hesitant.

“Oh, umm, yeah, I mean, it would be really great to get it into the store tonight!” A pause. “But if you’re out at a concert...I mean...you know what, don’t worry about it, we can talk about it in the morning.”

I let out a cheery “Sounds good, thanks,” and was immediately overcome by a deep sense of dread. Had I just overstepped some invisible line of work-life balance? Had I done something bad for the company for my own selfish purposes? Was I, as I had long suspected, a terrible, selfish person?

The next morning, I prepared to receive my punishment. My manager, though, seemed remarkably nonchalant. “Oh, yeah, I mean, I realized last night that it would have been nice to submit the app right away, but it’s totally fine to submit it today, it’s not like it’s going to make all that much of a difference with the final timing.”

In an uncharacteristic moment of directness, I said, “OK, can I ask you a favor? In the future, can you be very, very clear when you are actually asking me to do something right now? When I got your message, it was hard for me to tell how urgent the situation really was. If you ever urgently need me to do something, then I will do everything in my power to make sure it gets done. But if it’s more like a ‘nice to have,’ could you just be as clear as possible about that?”

For about 10 seconds, I felt deeply proud of myself for being so direct. I then realized that most of the requests I was making to my colleagues still started with some version of “It would be great if...” or “Hey! Do you think you could, maybe, perhaps...” or “HEY NICE DAY HOW’S THE WEATHER I LIKE SANDWICHES DO YOU LIKE SANDWICHES anyways I was just wondering if you maybe had time to...”

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

The pull toward any and all kinds of deflection, overwrought apologies, and general self-deprecation is strong for product managers. But it is also damaging and dangerous, both to you and to your team. 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.

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.

Not Everything Is Your Fault, and Outcomes Matter More Than Intentions

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. And, in a funny way, it felt like a relief. 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 missteps, rather than working with your team to address the systemic challenges that may have contributed to those missteps.

The line between addressing systemic challenges and flinging around personal recriminations can be a very thin one. 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.”

But as “assume positive intent” has reached the point of ubiquity, it has also revealed some limitations. In the last year or so, I have unfortunately heard the phrase used as a kind of passive-aggressive challenge to the very conversations it was supposed to facilitate: “How dare you suggest that something is wrong with my team? Don’t you know that I’m doing the best I can? What happened to ‘assume positive intent’?”

As this nightmarish emotional Rube Goldberg machine of projections and deferrals suggests, the very idea of focusing on “intentions” can lead us into weird, murky emotional territory. 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.

In practice, this has often meant mediating conversations about interpersonal or team-level challenges with the question “Did this situation deliver the desired outcome?” For example, when a product manager comes to me upset that their counterpart in engineering feels left out of the decision-making process (a common dynamic on cross-functional product teams), I have gotten into the habit of asking, “Was the desired outcome of this situation for the engineering manager to be excluded from the decision-making process?” If the answer is “Yes, I did not have the time to involve them,” or even “Yes, I don’t trust them to participate in our team decision-making process,” then we can take the conversation from there. And if the answer is “No, I was doing my best to involve everybody, and I’m not sure why they feel left out,” then the product manager can initiate a follow-up conversation with their engineering counterpart to understand what happened and work toward a better outcome next time around.

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. When confronted with a colleague’s frustrations or hurt feelings, I’ve found it helpful to respond with a statement like “OK, thank you for sharing that with me. It sounds like this didn’t result in the outcome we wanted. How can we change things moving forward to get a better outcome?” This shift from emotions to outcomes can help redirect conversations that would otherwise deteriorate into passive-aggressive finger-pointing (or unabashed Product Martyrdom).

The Two Most Dangerous Words in Product Management: “Looks Fine”

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

More often than not, this gesture of approval took the form of a brief, passive acknowledgment like “Got it,” or “Thanks for sending.” And, really, that was all I needed—and, at the time, all I wanted. I figured that if anybody took issue with my team’s work later on, I’d be able to throw that “Got it,” right back in their face and emerge vindicated and victorious: “I SENT THIS TO YOU A MONTH AGO AND YOU DIDN’T HAVE ANY FEEDBACK, WHICH MEANS YOU CAN’T CHANGE IT NOW!!”

I quickly discovered that “no backsies” is not a binding corporate policy. As we will discuss in Chapter 5, 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.”

The best product managers make it more or less impossible for people to react with “Looks fine.” They always show up with open-ended questions to ask—even if those questions are awkward and nerve-wracking. And, as we discussed in Chapter 3, they provide options, not arguments, requiring active participation from their stakeholders rather than passive, glassy-eyed nods or two-word email responses.

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

A Tactical Approach to Move Past “Looks Fine”: Disagree and Commit

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.

Thankfully, the good folks at Intel pioneered a technique called “disagree and commit” that is designed to do this very thing. 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.

By way of example, let’s imagine two different meetings, each held with the purpose of deciding whether a new feature should be included in the free or paid tier of a freemium product. The first meeting operates under the traditional rules of implicit consensus: if everybody agrees (or, at least, nobody disagrees), the decision is made and you move forward. As the product manager on the team building this feature, you’ve been tasked with making your case to a group of about 10 director-level stakeholders. 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. “Does anybody have any questions? Does this sound like a good approach?” A few tepid nods, but general silence. You breathe a sigh of relief. “OK, great!”

Your team gets right back to work and begins implementing an exciting new free feature. Technical details are negotiated, marketing copy is written, and everything seems well on track. Then, two weeks after the meeting, you receive an email from one of the directors who had nodded along to your proposed direction: “Sorry, we need to put a hold on this—there are a few hiccups around the pricing tier decision we need to address.” Wait, what? You thought everybody had agreed! You quickly shoot back an email, trying your best to suppress your rage and frustration: “Thanks for the note. Sorry, I’m a bit confused here—I thought we had all agreed that this would be a free feature?” A few hours later, you receive a response: “Yes, our VP of revenue is reevaluating the pricing strategy and isn’t sure another free feature makes sense right now. I’ll have more information for you next week.”

You shake your head and let out a deep sigh. Now you have to go back to your team and tell them that the company’s entire pricing strategy is in flux and that two weeks of their hard work is now in limbo because of it. You know this is going to be a big hit to morale and a big setback for your team’s timeline, but, at this point, you’re not sure what you can really do about it other than hope, wait, and vent.

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

You turn to the director of product marketing. “Do you commit to us moving forward with a free feature?” They seem a little taken aback and scramble to blurt out an “Um, sure, yes, I commit.” “OK, great,” you say. You pause for a moment and then continue: “Just to be clear, the goal here is to get any questions or concerns out on the table so that we can make the best decision possible. You don’t have to say yes if you’re not sure!” A few nervous laughs, and they chime back in with “Ha, no, thank you, yes, I commit! I think this makes a lot of sense.”

You move on to the director of revenue operations. Right off the bat, they don’t seem quite so sure. “Actually,” they say, “I’m not sure if I can commit to this right now. Our VP of revenue is reevaluating our pricing strategy, and I wouldn’t want to give you a definitive yes before we get that all sorted out.” You pause. “OK great, thank you for that. When do you think we could get more clarity on this?” They respond, “Uh, let me get back with you next week.”

In the week that follows, you’re able to have several follow-up conversations with the revenue team and get a better sense of how and why the company’s pricing strategy is changing. Meanwhile, your team moves forward with work that does not require a firm commitment to either pricing approach. Soon, you are able to reconvene the stakeholders from the original meeting and, with the full support of the director of revenue operations, explain how the company’s pricing strategy has shifted toward putting more features in the paid tier. The back-and-forth is frustrating, but you’re deeply relieved that you were able to navigate this change in full view of your team and your stakeholders.

As this example illustrates, 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 most uncomfortable moments of your product management career, but you’ll be amazed at the insights that can emerge from the quietest people in the room.
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 deeper and quickly demonstrate that dissenting opinions will be welcomed and taken seriously.
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. Then you can validate whether the approach you chose is working and make adjustments accordingly.

For example, suppose that you are in a meeting with your engineering team and there is a disagreement about whether your product development cycle should be two weeks or six weeks. 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.

Accounting for Different Communication Styles

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.

In my career as a product manager, I have often become frustrated with people who don’t share my penchant for extensive written communication and spur-of-the-moment “riffing” in meetings. (For those of you reading that last sentence and thinking, “Both of those things sound horrible,” I see you and I appreciate you.) It’s taken me a long time to realize that this is not an issue of “good communication” versus “bad communication,” but rather a reflection of the many different communication styles you are likely to encounter in your career.

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.
Offline communicators
On numerous occasions, I have had somebody confront me after a meeting because they feel like I put them on the spot when I was simply trying to involve them in the conversation. Initially, I wrote this off as a kind of juvenile defensiveness. But I’ve come to accept that some people need to think things through before they talk them out. Whenever possible, give offline communicators on your team a heads-up, letting them think through a particular question or challenge before sharing their thoughts. Also make sure that they know in advance if they will be asked to speak or present in a meeting.
Confrontation-averse communicators
In the day-to-day work of product management, receiving an uncomplicated “Yes” or “Looks good to me” can feel like a rare and precious moment of pure positivity and encouragement. But these encouraging yes answers are not always motivated by a thorough and nuanced evaluation of the question at hand. As a product manager, putting clarity over comfort is part of your job, but it is not everybody else’s job, nor is it their inclination. If you need feedback from somebody whose first reaction always seems to be yes, ask for that feedback in a way that does not allow for a yes-or-no answer. Accept that person’s implicit challenge to be both more precise and more open in the way that you ask for feedback, and it will likely help you gather better feedback from everybody in your organization.

The more you can learn about the specific people on your team and appreciate their individual communication styles, the better you can facilitate communication for your team and your organization. I’ve found that the easiest way to learn about somebody’s communication style is often to see how they communicate things to you. People generally convey information in the way that they most easily absorb information, and you can create a lot of good will by meeting people where they are.

Communication Is Your Job—Don’t Apologize for Doing Your Job

Effective product management requires asking lots of different people for lots of time, which can leave product managers feeling like the annoying jerks who drag everybody away from their “real” work and force them to attend meeting after meeting after meeting or answer email after email after email. Early on in my career as a product manager, I did my best to defuse this by insisting to my colleagues that I would do everything in my power to make sure that they had to attend as few (ugh) meetings as humanly possible. When I did have to schedule a meeting, I treated it like a necessary inconvenience, rather than an exciting opportunity for the team to solve important problems together.

It did not occur to me until much later that I had effectively created a self-fulfilling prophecy: every one of my team’s meetings would be treated like a waste of time and would, in turn, become a waste of time. 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.

If your team feels like they are wasting time in meetings, ask them about the best and most productive meetings they’ve recently attended. Then work together to craft a clear and achievable vision for what a “good” meeting looks like. If your team is overwhelmed with email or chat messages, work with them to set clearer expectations around the communication channels you use. (We’ll discuss this more in Chapter 13.) Don’t downplay the value of the time your team spends communicating with each other—instead, make sure that time is spent well.

Egregious Overcommunication in Practice: Three Common Communication Scenarios for Product Managers

Though product managers might find themselves communicating with a lot of different people in a lot of different contexts, there are a few scenarios that tend to present themselves time and time again. In this section, we look at three common communication scenarios for product managers and how you might approach each of them. After reading the setup for each scenario, take a moment to think about how you would be inclined to handle it. This will help you square these suggestions with the rhythms, personalities, and issues at play in your specific organizational context.

Scenario One

Account Manager: We have to build this feature in two weeks, or we will lose our biggest client.

Developer: That feature will take at least six months to build if we want to do something that’s even remotely stable and performant. (Figure 4-1)

An “emergency” request meets technical pushback.
Figure 4-1. An “emergency” request meets technical pushback

What’s really going on

This is a classic and common case of misaligned incentives. The account manager’s job is to retain customers. The developer’s job is to create software that is not embarrassing, buggy, and held together with tape and string. The account manager is not directly incentivized to care about things like whether the software is performant. The developer, on the other hand, is not (usually) directly incentivized to care whether the customer is retained—if anything, one less unreasonable customer is one less set of last-minute demands. Both the account manager and the developer are advocating for their own respective short-term goals.

What you might do

There are multiple assumptions at play in both the account manager’s and the developer’s positions here. Does this customer really need this exact feature? Will we really lose the customer if we don’t build it? Does the developer fully understand the customer need, or is she using the six-month timeline as a more defensible way to say no? Rather than debating the specific feature that your account manager is asking for, dig deeper into the fundamental problem the customer is having. Enlist the account manager as a partner in better understanding the customer’s needs and the developer as a partner in exploring possible solutions. You might discover that no new feature is required at all, just a quick conversation with the customer to help them better understand an existing feature.

Patterns and traps to avoid

OK, well, let’s decide whether we’re looking at two weeks or six months.
Both two weeks and six months might be totally arbitrary time frames. The account manager might have said, “two weeks” as shorthand for “really soon,” and the developer might have countered with “six months” as a way of saying, “Hell no, I do not want to work on that.” Avoid the false choice and get to the heart of the issue.
Yes, I agree that we need to solve this in two weeks. And I agree that the software needs to be performant and stable.
Don’t try to play both sides! This will simply not work. There are likely opportunities to level up to a more goals-oriented conversation, and it is your job as a product manager to facilitate that conversation. Best-case scenario: you will discover a solution that takes less than two weeks and incurs minimal concerns about performance and stability. Keep the conversation open and exploratory, but don’t try to score quick points by telling people what they want to hear.
Our planning process happens every two weeks, and we’re all full up. Come back to me later.
If you are working in a world of truly fixed iterations, last-minute additions like this are often avoided at all costs, and there are good reasons to keep these guardrails in place. But good reasons often won’t stop these requests from coming in, and I’ve generally found it more helpful to have a process for evaluating and prioritizing them, rather than shooing them away entirely. (We’ll discuss this more in Chapter 12, “Prioritization: Where It All Comes Together”.)

Scenario Two

Designer: I made four different versions of this design—which one do you like most? (Figure 4-2)

A designer presenting multiple options
Figure 4-2. A designer presenting multiple options

What’s really going on

The designer might have created four versions that he feels are equally well suited to the goals of the project, but with subjective differences (such as color choice) where he doesn’t have a strong point of view. Or, the designer might not be clear about the goals of the project and is trying to defer responsibility by forcing you to make a choice. Or, the designer might have one approach he’s really hoping you’ll pick and has made a few “dummy” options to create the illusion of choice.

What you might do

This is an opportunity for you to demonstrate your trust in the designer by asking him which option he feels best aligns with the goals of the project. If he feels that one choice is clearly superior, this prompts him to think about that choice in the context of goals rather than preferences. And, if he doesn’t have a strong preference, it might compel you both to have a conversation about whether the goals of the project are sufficiently clear. If multiple options seem equally viable, you might discuss with your designer how you could test these options to see which one best meets the goals of the project. After all, your team can have different opinions—but you should always have the same goals.

Patterns and traps to avoid

I like choice B—let’s go with that!
This is an easy and tempting response. After all, the designer asked you what you think. In some cases, the question really is that simple: the designer doesn’t care and just wants you to choose among a few subjective variations. But you’re better off digging a little deeper than you are rushing to a decision without a clear set of reasons beyond your personal preference.
Let’s bring all four of them to the whole group and see what they think!
For a long time, this was my strategy, until a thoughtful UX designer informed me that I was driving our visual designer to the point of quitting with “design by committee.” Nothing is worse than having a whole bunch of people spout their opinions at you about the job you were hired to do.
I don’t care. Whichever one you want is fine.
It’s very rare that somebody puts in the work of doing something four different times unless there’s a reason. Don’t dismiss that effort—and the deeper issues that might be underlying it—by refusing to engage.

...And a bonus question

What if the designer only gave me one option?

Avoid the temptation to launch immediately into a critique, even if it feels like a generous critique. Instead, ask the designer to walk you through how he arrived at the design. This will give you an opportunity to learn more about how the designer understands the project’s overall goals, and it might reveal a subtle miscommunication or two that you can work to resolve.

Scenario Three

Developer: Sorry, I just don’t understand why you’re trying to force us to follow all this unnecessary process. Can you just let me do my job? (Figure 4-3)

A developer protesting “unnecessary process”
Figure 4-3. A developer protesting “unnecessary process”

What’s really going on

Although phrases like “This process is just way too heavy for us,” or “I don’t want to follow all of these unnecessary steps,” or “This is big-company corporate bulls***,” might seem like generic grumblings of the process averse (we’ll discuss this more in Chapter 7), they are important and valuable signals that you have some work to do. If your team does not feel invested in your development process, and/or if they see that process as an impediment to getting their work done, you might have fundamentally failed in your role as a communicator and facilitator, even if you have succeeded in getting your team to formally adopt a certain development framework or process.

What you might do

First and foremost, take your developer’s feedback seriously. Thank him for his candor and make it clear that your team can succeed only if people are up-front about sharing their concerns. Rather than trying to resolve his concerns in an offline one-on-one conversation, ask if he can repeat this feedback during the next team meeting. This will help establish that you are not looking to be the brutal enforcer of your team’s processes, but rather a facilitator who helps the team identify and adopt the processes that will best meet their goals.

Patterns and traps to avoid

Just try it for a while—I promise it will make your life easier!
There is a subtle but critical distinction between “I promise this will work” and “Let’s collaborate to make this work.” Asking anybody on your team to uncritically accept process changes is a fundamentally dismissive gesture, not a connective and supportive gesture. If your team does not feel invested in its process, that process is likely to fail.
You’re right. Forget this process stuff—what do you want to work on?
Although giving engineers free rein to work on whatever they want might feel like an empowering or at least suitably deferential gesture, it ultimately leaves them deeply disconnected from the user- and business-facing impact of their work. Eventually, somebody is going to hold your team accountable for the actual results of what they build. And the longer your team goes without any kind of process to connect the work they’re doing with the goals of your organization, the worse that day of reckoning is going to be.
I know, I know, I’m the worst, but my boss said we should put some more process in place. I promise I’ll try to make this as painless as possible!
As we’ve discussed, self-deprecation is a common coping mechanism for product managers. But if you cast yourself as an unwitting pawn in somebody else’s quest to instill meaningless processes, you are guaranteeing that the process will be meaningless. If you don’t believe that the process you’re using is the right one, but, hey, your boss asked for some process, it is time for you to have an uncomfortable conversation with your boss.

Summary: When in Doubt, Communicate!

The day-to-day work of communication requires attentiveness, adaptability, and nuance. But 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.

Your Checklist

  • Err on the side of overcommunication. When you aren’t sure whether something is worth mentioning, mention it.

  • Don’t be afraid to ask “the obvious.” In fact, the more obvious something seems, the more insistent you should be about making sure everybody is on the same page.

  • Create a document like “Good Product Manager/Bad Product Manager” that clearly lays out the behavioral expectations for product managers in your organization.

  • Avoid starting sentences with phrases like “It would be great if...” or “Do you think it might be possible to...” that deflect responsibility. If you are asking for something, ask for it—and be clear about why you are asking for it.

  • Try to refocus conversations about emotions and intentions around outcomes by asking questions like “Did this situation deliver the desired outcome?”

  • Never forget that “Looks fine” often means “I’m not paying attention,” and always aim for engaged, affirmative, and specific feedback and buy-in.

  • Make sure that people are given a chance to voice their opinions in meetings by using “disagree and commit” or any other approach that achieves similar goals within your organization.

  • Remember that people have different communication styles. Don’t write somebody off as a “bad communicator” or assume that they have bad intentions if their style is different from yours.

  • Avoid the temptation of being a “meeting hater” or “email hater.” Don’t apologize when you’re asking for somebody’s time, but make sure that their time is well spent.

  • Ask your teammates about the most valuable and well-run meetings they’ve attended. Then work with them to set a clear vision for what a “good” meeting looks like for you.

  • Level up tactical conversations about things like design choices or development timelines to strategic conversations about business goals and user needs.

Get Product Management in Practice, 2nd Edition now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial