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

by Matt Lemay

The teams I’ve seen most successfully navigate informal communication have, either implicitly or explicitly, shifted the bar from “Let’s create a space where everybody can share lots of information with each other in the open” to “Let’s create some spaces where people can broadly get to know each other, in the hopes that they will then follow up to share relevant information with each on their own time.”

“What could the company accomplish with you in a promoted position that it cannot accomplish now?” I love this question, because it forces you to think about the potential impact of your desired role and why you are the right person for that position. Returning to an idea expressed in Ben Horowitz’s “Good Product Manager/Bad Product Manager”, defining and understanding the impact of your role is part of a good product manager’s job.

In the product world, individual contributors often get promoted for the very behaviors that limit their effectiveness as leaders. And as you step into a product leadership role, the continuation of these behaviors will have two interrelated and equally negative consequences: you will burn out, and your team will feel disengaged and disempowered. Accept the fact that you will need to unlearn some old behaviors and learn some new ones—and that those new behaviors may not come easy for you, no matter how big and fancy your title might be.

There is simply no way around this one: when you are a product leader, the standard you set for yourself is the standard you set for your team. If you are in the office until 8 p.m., your team will think that you expect them to be in the office until 8 p.m., no matter how many times you insist otherwise.

Ultimately, becoming an effective product leader means learning to measure your value by something other than how late you’re staying and how hard you’re working.

When senior leaders ask questions, I do my best to give them the benefit of the doubt and treat those questions as real questions, not as cloaked demands. I also try to be aware of the fact that my own questions might be taken as cloaked demands.

many product leaders—myself very much included—have misinterpreted the call to “autonomy” (and the fear of micromanagement) as permission to just “leave teams alone and let them do their best work.”

I can say definitively that “just do whatever you want” ultimately delivers neither autonomy nor empowerment. Many of us have learned this the hard way when planning a group meal for people who insist that they’re “up for anything!” only to reveal a plethora of previously unstated preferences and restrictions when everybody sits down to eat.

Truly empowered teams also need the business context that comes from the leadership—especially the product vision—and the support of their management, especially ongoing coaching, and then [to be] given the opportunity to figure out the best way to solve the problems they have been assigned.

I have found three things consistently helpful for striking this balance: clear goals, clear guardrails, and—most importantly—short feedback loops.

It’s worth remembering that, even when you’ve made it to a product leadership role and you’re ostensibly doing everything right, you’re still going to get that “Why does your product suck?” email.

I believe that communication is the key that unlocks the solution to almost all of our problems. Too often people say a thing is happening, or that someone thinks something, and I ask, “Have you talked to them?” And the answer is no. And my response is, “What you just said to me? Go say those exact words to them.”

As you step into positions of product leadership—formal or informal—one of the first and hardest lessons you will learn is that you can’t complain about your colleagues in the way you once did. (You may, in fact, realize that you never should have complained about your colleagues in the way you once did!) This holds particularly true when you are speaking to somebody whom you directly manage.

Check your ego when you find yourself being asked a lot of important, strategic questions. Remember that part of your job is to organize your teams to answer those questions themselves as best they can.

Avoid turf wars over who gets to “own” any particular part of the product; stay laser focused on the outcomes you are driving for the business and its users.

When your team feels like it is on autopilot, it becomes more important than ever for you to seek out challenging ideas and alternate explanations.

One of my favorite ways to approach these prototypes is with an hour-long “reinventing the product” session. The setup is pretty simple: you bring together some cross-functional stakeholders, assign them a user persona and an important task for that user to accomplish, and give them five minutes to put together a rough digital or paper prototype showing how they might completely reimagine their product to help that user complete that task.

As a product manager, your title gives you nothing—no formal authority, no intrinsic control over product direction or vision, and no ability to get a single meaningful thing done without the help and support of others. To whatever extent you are able to lead through partnership and trust, you must earn that trust every minute, every day. And you must chart your own path to earning that trust in a role full of irresolvable ambiguity and irreducible complexity.

Without exception, this means that you will make mistakes—glaring, egregious, embarrassing mistakes—as you build your product management practice. You will be evasive when you need to be direct. You will be impulsive when you need to be patient. You will follow “best practices” to the letter, and they will still backfire in ways you never could have imagined. The mistakes you make will have real repercussions for yourself, your team, and your organization. You will be humbled by the generosity and forgiveness shown by your colleagues. And over time, you might even become more forgiving toward yourself.

A few years ago, I delivered a training session at a large, process-driven enterprise financial services company. When the topic turned to the day-to-day responsibilities of a product manager, a recent hire expressed his frustration at the unexpected ambiguity of his new role: “I feel like every day I show up for work, this is a totally different job.” The other product managers in the room just smiled. Eventually, he started smiling too. Like many product managers before him, he had asked the question, “Just what am I supposed to do all day?” And without even realizing it, he had already found the answer: whatever it takes.