At a high level, product managers across any product uses the same range of methods, tactics, and skills. As you get to know different products, businesses, lifecycle states, and types however, the skill sets of product management needed will specialize. A PM working on hyper scale user acquisition for a SaaS product will have a different focus than one operationalizing a hardware product with a multi-million dollar, five-year lifespan plan. If you’re a PM or aspiring PM who loves deep technology, enterprise products provide a deep well of career and learning opportunity.

Enterprise products are a different animal than most however. Wikipedia has a succinct definition for enterprise software. ‘Computer software used to satisfy the needs of an organization rather than individual users.’ In my experience, enterprise software has many other connotations based on the expectations that organizations have of them. This is where the enterprise definition is really critical.

‘Computer software used to satisfy the needs of an organization rather than individual users.’

Enterprise product solutions are not household names. From the point of a regular person, you may have never heard of the companies or the products in this sector. These products power the things you use every moment of the day. From the technology stack running the browser on the device in your hands now, back to the datacenter it’s reading from, instantly across the Internet. Even everyday items you might not think about. E.g. The power grid that keeps your house warm and lit, or the supply chain systems that keep groceries arriving at your local store from thousands of farms around the world daily. The names of these companies that make this happen often remain hidden. Instead you know the final names Walmart, Chevrolet, Netflix, and AT&T. Some enterprise company examples include:

• Server/Storage/Network Information Technology (IT) E.g. Nutanix, VMware, NetApp, Cisco, DellEMC, HPE
• Cloud Computing E.g. AWS, Azure, GCP, Alibaba Cloud
• Enterprise Resource Planning (ERP) E.g. SAP, Oracle ERP Cloud, Dynamics 365
• Customer Relationship Management (CRM) E.g. Salesforce, Marketo, Dynamics 365

IN CASE OF FAILURE DO NOTHING

The reason that enterprise products are so complex comes down to some key rules and principles. Many of these boil down to requirements for hands-free resiliency. Failure is expected and failure handling is built-in. If my phone freezes I can power it off and on again. Annoying but no big deal. If a hospital patient monitoring system server freezes and stops working; someone (or many) may die. This failure outcome can be catastrophic. Product failure planning is a key requirement that is baked into enterprise products from day one. If this sounds dramatic, consider the following examples of things you never want to fail.

• Hospital equipment and monitoring systems that keep patients alive
• Air traffic control systems the keep planes in the sky
• Banking systems keeping you fed and housed via reliable wages access

If these systems fail, the results can be very bad. The way enterprise products address this is to build for reliability. When failures occur, these products already have mechanisms to keep working and fail over, rebuild, restart, etc. Performance may go down, but the application stays up (online and working).

7 LAWS OF ENTERPRISE PRODUCTS

If you’re an aspiring product manager, or a PM who has not yet worked in enterprise, below is a set of 7 laws that pertain to building and offering enterprise products. These help describe why enterprise products are complex and different.

1. THE FIVE “9”s LAW

Enterprise software is supposed to never go unexpectedly offline. High availability is a requirement and is often expressed in terms of ‘nines’. The most common ‘nines’ definition is “Five 9s” which means your application must have an availability percentage of 99.999% (count five 9s). That amount of uptime only allows you to have 5.26 minutes of unplanned downtime per year. To achieve that, enterprise software builders and PMs have to think intensely on how their solutions deliver this. Failure to deliver means you will lose this customer.

2. THE REDUNDANCY LAW

In service to the five 9s law, many datacenter hardware solutions have duplicate parts that do the exact same thing. Servers have two CPUs, two power supplies, two network connections, etc. This is based on the expectation that all hardware components eventually break. Software code isn’t usually duplicated, but software can also provide multiple ways to recover according to your needs. Each part builds resilience themselves, or rely on a resilient platform they get deployed on (i.e. virtualization or hardware). If that’s not enough redundancy, customers will also design and build to include hot hardware spares just in case.

3. THE MUTUAL CERTIFICATION LAW

For platform products that bring together different vendors, customers demand in most cases that all software and hardware providers cross-certify each other’s solutions where relevant. This is a large burden on the enterprise product providers to ensure. The customer requires that there is no chance that any vendor they use will declare any part of their environment unsupported because the risk is too high.

4. THE SUPPORT LAW

Customers of enterprise products demand support. Unsupported products are for pure open source fans and hobbyists. When customers need help to solve technical or functional issues, they require a defined process on how to get a hold of the vendor that built the product. There is a ticket system, an escalation path, a response team, and a follow-up system to ensure customers are taken care of. Enterprise customers demand that they can call a vendor and know that the phone will always get picked up. Many companies even offer 24 hour a day support across different geographies.

5. THE SLA LAW

SLA is Service Level Agreement. When things break, customers pay for and demand a response within a known time frame by the vendor. That might be a ticketed support case, a shipped piece of replacement hardware, or a phone call from your provider. Not every issue can be fixed in a predictable time frame, but response SLAs can be delivered. This is often an attribute of a paid support tier. You can usually pay more for a premium, faster SLA.

 

6. THE SERVICES LAW

Often called Professional Services, these exist to give customers access to specialized skills for installations, scripting, procedures, etc. which they pay for. This might not sound like a law. It may sound like an upsell, and sometime it is. More importantly though, customers often need expertise in order to be successful. Enterprise products are not iPhone apps. They connect into tens of other enterprise applications like Active Directory, ServiceNow, CRM, ERP, DNS, etc. Services can help your customers be successful in getting your product connected and running.

7. THE AUTOMATION LAW

A great consumer grade UI and UX has become the standard for modern enterprise products in the last 10 years. Before that UI was included, but UX was not. I’ve seen a lot of terrible legacy user interfaces in past years. At scale today, however, big enterprise customers also require access to documented APIs for automation and code-based usage of your product. The UI is still useful, but for at-scale customers it is not the primary consumer interface.

While thinking about the laws of enterprise products I also noted down several thoughts or axioms which didn’t quite feel like laws. I felt these were relevant and useful to include.

7 ADDITIONAL ENTERPRISE OBSERVATIONS

1. ALL SOFTWARE HAS BUGS

No one likes bugs, but they exist. Even perfect software will have unexpected behavior when something new is introduced into the ecosystem. E.g. Perfect software gets deployed on hardware from the same vendor, same model, but with a brand-new CPU generation? Or a new configuration? Or a swapped out device? Hello new bug. You will always be tuning and improving your product. Given quality support your customers will stay with you through the bumps. If you think your favorite software has no bugs, your vendor probably spent millions of dollars over the years in development, testing, fixing, patching, and supporting the software which you didn’t see (which is the way they want it).

2. YOUR USER IS NOT YOUR BUYER

The person that approves the PO (purchase order) for your enterprise product purchase is usually not remotely the person that will use it. This is very different than consumer software and hardware. When I buy a new car, phone, or TV subscription, I am the consumer who will use it, and I decide if I make the purchase. In enterprises, you have to sell to two different audiences at once; the end user and the management chain. Even then there may be groups like Procurement or Accounts Payable involved. Sales teams need to convince the user since they influence the purchase decision. They also need to sell to the management director, VP, or higher to get the purchase agreed-to and sold. These can be very different groups.

3. ENTERPRISE BUYERS TIME PURCHASES

Your customers will time when to buy to make it most advantageous to them. Expensive software requires budgets and approvals. A full datacenter rack of hardware and software, plus support, can cost more than a house in some parts of the United States. Customers therefore, align their needs to budget availability, approval windows, and time of the vendor’s quarter. Others will simply time when in the quarter they are able to get the best price, provided they can afford to wait for that given their business needs. I.e. If I wait until the final three days of your quarter, and you need to make your number, I can negotiate a better discount. It’s pretty similar to buying a new car off the lot.

4. RELATIONSHIPS WIN MORE OFTEN

Unlike many consumer goods, you can’t just go to the store and buy what you want, or buy them direct from the vendor. These products are often sold via a “channel” of vendors which specialize in these kind of products. These channel providers are known as Value Added Resellers (VARs) and System Integrators (SIs). As a customer you will have a relationship team that supports you from the product vendor and the reseller channel vendor. The best account managers and sales teams build long-term relationships they can benefit from for years. Superior teams also solve customer problems first vs. selling product first which strengthens relationships and puts you into the coveted trusted advisor role. FWIW, trusted advisor is not a self-appointed title.

5. VENDOR LOCK-IN CREATES TENSION

Customers hate vendor lock-in. Lock-in is when a single vendor provides the only hardware or software solution they use, making it procedurally hard or financially painful to get out of. Replacing datacenter solutions isn’t like choosing between Safeway, Trader Joe’s, and Whole Foods grocery stores. Unlike shopping for dinner, switching cost in the datacenter is high and slow. Vendors get more pricing leverage when they’re your sole provider. Vendors also use pre-paid, multi-year entitlement agreements to keep customers on their solution. E.g. I’ll give you a significant percentage off the cost for a 3-year agreement if you pay up front. That creates product commitment by the buyer, and difficulty of an alternative vendor to sell into that customer who already paid for a different product.

6. GUARANTEED RELIABILITY IS VERY EXPENSIVE

Resiliency under all circumstances for specialized, hard use cases and problems creates valuable, but expensive products. Enterprise-scale products are big ticket items to purchase. This creates high customer expectations back to the company, the product manager, and the product.

7. YOU (THE PRODUCT MANAGER) WILL BE ON CALL

When you’re the PM for Google Chat or Facebook News Feed with millions of users, it’s probably challenging to have direct relationships with your customers outside of coworkers and friends who use the products. When customers of enterprise products are unhappy, however, they will contact their Account Manager (sales rep) and Sales Engineer and let them know. If it’s a hot issue, it will escalate (sometimes via your executive team). As the PM you’ll then be on call communicating to the field team and the customer directly. Your customers will get to know you, and know that they can speak to you if needed. Your professional demeanor and polish will help in these situations.

BECOMING AN ENTERPRISE PM

If this world interests you, you can have a long career digging into ever deeper technologies and customers. It can be a lot of fun too. I’ve written about how to enter the field of product management, Breaking Into Technical Product Management, and The Product Management Career Decoder Ring, in previous posts. While those still apply, it’s important to note that enterprise products are often very technical since they often solve technical problems. This is why you’ll often see PMs with engineering and computer science backgrounds in these roles. If you don’t have that background, but really want to work in this area, you’ll have to work to build the baseline understanding required to be effective as a PM for these products.

ABOUT LUKE

Luke Congdon is a career product manager living and working in Silicon Valley since 2000. His areas of focus include enterprise software, virtualization, and cloud computing. He has built and brought numerous products to market including start-up MVPs and billion-dollar product lines. Luke currently lives in San Francisco. To contact, connect via luke@lukecongdon.com or https://www.linkedin.com/in/lukecongdon/.