An Enterprise Primer

So perhaps you’re burned out in the consumer software game, or are just considering a pivot into the enterprise (“B2B”) market. You’ve heard that there’s a lot of opportunity in “selling to enterprises” – and maybe, you’re thinking, after you build some revenue there and make your investors happy, you can get back to the other world-changing stuff that you really want to build. Plus – most enterprise software kind of sucks, right? Users who have grown up with Facebook and Instagram are demanding way better experiences from the software they use at work, and you see an opportunity to serve those needs. So enterprise it is.

This is sort of a cardboard stereotype of a certain approach to enterprise software that I’ve seen voiced frequently – often by very smart, experienced people whose careers have mostly been in consumer-facing software. Well – it’s a very good strategy for failure. As a corrective, I offer this quick primer to some of the basics of how enterprise software is different. (I avoid the terms “B2C” and “B2B” as too jargon-y for my taste.)

Some people may have read my Medium piece on Product Management in enterprise software, which I think has held up pretty well. (If you like that, go check out our book on the same!) What I want to write about here is more about the enterprise software market broadly, rather than how it affects the PM function. I have to cop to my own ignorance first, though – I’ve never worked in consumer software, and don’t claim a high degree of mastery there. That said, so much of the tech industry atmosphere is marinated with consumer-facing perspective that you kind of absorb a lot of it by osmosis. But I’ll eschew making too many bold claims about it nevertheless.

That said, here’s some things you need to understand about the enterprise market first.

There’s no such thing as “enterprise”

People who haven’t worked in enterprise software sometimes have a very vague idea of what it really means. Often, they think of the products they themselves have used in past jobs. If your own career has been in marketing, you might think of Salesforce for CRM and Adobe Marketing Cloud or Responsys. If it’s in data science, you might think of Tableau or Hortonworks (or SAS!). Or if you come from the construction industry, you might know Procore or PlanGrid or Deltek Ajera.

Wait, what? If you’ve never heard of those last three, I’m not surprised – you probably just haven’t worked in construction project management! And that’s the point. Pick literally any industry, and you’ll probably find a whole ecosystem of software vendors who you’ve never heard of who know their market really, really well. Lots of people (especially many in tech) are very dismissive about software vendors they haven’t personally used, or even heard about, only to discover very quick that Silicon Valley pixie dust does not actually sell software.

The term “enterprise” is often thrown around as if it describes a type of company or industry. It does not – it describes only a market segment, usually one of larger companies with more complex needs, as opposed to smaller firms with simpler ones. “We’re making a play for enterprises” is the sort of thing people who have never built enterprise software say, because it’s sort of like saying “we’re building software for humans.” Rather, it’s smarter to build products focused either on specific industries or job roles that are reasonably similar across them.

This is certainly not to say that enterprise products with cross-industry appeal don’t exist; simply that they’re rarer and, in my view, much harder to build and execute on. (There are only so many Slacks.) Meeting enterprise customers’ demands quickly means specializing into features that are more relevant for some industries than others – which leads into my next point.

The user is not king

Let’s talk about users versus customers.

Our users are many of the same people as theirs on the consumer side. (Kind of – they skew older and better-educated, but you get it.) They’re just people doing their jobs. Sometimes those jobs are straightforward, and other times, they’re extremely specialized or complex. Sometimes, especially in knowledge industries, a person’s job is more like an area of responsibility, without an exact procedure for “doing the thing” – figuring it out is part of their job. In any case, they’re often using some software product that would have no real relevance outside the scope of their job.

Our customers, on the other hand, are rarely those same people. Few frontline employees have a budget, or the juice to make big software purchases on the company’s behalf. Their bosses, or their bosses’ bosses, do that. Depending on the type and size of the product, that might be a really big deal. A standard deal size for an “enterprise” product easily goes into the five figures, which typically means multiple levels of review and sign-offs. Some executive is signing your check, and s/he needs to be sold. (More on that in a bit.)

Executives tend to have markedly different buying criteria for software than their direct reports (who are usually the ones actually using it). There are a whole host of “institutional” criteria too, like IT security requirements, budgetary constraints, legal, etc., but these aren’t what I mean. All of those things aside, for an executive to pull the trigger on spending a lot of company money, they need to be convinced on the promise of your product to unlock value for the company. Distilling this question into “showing ROI” really kind of shortchanges it, because smart executives understand that not all tangible benefits are quantifiable in a business case spreadsheet. That said, companies’ bottom lines are, so packaging and presenting your product’s value proposition in a way that relates to helping unlock that value is critical.

Users matter. Of course they do. But it’s rare that our users are the ones actually buying our product. Do users want the software they use at work to be as slick, clean and easy as Instagram? Maybe they do, but so what? Even if that were possible in highly specialized software (and whether it is or not is up for debate), user delight isn’t always our goal.

Knowing what to build requires learning

If your executive customers knew how to build their business value, they’d be doing it already. But chances are, they don’t – or at least they’re not sure. That’s why they need your help. This is why you can’t avoid the feature/problem discovery process in enterprise software by just asking your customers what they want.

Every Product Manager in the history of enterprise software has stories of customers who bang the table for some desired feature, and then either don’t implement or purchase it when it becomes available. This happens for lots of reasons – budgetary, personnel changes, new strategies, whatever – but more often than not, the cause is pretty mundane: other shit came up. It happens everywhere! And it’s why you can’t outsource your enterprise product strategy to your customers’ wishlists.

The problem discovery process in the “enterprise” market requires primarily Product Managers to become quasi-experts on the industry/industries they sell into. In our book, we call this “Industry Knowledge,” and it’s one of the three critical domains of knowledge enterprise PMs must develop. You can’t really understand your customer companies, or how they build value, unless you deeply appreciate the industry landscape they work in. Once you begin to get that, then you gain context in which to understand what your users and customers are telling you; and that is where you can begin to identify opportunity.

Again, this is not to say we don’t listen to our customers (and users). Every PM I know has a long list of one-off feature requests in their backlog that they like to tick off as they can. But catering to every request is not a way to build a powerful enterprise product, any more than it is on the consumer side.

Learn to sell

Enterprise software does not sell itself. It needs a sales force, and they need a whole range of tools to work with – slide decks, marketing collateral, messaging, demos, you name it. The whole messy apparatus of selling software is often treated by the tech community as some kind of unpleasant chore, which honestly blows my mind. If you work in enterprise software, especially as a leader, here’s a tip – don’t hire anyone with that attitude.

The blog post I wrote on this topic earlier, Learn to Sell, is still my #1 most-viewed post of all time, and I won’t regurgitate it here. I will say that many folks fresh from the consumer software world tend to undervalue or overlook the importance of software sales/marketing, and too readily think of it in the consumer-ish “self serve” model. (Some find sales and marketing a sort of unpleasant chore at all, which… ain’t a good sign.)

Building, managing and incentivizing a productive sales force is really a fascinating process in and of itself. There is natural tension to be found between the demands of a sales force that wants to close as many deals as possible this quarter and a software product organization that builds for the long term. That’s an organizational and leadership challenge that I may write about later; but for the purposes of this post, I simply posit that it exists and must be planned for when building in enterprise.

There’s a lot more to say about the differences between consumer and enterprise (the business model!), but this is getting long, so I’ll stop there. If you want more, check out our book, or some of the other posts I’ll link to below.

And if you’re thinking of breaking into the enterprise segment, I highly recommend it! There really is a ton of opportunity here – but it’s not a place to coast because you find the consumer market intimidating. If that’s your strategy, you’ll be a lot of fun to sell against. 😉

 

Related posts:

 

[mc4wp_form id=”185″]

Standard