Product Management for Enterprise products

Even if you're a seasoned product manager, from the business model to the meaning of the word "customer," building products for companies is substantially different than building products for consumers. Here's why.

Product is hot. If you pay attention to the tech industry at all, you know what we're talking about. "Product manager" is one of the most highly-coveted job titles for new MBA graduates. Entire blogs, newsletters, conferences, even boot camps have sprung up around the tech world catering to people interested in the topic. Try putting "product manager" in your LinkedIn profile, and get ready to see a steady uptick in your recruiter spam. There is, in fact, a whole content and social network called Medium dedicated solely to sharing product management thinkpieces.

Yet we still have difficulty explaining to our parents what we do for a living. Neat summaries or the kind of pithy clichés ("the product manager is like a mini CEO!") you often see are either silly or, at best, very incomplete. We're not engineers. Nor are we marketers. We're certainly not "CEOs of the product." But we're the guys who everyone else looks to when there's a question about our products, or "how it's doing," or "what it needs" or "what [it/we] need to do next." And we better have a good answer for those questions, because we're ultimately the only guys whose responsibility it is to know.

In a mature, high-functioning software business, you have a lot of teams hustling around different aspects of a product (or group of products):

There is obviously engineering, which not only builds what they're asked to build, but tests and patches it for stability, quality, defects, and more.

In Software as a Service (SaaS) businesses like ours, there's an operations team that monitors the cloud platform and customer tenants and works closely with engineering (hi there, DevOps!) on releases.

There's sales, the folks who actually breathe life into your business. Sales can encompass everyone from lead development reps, or LDRs (sometimes called account development managers or similar) to account executives, to customer success managers, to sales engineers (or solutions consultants), all of whom are dedicated to acquiring, growing, and keeping business.

Marketing, whose array of specialty functions can be dizzying: digital, content, demand generation, social, events, brand, product and solution, and more.

There are "foundational" services like finance, legal, and even IT, that are easily overlooked but absolutely essential to making everything run. And there are plenty more besides.

Right at the nexus of all of these teams—neither above nor below, but working as a peer—is product management. "Product" leads in defining the product vision, establishing the operational plan to get there, and then executing on it. It harnesses the incentives built in to all of the other teams and aligns them toward a single destination. In this way, "PM" is an operational role, not really a technical or specialist one. If you'll permit us just one pithy metaphor, the product manager is a sheepdog; we don't necessarily dictate the destination, especially in business terms (an executive team often does that), but we generate a route to get there, a "roadmap," if you will, in terms each team understands.

We're also no one's boss. Product typically works with other teams, not over them. The product manager is no one's CEO and usually works with little or no formal authority to tell anyone what to do. Indeed, in most software companies, and particularly in enterprise software, one of product management's core functions is this cross-functional collaboration with many different teams to make sure that the team as a whole moves in the right direction.

In most high-functioning organizations, other teams rely on Product to help them do their jobs more effectively. Development relies on product management to define a plan and write user stories, requirements, and acceptance criteria that explain what needs to be built. Marketing relies on Product for product information, value proposition definitions, business case material, market intelligence and, sometimes, content. Sales relies on Product for much of the same, plus determining target market segments, demo cases, answering detailed inquiries, and helping to close deals. Finance and Product rely on each other to build the business through determining pricing, margins, discounting, and so forth. Leadership relies on Product for execution on overall product and business strategy. Across all of these cases, Product is the key index and what keeps all of them churning toward the same destination.

The tech landscape is just so broad, especially when you consider both consumer and enterprise segments, that we doubt if it's very useful to distill the product management function down into just one definition. No two companies will use the product management in exactly the same way. Perhaps being the "sheepdog" doesn't resonate with you. If not, we bet this will:

A friend of ours, Matt LeMay,1 was recently teaching one of his excellent courses on product management for O'Reilly. In it, he gave his students a quick learning exercise: he separated them into teams, representing different parts of the aforementioned business. He gave each of them certain resource restraints and a finite timeline in which to solve a product quandary. After a period of negotiating with one another, they came back to him, harried, confused, and a little panicked: "There's just not enough time!" they cried. "We can't complete all of these requirements, in sequence, in the time window you're asking for! What do we do first?"

After he explained this ingenious exercise to us, we laughed, because we all got the joke. "Welcome to product management!"

Three Things that Make Enterprise Software Different

There are really three big elements that make product management in enterprise software different: our business model, our specialization, and the split between our customers and users.

1. The Business Model

In consumer technology, there are lots of revenue models; advertising-supported is obviously very popular, but there are also two-sided marketplaces, affiliate models, direct sales (almost always self-service ones), and much more. In the winner-take-all world we live in today, all of these are fundamentally scale businesses. You have user bases in the millions (or tens, or hundreds thereof) and must make product, pricing, infrastructural, and technology decisions accordingly.

In the enterprise market, we operate almost exclusively on a direct-sales model, whether that means selling good old-fashioned licenses or subscriptions (as we do in SaaS). Enterprise is rarely a scale business. Though there are interesting exceptions, we mainly rely on direct sales to sell complicated products and solutions to a relatively small (compared to consumer software) group of sophisticated customers for large deal sizes. Those deals are negotiated, budgeted, implemented, and monitored for weeks, months, or even years! Sales cycles are long and complicated. (You can probably already see some obvious reasons why it can be very difficult for startups to crack this market.)

2. Product Specialization

Enterprise software is usually also very specialized and tailored to serving a specific technical or business need. Think CRM, business analytics, or data management. These are solution areas that become very complicated, very quickly. Our challenge as product managers is not only to make these tools deliver more business value over time with new features, capabilities, integrations, and so forth; it's also to understand how our users work, what their jobs and industries are like, and how our products fit into their lives. This is especially true after your product breaks out of the "point solution" category (i.e., meeting a very specific, constrained business need) and grows to encompass multiple different use cases, roles, or industries. (We talk about platforms versus products later on in the book.)

3. The Customer versus the User

The last big thing that makes "enterprise PM" tricky is who we're building for. Our users, who might spend a substantial chunk of their professional lives working in our product's user interface (UI), are almost never the same people who actually pay us for it. Our users work directly with our product to perform some function that allows them to do their jobs better, more easily, or efficiently. Our customers, by contrast, are nearly always those users' bosses (or their bosses, or even their bosses' bosses) who write the check.

When you're selling a product that has a five-, six-, or even seven-figure price tag, it's going to be an executive, not infrequently a C-level one, who has the budget juice to pull the trigger. These types of customers have a very different set of selection criteria than their direct reports, our users, who will actually be using our product day in and day out. Broadly speaking, they tend to care more about hard business results and return on investment (ROI) than a high-design UI and feature checklists. In our experience, they might touch the product in question, but they do not live in it day in and day out.

In some cases, your users might exert a strong influence on your executive customers. Executives might short-list a set of potential solution vendors with their department's input, or, often, they might have used a preferred vendor's product before. For scenarios in which the products in question are highly sophisticated and require specialized training or experience, this is more likely the case. Alternatively, there are lots of cases in which executive customers make their choices based on basic functionality and price, with little or no regard for user input (think call center or large retail point-of-sale software).

Very clearly understanding your user and your customer and how those two interact and influence each other is absolutely vital to being successful as an enterprise project management.

Should you focus on more powerful or flexible user features? An ultra-sleek UI? Expanded mobile support and great notifications? Or do you target additional integrations and adjacent capabilities that can provide "good enough" functionality to allow your customer to end their contract with a competitor? There is probably an infinite list of projects you could spend time on, but choosing which of these two stakeholders to over-serve, and how, will depend on you, the product manager, understanding which is going to best drive your product's success.

Are You Selling to Users First, or Customers?

There are some companies that make a deliberate strategy of conquering their market's total user base community as a backdoor into enterprises of all sizes. A "hearts and minds" route like this is a high-touch and often high-investment strategy requiring a product focus on the user experience (UX), great design, clear features, ample documentation, simple onboarding, and, often, a very heavy marketing spend. By evangelizing the product among subject matter experts (SMEs) and enthusiasts to make it a popular favorite, they're really relying on these communities to indirectly pressure the big companies they work for to "get with the times."

By contrast, other companies are renowned for having a direct line to the executive suite. They rely on brand and solution-level marketing, long-term relationships, executive-focused "thought leadership," and sheer sales savvy to capture business at the C-suite level. (These are the guys whose ads blanket every major airport.)

These strategies are rarely clearly articulated as such, but it's usually pretty obvious which one your company is taking. They are both proven, successful methods for winning a market. Each one has a quite different set of product implications that enterprise project managers should clearly understand.

Clearly differentiating between our users versus customers reveals a layer of subtlety to the problems the product solves, and therefore the value it offers. Whose problems does our product chiefly address? Our users or customers? Striking the right balance of that value will depend on your reading of your market and product strategy. One way to begin that process is to prioritize the problems we want the product to address. So, get ready for a deep-dive in the next chapter into a discussion of whose problems you're really solving.

Closing Thoughts 

Product management for enterprise software is crucially different than for the consumer market. Not only must we differentiate between our enterprise product's user and customer and the needs for each party that must be met, but our product's route to market and the way customers plan for and buy it are completely different from consumer software. Moreover, enterprise software typically operates with a completely different business model than consumer-facing businesses. All of these differences have significant upstream consequences for how enterprise products need to be planned, built, sold, distributed, and serviced.