When I first got interested in moving into product management several years ago, I basically read a lot and asked around to understand more about the role and what it entailed. A lot of what I was found is still the conventional wisdom of Product Management: what they call the “mini CEO” model. As its name implies, this idea puts the PM at the center — or perhaps the top — of a system that produces a product.

Over the years since, across different product roles in different companies, I’ve had to un-learn a lot of that. Today, I mostly reject the “mini CEO” model of Product Management. Here’s why.

Enterprise vs. Consumer

A great deal of the growth and popularity of the Product Management role has come from the influence of meteoric success by consumer web-focused companies in Silicon Valley. Google, whose APM program is legendary, is probably the best example; today, even VC firms are starting their own Product Management recruitment programs and independent bootcamps are sprouting up to teach Product Management wisdom.

Something that many of the highest-profile consumer tech companies (ex. Google, Facebook, Twitter, etc.) have in common is their business model. They are fundamentally in the advertising business, not product sales, and monetize users’ eyeballs on their site or app(s). This means that their “users” and “customers” are explicitly not the same. By attracting and retaining eyeballs with compelling, engaging user experiences, they sell more and better (higher value) ads. In that world, a PM’s role is not just to make the product better; it is also, and perhaps more directly, to keep the user engaged, and delighted, for longer (the better to show you more ads).

The most important difference I’ve discovered in “consumer” versus “enterprise” product management really comes down to business model.

In enterprise tech, you truly have a customer — one who pays you money, often a lot of it, for your product. While your user and customer may be (indeed, usually are) different people, they represent the same company with similar interests, and understanding the problems and needs for each is critical for success. Ben Gaines, the senior PM for Adobe Analytics who’s something of a legend in the digital analytics world, wrote an outstanding post recently clarifying the differences between “user” and “customer” problems, which I strongly recommend because he does so better than I can.

When your user is also your revenue source, it forces a different prioritization of needs and focus than when user engagement is a means to an end (selling more ads). That isn’t to denigrate the ad model, you understand — only to highlight the alignment of interests between an enterprise PM and her or his users. When I was a Product Manager on Coremetrics, I personally met with a sizable percentage of our clients to better understand their use cases, which is something a Facebook Product Manager will simply never be able to do. Client feedback and requests are considered in the context of their likely impact on renewal rate and new bookings, which brings Product Management a lot closer to the Sales and Marketing organizations than it would be otherwise.

(I believe this bifurcation between users and revenue sources in product-vs-advertising businesses is also one source of the heavy engineering-led company cultures in many companies, like Google. It changes the leverage that Sales has in discussions about product. But that’s for a different post.)

For consumer tech companies that are based on product sales — like Amazon or Uber — Product Management is arranged in a similar way.

“Pyramid” versus “Capstone” Product Management

The other problem with the “PM as product CEO” model is that I’ve never actually seen anything like it in real life.

Product businesses, particularly in enterprise software, also tend to come in portfolios that are broad, fairly complicated, and which do more than one thing. Product portfolios, of course, need more than one Product Manager. Our team at SAS, like most enterprise counterparts I’ve seen, has multiple PMs building a single platform (SAS Customer Intelligence) and working as a team. There are no CEOs, “mini” or otherwise, on this team — even the group leaders work as team members so that we can collaboratively decide what to prioritize and what must wait in the context of the “CI” business as a whole. But we’re all aligned around our goal: to meet the customer’s needs and create value that far exceeds the price that customers pay us.

There is a model of Product Management out there that puts the PM at the top of the pyramid. If you’ve seen AMC’s awesome series “Halt and Catch Fire,” this is the Joe MacMillan model — less a “Product Manager” than a “Product Czar” whose word is law and has complete control over all aspects of the product.

This model is still out there, though it is far more common in either legacy hardware platforms (like servers or mainframes) or in early-stage startups (who either haven’t begun to scale or have only one product to sell).

More common is what I’d call the “capstone” Product Management model, wherein the PM isn’t “in charge” per se, but rather acts as the key facilitator — the capstone — to align and coordinate all of the other critical functions in building the product, like engineering, design, testing/QA, sales, operations, marketing and finance.

A solid Product Management organization working in tandem.

The reality is that, in most organizations I’ve seen, Product Managers often have little formal “control” over those other teams. I may define priorities and planning with my development team, for example, but I work within their constraints set by the broader engineering group. I give guidance to marketing, sales and finance about what’s coming, but I also take direction from them for targets and key events. The thing to remember is that each team, left to themselves, has inevitable biases: Development will always want more time; Sales will always want to build one-off fixes to close an end-of-quarter deal; Marketing will want the UI to look like Apple’s; Operations will want more infrastructure; and so on. The Product Manager’s job here is to be the central player who keeps his/her eye on the prize: to grow sustainably, meet customer needs, and understand their market with a big-picture view.

Working with Sales can be especially tricky. In consumer tech, where quarterly deal volume might be measured in the thousands with relatively low dollar amounts, Product Management can interrogate that aggregate deal data for a clearer idea of what customers need and where they’re moving. In enterprise tech, of course, the figures are reversed: comparatively low deal volume at significantly higher dollar amounts. There is, of course, valuable quantitative data to be gleaned, but there’s also a qualitative element to every deal (particularly big ones) that Product Management can only learn from working closely with Sales. In my opinion, working with a really good sales leader is probably one of the most valuable professional development experiences a Product Manager will ever have.

When you start thinking of your Product Management role in this way — as an enabler for each of the teams behind your product to contribute most to sustainable growth — the job gets easier. It’s easier to give an enthusiastic “yes” to some requests and a polite, but firm, “no” to others. Crucially, it also forces you to grapple with some of the aspects of your business that you don’t know as much about: your content delivery network? Unit contribution? User permissions framework? All stuff I’ve had to get smart on quickly in my time as a PM.

One day, maybe I’ll learn the ropes on the consumer side too. For now, though, enterprise tech is keeping my hands full. Time to go learn about data federation tools…