Being the product manager of a B2B (aka enterprise) product may not seem all that glamorous when compared to B2C. While everyone is talking about the coolest Pinterest, Uber, and Airbnb features, the work of an enterprise software PM is rarely considered “sexy.” What are the intricacies and complexities of this “underdog” B2B PM world? What is rewarding about B2B product management? Can you have a blast building enterprise products?
Features vs. Aesthetics
Remember the “I’m a Mac and I’m a PC” commercial? That’s the image I sometimes get after attending product management gatherings, especially in Silicon Valley. B2B products are more abstract than their B2C counterparts. It’s more difficult to relate to and even explain what you do if you work on a complex enterprise software product, especially those used by IT departments or those focused on a narrow industry vertical.
In B2B, it’s often all about features and checkboxes rather than aesthetics, beautiful UI, presentation, and ease of use. And there is a reason for that. First and foremost, business buyers are hiring your product to solve a problem rather than provide an experience. Hence, they are looking for those features and checkboxes. Moreover, the enterprise product buyer is rarely the actual end user of that product. In some cases, they could care less about how delightful (or not) the user experience is.
Of course, there are a few “cool companies” in the enterprise software world. Slack definitely comes to mind. However, they are the exception rather than the rule.
Ok, let’s double-click on the B2B specifics. Below, I’ll cover five not-so-glamorous areas of B2B product management. And in my next piece, I’ll share five reasons why B2B product management is actually really cool.
Lack of Visibility
While the B2C world is swimming in data, B2B PMs are often struggling to understand how their products are being used. This problem is especially acute for on-prem software, where sometimes you get no telemetry and don’t even know if your product is being used at all. At one point, I owned a seven-product security suite and I realized that we had no idea how many and which of those products were actually been used. After a quick survey, I learned that the number was less than two!
What complicates things further is that the buyer and the user are often two different personas in the B2B world. So it might be quite difficult to get to the actual user for any kind of feedback. If you sell through the channel, that becomes even harder.
Finally, scale. Enterprise software is rarely used by millions. More often than not, you have a few hundred or a few thousand customers. In many cases, it’s almost impossible to do things like A/B testing that are so common in B2C.
Do you remember when Microsoft released Windows XP? It was back in 2001. Even the extended support for it ended in 2014. Believe it or not, we still encounter prospects with Windows XP in their environments. But forget XP. Windows 7 was released in 2009. At the last two startups I’ve worked with, we’ve encountered thousands of systems that were never updated or patched from that original 2009 release.
Similar story with Internet Explorer — sometimes an enterprise is using some browser or OS-specific application and cannot upgrade for a variety of reasons. Now, this becomes your and your product’s problem.
Large enterprises often have unique requirements that they will want you and your product to fulfill and support. They may ask for in-depth documentation or support for some operating systems that you may not have even heard of. For example, at one of the companies I worked for, many of my products had to support well over a dozen different operating systems and versions: about ten versions of Windows, a number of versions of macOS, few versions of Linux, three flavors of UNIX (AIX, HP-UX, Solaris), virtual environments, etc. Imagine that support matrix for QA! Don’t be surprised if your release cycle slows down dramatically with all of these platform requirements.
Even product licensing can get unnecessarily complex. I remember having 550 SKUs on the price list for a specific product portfolio. You couldn’t figure out what to buy even if you wanted to. All these add-ons, packages, and editions tend to pile up, resulting in a complete mess.
Finally, custom requirements = a true product killer. Don’t become a custom development shop. Learn how to say no or you’ll end up building a Frankenstein.
Everything Is Slow
It is not uncommon to have 9- to 12-month sales cycles for complex enterprise software products. When selling to the federal government, this can be as long as three years. Agonizing!
As a PM, you probably think all customers want to be on the latest and greatest version of your software and can’t wait to enjoy all those newest bells and whistles that you added in the last sprint. The reality is that people hate change! They get used to doing things a certain way and in most cases, don’t appreciate having to learn a new way. Moreover, some organizations have very strict change control where they may only be able to adopt new versions of software a few times per year.
“Move fast and break things” is a definite recipe for disaster in the B2B world.
FIPS 140-2, Common Criteria, VPAT/508 compliance, FedRAMP, HIPAA, PCI DSS, SOC 2, ISO 27001 — this acronym soup is well-known to B2B PMs. Especially when selling to the government, security certifications and other compliance requirements can become a nightmare. In many cases, this isn’t something that is optional (although there are creative ways of partnering as well as leveraging pre-certified components). What is important to note is that often this isn’t something you can achieve in a matter of a sprint or two and may require not only product changes, but changes to company processes.
One time, one of my products got committed to supporting some obscure UK encryption certifications. It cost us tens of thousands of dollars and went on for over a year. Opportunity cost? Millions!
Sounds pretty daunting! Who would want to work on something like this? Well, it’s not all bad in the enterprise world! Stay tuned for my next post on all of the good things about B2B product management.