Product Management for the Enterprise
(Interested in more on this topic? Check out my book with co-author Ben Gaines from Adobe Analytics: Building Products for the Enterprise. Coming very soon from O’Reilly Media!)
In the last several years, we’ve seen an explosion in the number and quality of resources for software product managers to learn from and use. The WSJ reports that “Product Manager” is now one of the most highly-coveted job titles for new MBA graduates (read into that what you will), and experienced PMs are now increasingly finding their way into more prominent executive roles at tech companies. The combination of technical savvy, business-level perspective and operational experience can make Product Management into a springboard into a wide number of other roles. It’s a great gig!
Yet something I’ve noticed is that the large majority of product management resources out there are heavily geared towards consumer technology. Take that WSJ article, for example — you see prominent names like Uber, Twitter, Amazon, Facebook, Etsy — and, of course, the granddaddy of them all, Google. Look around at most major product conferences (these exist!), and you’ll see the same. The explosion of consumer web companies, particularly in Silicon Valley, and the resulting organizational norms that have emerged and spread have created this large and expanding crop of consumer product managers who are eagerly defining their field as they go along.
As an enterprise software PM, I love all of this stuff. Yet I also find that I struggle to apply much of it to my job. Enterprise software is… just different. A lot of tech folks whose experience is on the consumer side don’t always understand this, so I thought I would try to explain why, and hopefully share some of the lessons we’ve learned.
Everything flows from the business model
While the big difference between the consumer and enterprise software markets is probably obvious, its impact on the product management function isn’t always the same.
Consumer tech comes lots of flavors: ad-supported, marketplaces, affiliate models, direct sales, and more. Most are fundamentally scale businesses in the winner-take-all world we live in now. In a scale business, you have a large number of customers and must make pricing, product, support, technology and business decisions with all of them in mind.
In the enterprise market, we live exclusively in the direct-sales (/subscription) model, and scale usually matters a lot less. We sell sophisticated products to a much smaller group of paying customers who are often quite big and complex. And here’s the thing: it’s actually pretty difficult and painful for most companies to buy, implement and start using new software. Resource discussions must happen internally. Budgets must be allocated. Sales calls are made. Negotiations happen. Contracts are signed. Training happens. There’s an implementation process. And lots more besides.
As such, most of those consumer tech assumptions don’t hold. I’ve managed products in the past that had run rates in the millions from only a few dozen customers. In that world, individual clients — and individual deals with those clients — matter a lot. One major client can request a product change that disrupts that nice roadmap you had all planned out — and no matter how much you resist this happening, it inevitably does.
Ironically, I often think enterprise PMs are closer to our customers than our counterparts in consumer tech.
Here’s what this means for enterprise product managers: first, we must work closely with sales and marketing. Sometimes this only means going out to meet with a client or prospect to help close a deal or gather feedback; more often, it means working with sellers, sales engineers and architects to craft, or even build, a specific solution to bring to a client. Ironically, I often think this makes enterprise PMs closer to our customers than our counterparts in consumer tech. We just have fewer of them, and must constantly justify their (big) investment(s) in our products.
Yet while sales support is part of the job, PMs are not sellers or sales engineers. A recurring challenge for most enterprise PMs I know is how to stay focused on longer-term product development and not get too distracted by sales needs. I firmly believe that in a direct-sales company, sales is everyone’s job — but it’s more some people’s job than others.
“Move fast and break things” is a recipe for disaster
I had a real meeting the other day where our 2018 product roadmap was mentioned. We were only half joking.
When big companies pay you millions of dollars for software, the last thing they want is major, unannounced and unexpected changes to the product. Upgrades, yes; bugs, no. This is even more true for business-critical applications like the ones I’ve spent my entire technology career working on, like digital analytics, marketing intelligence and ecommerce platforms. If one of those goes down, it’s not just annoying — it’s lost business. The stakes of failure are potentially huge, and not just because customers expect the product they paid for to always be available. (At least for cloud software, where I have spent my entire tech career. My many colleagues whose experience was first in traditional on-premises licensed software were used to two, three or four-year cycles in product development!)
I really admire the legendary “hacking cultures” of fast-moving consumer companies like Facebook, where stuff is conceived, designed, built and shipped in a single sprint a week long. It sounds like fun! If we did that, the sky would probably fall — and we don’t have time anyway.
Enterprise software companies have nearly all been moving to cloud, which means adopting Agile, continuous delivery frameworks. Believe me: this is really, really hard if you didn’t start out there, for reasons that probably deserve an entirely different blog post. (Noted!) Even for those companies that did, product delivery for enterprise customers requires lots of planning, coordination and careful work by many different teams, often with product managers right at the center. It’s stressful, but rewarding, work — and it doesn’t happen by hacking your way to a “good enough” solution. Which brings me to…
What is a Minimum Viable (Enterprise) Product?
We’ve all seen this explanation of “what is an MVP,” right?
Make something basic that works, and iterate on it until it’s awesome. Easy, right? This conceptual model makes perfect intuitive sense, and is a good framework to think in. It probably works great if you’re building a mobile app or a consumer service. It does not work at all for enterprise software.
Most companies don’t like to buy widgets — they want well-baked solutions to business problems they face. The dedicated sellers who sell your software must demonstrate how their product solves those problems, which usually means doing more than one thing well. Once you solve one set of problems, it’s a lot easier to start solving others as well, which leads to the classic “land and expand” strategy for many enterprise platforms. This is one of the most important ways platform companies build their business — by “farming” opportunities for expanding the footprint in client organizations. (Every company’s sales org should have “farmers” working in parallel with the “hunters.”)
Solving simple business problems isn’t going to make you any money — solving the hard ones does.
A lot of enterprise software is pretty specialized. It takes a thorough understanding of use cases and business problems your users face — which, in turn, often requires you to deeply understand your users’ business in the first place. Solving simple business problems isn’t going to make you any money — solving the hard ones does. And doing that takes time, focus and attention to detail, not hacking stuff together in isolation.
Obviously, none of this is to say that rolling out features in development, maybe still in beta, can’t or shouldn’t be done. Indeed, a lot of clients love testing out new bleeding-edge features, and we want their feedback. It’s just that it’s pretty difficult to actually sell an “enterprise MVP” to a net-new customer. There are likely to be better-developed substitutes they could use at a lower price, or a competitor who is already offering something like it.
Your Customer ≠ User. Appeal to both!
In a lot of companies, and particularly big ones, the person who actually uses your product probably is not the person who signs the check to pay for it. Understanding this difference is critical, and it has big implications for product management.
Paying $100k or $250k or $1M per year (or much more) for an enterprise software subscription/license is a pretty big deal, even at a big company. That’s usually a VP, SVP or C-level signature on your check, and s/he is going to need a clear justification for that investment. This is one reason why virtually all enterprise software is packaged into “solutions,” because “solutions” solve problems that executives have. These folks are your customers, and they have specific pains that must be addressed first and foremost, or there’s no deal.
Your users, on the other hand, are typically way further down the food chain. They’re the front-line, in-the-trenches operators — analysts, managers, sellers, buyers, reps. They report to those budget-holders above, or their bosses (or bosses’ bosses) do. Sometimes, these folks have significant input into the vendor selection process; but often, they don’t. Nevertheless, these folks will know your product inside and out.
Enterprise software that appeals to the first group, and not the second, is the kind that everyone hates but which lives forever. Since I’m not an IBMer anymore, I can use Lotus Notes as a prime example.
Literally no one likes to use Lotus Notes. Truly, it is a horrible piece of software. Yet guess what? It’s still a one billion dollar business for IBM.
How could this be? Well, Lotus Notes is basically a very secure database product with an email client layer strapped on it. It is deeply embedded at lots of huge organizations whose conservative CIOs are reluctant to take on the risk, expense and bother of ripping out a business email solution that basically works, is super low-risk and has low renewal fees.
So executives’ needs trump those of their underlings, whose silent screams of horror are lost inside their Lotus Domino servers.
Indeed, enterprise software has an unfortunate bad reputation of suffering from crappy design. This schism between its customers and users is mostly what’s to blame. Executives pay first and foremost for functionality and business value, not pretty UIs. This has begun to change, however, as SaaS is beginning to force a greater attention to user experience and ease of use. Adobe Marketing Cloud and Salesforce are great examples of this. (We’ve also paid keen attention at SAS.)
The evolving role of design in enterprise software development is another great topic deserving of its own separate blog post. Noted!
Good resources for enterprise PMs
I learn a ton about my own market, and product management generally, from twitter and blogs. If you’re looking for enterprise PMs to follow, I highly recommend these:
- Adobe’s Ben Gaines and Joe Martin
- Percolate’s Carmen Sutter
- Constellate Data’s Matt LeMay
- Salesforce’s Dan McCall
- Demandware’s Vinod Kumar
- HubSpot’s Jeremy Crane and Mike Champion
- Got more? Let me know, and I’ll add them!
You’re also welcome to check out this Twitter list I keep: PMs, devs, bears. It’s filled with about 280 of the most active product managers, developers and (yes) bears I’ve noticed on the Twitters.
A lot of folks know about it already, but no list of product management resources would be complete without a shoutout to Ken Norton’s “Bringing the Donuts” newsletter. Ken is a partner at Google Ventures and works with PM and engineering teams from across their portfolio. His newsletter is great stuff.
About me: I’m a Principal Product Manager at SAS Customer Intelligence. I’ve previously held senior product roles at Demandware and IBM’s “Marketing Cloud” group. I live in Chapel Hill, North Carolina with my wife and our two dogs. I’m on twitter.
Recommends appreciated. 👇🏻
