The Eight Leadership Practices of Product Management

Lots of things can go wrong across product development.

You’ve been in this meeting.

The program review is going fine. Engineering is on schedule. Finance likes the margin. Supply management found a cheaper component and saved a few dollars a unit. Marketing has the launch plan ready. Every slide is green.

And somewhere in the back of your mind, you know the product isn’t right anymore.

Nobody made a bad decision. A part got swapped to hit the cost target. A feature got cut to hold the date. The price moved up because the forecast needed it. Each change made sense to the person who made it. Together, they added up to a product that no longer beats the thing it was supposed to beat.

Nobody flagged it, because from every seat in the room it looked like progress. Nobody decided to build the wrong product. It just happened.

So here’s the question. Whose role was it to notice?

The responsibility is bigger than the job description

It was yours. If you’re the product manager, it was yours.

I know that’s not what your job description says. Your company gave you a function: write the requirements, run the reviews, keep the backlog moving, support the launch. That function is real, and you should do it well. But it’s smaller than the role.

Every contributor on the team is answerable for their part. Engineering answers for the design. Finance answers for the margin. You answer for whether the product is right. That means the premise everyone else is faithfully executing is yours to test. And nobody is going to give you permission to do that. Permission never comes. You take the role.

Product managers need three kinds of expertise. The first is domain expertise: knowing your market, your customers, your technology, and your industry. The second is process expertise: the methods, frameworks, and templates that move a product from idea to launch. This includes, of course, New Product Blueprinting! Both matter, and there’s no shortage of advice on either.

The third kind is the most important and the least talked about. It’s leadership expertise, and it’s what turns what you know and what you can do into a product, a team, and a company moving in the right direction. In my own years managing products, and in the years since working with product managers across a lot of industries, the people who made the biggest difference weren’t the ones with the deepest domain knowledge or the best templates. They were the ones who stepped into the strategic role. And they did it through a handful of leadership practices I kept seeing over and over.

There are eight of them. They fall into three levels: how you lead yourself, how you lead with your product team, and how you lead across the organization. None of them are ever finished.

Level one: Yourself

I. Become the Market Expert

Think of a scout. A scout leaves camp, goes out into the field, and learns the terrain firsthand. That’s the customer part, and most product managers know they need to do it. New Product Blueprinting skills and tools provide the perfect mechanisms to do this well. 

But learning the customer is only one of three things. A good scout also knows the competition, and not just what the competition says about itself. Keep two notebooks: one for the propaganda, one for the terrain as it actually is.

The third thing is the one people skip. The scout has to come home and share what they learned. A scout who never reports back is useless, because the organization is going to decide anyway. It’ll just decide without the map. When you keep bringing the map back, and you get the terrain right, credibility builds briefing by briefing. Eventually people come looking for you before they decide.

This isn’t a method. It’s a commitment to be the person in the building who knows the market.

II. Represent the Customer Throughout Development and Beyond

Go back to that meeting where every slide was green.

Picture an architect. The sketches capture the design intent. Then the building goes up, and every function makes changes. Engineering adjusts for buildability. Finance trims to the budget. Supply management substitutes materials. Marketing wants a different entrance. Each change is reasonable. You might even accept one of them yourself. And one of them never reaches you at all.

The building that gets built isn’t the one on the blueprint.

Your role is the product’s direction: what it’s for, who it’s for, and what it has to beat. That last one is positioning, and it’s the first thing to quietly erode. Holding the vision through every one of those reasonable changes is the core of the role. The hard part is that the failure doesn’t look like failure. An unexamined premise, executed faithfully, looks exactly like progress. The void you’re filling is a space that already looks filled.

III. Protect the Time for Your Core Work

Your calendar is a jar. Your core work, the market understanding and the product direction from the first two practices, are the big rocks. Everything else is pebbles and sand: meetings, status updates, fire drills, favors for other teams.

The tricky part is that the pebbles and sand are legitimate. Nobody is asking you to waste time. They’re asking for reasonable things. Pour those in first and the rocks don’t fit.

 

So put the rocks in first. Block the time for customer work and product thinking before the week fills up, and let the requests fill in around them. And sometimes look twice at a request. Something that looks like sand, like a month on the road with the sales team, can turn out to be a rock if it puts you in front of customers.

That includes your own development, such as taking courses from AIM! And let’s face it, if you never make time to get better at the role, nobody else will likely make it for you.

Level two: The Product Team

IV. Build the Product Together

Picture a basketball court. Five players: you, the program manager, and three engineering leads. Every one of them is talented. Talent alone doesn’t win games.

What wins is trust, and trust comes from three plain behaviors: work together, tell the truth, and show up. When the team trusts each other, everyone covers their own zone and knows someone has the rest. When trust is low, everybody guards the same spot. You get duplicated work, second-guessing, and gaps nobody’s covering.

Two more things happen on a team like that. You become the trusted voice on the customer, the way a senior engineer is the trusted voice on the technology. And you start connecting the engineers directly to the customer, so they hear it firsthand instead of through you.

The flip side is worth knowing. When the product manager isn’t on the court, the work doesn’t stop. It routes around you.

Build these relationships over real work. And don’t discount lunch or time together outside work. That builds them too.

V. Bring a Position, Not an Opinion

An opinion is “I think we should do X.” A position is the case for X.

Think of a case board. You start with what’s uncertain, and there’s always something uncertain. Then you commit to a position anyway, because waiting for certainty means nobody decides. “Not yet” can be a position too, as long as it comes with a plan and a date.

A position puts the claim up with the reasoning and the evidence behind it. That changes the conversation. When people push back, they push on the evidence, not on you. If one piece of evidence fails, the conclusion should be able to flip. Leave a card on the board that says “what we don’t know.” And the strongest positions pull together separate sources that point the same way.

There’s a condition for all of this. You can’t build a case from a distance. The engineer making small design decisions every day, the supplier change that happens on a Tuesday, the question that needs an answer this afternoon: you have to be there for those. Be present, be accountable, be useful.

VI. Learn to Say No Without Making It Personal

Picture an assembly line: concept, design, prototype, tooling, launch. Somewhere on that line is a stop button, and part of your role is knowing when to push it.

That’s hard, because by the time you see the problem, a lot of work is already invested. But that work is spent either way. The real question is about the work still ahead. Make the case for no the same way you’d make any case, with the reasoning out in the open.

The key is that you and the engineer are both facing the product, not each other. Keep it about the work. That includes your own ego. Being right isn’t the point. Getting the product right is.

You’ll get pushback, and sometimes you have to hold the stop anyway. If you stay silent, people route around you. Try to solve it where the decision lives rather than escalating it up the chain. And remember there’s a second kind of no: not yet.

When it’s done well, the line starts back up, and everybody restarts it together.

Level three: The Organization

VII. Communicate Bad News Quickly and Transparently

Here’s what usually happens when bad news shows up. The curtains close. The test results get softened, the schedule slip gets rounded off, and the hope is that it’ll be fixed before anyone has to hear about it.

The alternative is a glass box. Imagine two product managers with the same inputs and the same recommendation. One hands it over as a black box: here’s my answer, trust me. The other shows the whole chain of reasoning, how confident they are in each part, and the evidence that cuts against them, left right out in plain sight.

 

The second one earns something the first one doesn’t. Trust is the point where people stop checking your work. You get there by going looking for the crack yourself, before someone else finds it.

When the news is bad, that’s when the glass box matters most. Tell leadership first, and tell them fast. Bad news doesn’t age well, and nobody likes finding out secondhand. Nothing hidden.

VIII. Run Your Portfolio Like a Business

You probably know the story of the blind men and the elephant. One touches the trunk and says it’s a snake. One touches the leg and says it’s a tree. Each one describes the whole animal from the one part he’s holding.

That’s most companies. Every function is measured on its own piece, and nobody’s watching the whole. So you get plans that are correct by one function’s numbers and disastrous by the company’s. Manufacturing optimizes the plant. Sales optimizes the quarter. Each of them is right about their part.

The product manager’s move is to walk around the animal. Go to each function and learn their language. Understand what they’re measured on and why they want what they want. Then you can see how a move on one part ripples across the rest of the business, including the part people tend to forget: the customers who already own your product. And you start to notice when the symptom shows up in one place, but the cause lives somewhere else.

This isn’t about P&L authority. It’s an attitude of ownership. You don’t have to own the business to think like someone who cares about the whole business.

They don’t work alone

I’ve laid these out one at a time, but they don’t operate that way.

 

Practice II, which is greatly aided by processes like New Product Blueprinting,  is the anchor. Representing the customer and holding the product’s direction is the core of the role, and the other seven either feed it or protect it.

A few examples:

• I and II. You can’t hold a product’s direction if you don’t know the market. What you learn as the scout is what you represent in every one of those reasonable-looking changes.

• II, IV, and V. Direction only matters if the team acts on it. That takes a team that trusts you, and positions they can actually work with instead of opinions they can ignore.

• II, VI, and VIII. Saying no is how you protect the direction. Seeing the whole business is how you know which no’s are worth the fight.

That’s why the product manager in that green-slide meeting is in trouble. It usually isn’t one practice that failed. It’s that the practices weren’t working together.

Leadership in management: Start with one

If you try to work on all eight leadership practices for product management at once, you’ll work on none of them.

So here’s a simple exercise. Go back through the list and rate yourself from 1 to 5 on each practice. Be honest. Then look at your lowest score. That’s the one to work on first. Pick one practice, get better at it over the next few months, and then pick the next.

I also run this as a one-day interactive workshop, where product teams work through each practice together using their own products and their own situations. If that’s something your team could use, reach out by leaving us a message on our contact page.

In the meantime, I’d like to hear from you. What’s the single hardest thing about product management that you find? And which of these eight would have made the biggest difference the last time a product drifted on your watch? Send us a note on the contact page and let’s chat about it!