They don’t. If you have a product manager for a product or feature, that person should also be the product owner, where “product owner” means the person who understands the target market, who owns the roadmap, who defines the feature list, and who makes decisions large and small to ensure that the product meets customer needs.

If your PM is not competent enough or empowered enough to define the roadmap and make prioritization decisions, then you either have the wrong PM or you have a “too many cooks” organizational/cultural problem in your company that will slow down productivity and result in shipping worse products to your customers.

The typical reason why these roles are split goes like this:

• “Jimmy” on the Marketing (or Sales, Marketing, Support, etc.) team has lots of domain expertise and understands customer needs really well, but he’s disorganized and doesn’t like to sweat the details. He travels a lot so is often unavailable to answer questions. He also has limited tech experience and has no idea how tech products get built. And he’s always randomizing the developers so they hate him.
• “Victor” is a junior PM with great organizational skills, good rapport with engineers, but isn’t very familiar with the market, isn’t plugged in with the Sales team, and isn’t comfortable presenting to or defending his decisions to the management team.

Naïve managers might think that the right solution is to put Jimmy in charge of roadmap and product decisions, while Victor can focus on executing those decisions by working with engineers (and everyone else) to get the product shipped. Jimmy likes this because he can direct the product without getting sucked into the weeds. Victor likes it because he can stay in his comfort zone: working with engineers and focusing on “process”. Everyone wins, right?

Wrong. It’s not like building a tech product is like plugging a roadmap into Google Maps and blindly following directions for 500 miles. Building tech products is like a NASCAR race where the driver and the pit crew are constantly making thousands of decisions—large and small—to make optimal use of scarce resources and to beat the competition. If you slow down your decisionmaking process or reduce your decisionmaking quality, then you’ll lose the race.

To make decisions well and quickly, you need one person who’s empowered to make decisions and who has context (business, technical, interpersonal) about why those decisions are and should be made. That person doesn’t need to have the job title “Product Manager”, but they do need to understand the business, understand how tech products are made, and to be consistently available to work with engineers and others to make decisions and tradeoffs. “Jimmy” never has the bandwidth nor inclination to do this. He’ll get bored!

Your best answer is only to hire PMs who have both great business/product sense (“what should we build?”) and great execution chops (“how do we get it built quickly with high quality?”).

But life isn’t perfect. Imagine you have a flaky Jimmy and a shy Victor on the team. How can you make it work? Here’s what I’ve done in the past in similar cases:

First, I’d send Victor and Jimmy on a road trip for a few weeks to visit customers. Jimmy’s job is to educate Victor about what the market needs. Victor’s job is to absorb knowledge from Jimmy and the customers they visit. The goal: Victor should be able to answer most basic questions without having to bug Jimmy, and also should learn which questions are complex enough that he needs Jimmy’s advice. I’d have engineers go with them if possible— the more the merrier to learn about the customers being served.

Then, when the team is back in the office, Jimmy, Victor, the lead Engineer, and other senior team members should lock themselves in a room for a day or two and hash out a draft roadmap. Given that they’ve all seen the same customers, firsthand, getting consensus is easier than you’d think.

After that, Victor should keep Jimmy closely in the loop, ideally with regular 1:1s so that they can discuss progress, solve problems, and ensure that Jimmy feels involved *without* having to directly bother the engineers. When it’s time to present progress to the management team, Victor should present but should pre-review with Jimmy so that Jimmy supports him publicly when the heat is on.

But on a day-to-day basis, the team should know that Victor is the go-to person for product decisions.

And if Victor can’t do this, then you probably need to go recruiting a “Caroline” who is capable of thinking about both business and execution at the same time.