Enterprise Software Product Management – A Buyer’s Perspective

As a Product Manager of Enterprise Software Products, you have a number of important stakeholders to manage. Most of the time, what is going to make any one of them happy, will cause another of them grief. Your stakeholders are the end-users, your engineering teams, your sales organization, your marketing organization, your support organization, your investors and of course your clients. You are the strong link in the chain. This post puts you into the shoes of the Enterprise Software buyer who will be putting their career on the line in selecting your product.

Why Enterprise Software should cost more

Enterprises are essentially a large number of people, possibly distributed across numerous locations following repetitive business processes. Usually there is a large amount of capital tied up in assets and then there is working capital required to keep the business going.

The people who are responsible for running the enterprise… executives, leadership, management and then all the way down to process owners – need to make sure that what is going on is effective, efficient and predictable.

When the Walmart ecommerce site is down they lose $40K per minute. Amazon loses $220K per minute. I’ve worked in the mining and metals industry, the cost of downtime in a mine could be $180K per incident. The reason for the downtime could easily be because the inventory file is not accurate. A common issue that could result from poorly performing batch up date jobs. The consequences could be shutting a production facility down because of an unavailable replacement part.

So given the costs of errors, decision-makers look to enterprise software vendors to lower the risks of downtime. Vendors do this by providing software that is equally effective, efficient and predictable. The Total Cost of Ownership calculation should justify the high price-tags of a truly Enterprise application

Put yourself in the buyer’s shoes

I worked for a European Insurance company with annual revenues exceeding US $64B, which classifies it as ‘Enterprise’. Our primary vendor was IBM, a classic enterprise technology vendor. During our software selection process, my 3-bullet mantra for my team as they evaluated vendors was:

“Does the product do what it says on the can?”
“Will it do it again tomorrow?”
“If it doesn’t and I need support at 2am, when I call you at home will you get out of bed?”

As a product manager of enterprise software products, you have a lot to consider. Those bullets provide a buyer’s perspective on how you will underwrite their purchase decision.

1. Does the product do what it says on the can?

During the sales cycle, you need to make sure that you are not overselling capabilities and not generalizing. Your product had better work in your clients’ environments with their users on their schedules. Buyers will always consider total cost of ownership, not the ticket price. If they have to do a tonne of integration work, buy new hardware, or re-skilled the development team, then it may not be worth it.

2. Will it do it again tomorrow?

What ever your product does, you need to guarantee performance for the conditions that your clients will to put it through. That means all the business as usual cases, spikes and dips in volume, with missing data, and when end users accidentally or purposely try to break it.

3. If it doesn’t and I need support at 2am, when I call you at home will you get out of bed?

When it goes down, your client will need your commitment that you are going to get it working again fast. They can’t afford that downtime so the support organization would need to pull out all the stops. If an emergency fix is required your clients will expect your developers to be working around the clock. Superlative account management will empathize with your clients’ pains while leveraging their authority and influence with the engineering organization.

Enterprise Software buying decisions

So what differentiates ‘Enterprise Software’ from Scientific, Packaged, or Cloud Software? Well most of the differences stem from a broad range of customers who are critically dependent on it running. The other areas are the varying usecases, edgecases and exceptions, an unpredictable run-time environment. Yet the wrench in the works is the large number of stakeholders that need to be kept happy throughout.

Now given there is a 6-, maybe 7-figure total cost of ownership amount, the buyer is going to be asking a lot. That’s what makes Enterprise Software so difficult and expensive to develop.

Buyer’s need: “Can I rely on it to support my business?”

“Will it function as specified?” – On the approved hardware and software platforms, it must perform consistently to specification under normal operating conditions. The trick here is agreeing what is specified, because feature-creep happens when you try to please all of the people. Product Management is managing expectations when one of your stakeholders cannot get what they want.
“How robust is it?” – When something exceptional happens, it should behave predictable, especially when it fails (e.g. not leave database writes incomplete). The product manager has the impossible task of expecting he unexpected
“How well does it scale?” – Has the software been designed to operate optimally at a scale that most customers will be regularly peaking at? What happens during both peaks and troughs in capacity? Does everything scale – number of users signed in, number of transactions, number of exceptions, number of CPUs if it’s being distributed, number of records in a master data file. You have to think of the number of anything that might impact performance, including the lower limits of those things.

Buyer’s need: “How closely will it fit my business operations?”

“How configurable & customizable is it?” – Can most features support most customer usecases out of the box? If not, either make it so, or refine your target market to make sure it can. What features are configurable and what would require customization? If too many vital features are customizable, you will have a large number of customers who cannot easily take an upgrade. If you have a professional services organization or implementation partners how would you factor their capabilities and cost into your configure vs. customize decision?
“How usable is it for the end-users, in all languages and territories?” – How has the end-to-end user experience been designed? It is intuitive for the types of user you expect? Getting your customer support organization’s input before your commit the UX designs will be a worthwhile investment, they have an immense knowledge that you can tap into. Will it be easy to translate and internationalize to the for territories and countries that you expect to market in? What is the investment trade-off in designing for internationalization and localization now versus in the future when you have been successful in your initial markets?
“Is it accessible for my impaired users?” Are you expecting visually or otherwise impaired users? Have you designed for those? If you are using third party tools how stable are those vendors? When you customize, configure, localize or internationalize, will the accessibility features stay intact?

Buyer’s need: “Is there sufficient rigor in your development process?”

“How extensively tested is it, and each bug fully regression tested?” – An educated buyer will expect a certain number of bugs, especially at the edge cases, but these should not be showstoppers. But these bugs should be far and few between. For bug fixes insist on systematic regression testing across the whole product where this is feasible. Automated testing is most often the way to go, and don’t forget to recheck the UX when a major fix is implemented
“How secure is the data, the algorithms and the authentication?” – Today’s enterprise software applications are written with a lot of connectivity and so must be secured against attack. The cost to your client of being hacked or there being a data leak is high, impacting sales, company valuation or the whole company going under. Data files must be encrypted for transfer and at rest. And the authentication must be rock solid. If you are using third party code, is that secure too?
“Is it compliant with whatever legal regulations are in force ?” What are the compliance regulations in your customer’s industry or worse, industries? Are the vendors of embedded packages and code libraries you leverage also compliant? How often are those regulations changing? And are you compliant in all territories you will be marketing in? And what sort of scrutiny are other vendors in your domain and locale coming under? Is the software easy to audit?

Buyer’s need: “What will make the application successful in my organization?”

“Tell me how you will support the application, my administrators and end-users?” – How can the application be designed to make supporting the customer easy? Can the customer support team easily window-in on or take control of the end-users’ screen? Is there a self-service issue logging system to minimize client wait time on support calls? How can you build a knowledge base of known issues and resolutions?
“What analytics do you provide out of the box, via your partners or can we build our own via APIs?” – Analytics is now a vital component of any enterprise software application. Reports and Dashboards should be either part of the base product or an uncomplicated add-on. For advanced analytics, make more granular data available via well designed APIs that allow efficient querying of the data. Again there is a trade-off as to how much of this can be done in early releases.
“Do you provide documentation & training for my administrators and end-users?” – Mobile applications are designed intuitively to not require documentation or training. However enterprise software supports complicated cross-functional business processes, will include policy and compliance and needs to be efficient to use. So your job will require consideration of how end-users will be trained. Also you must ensure that administrators and support have the necessary documentation to enable them to be efficient.

Buyer’s need: “How will the application support my future requirements?”

“When tricky run-time or output problems occur, can we troubleshoot?” – In simple transaction systems, this is a relatively easy task. Tomorrow’s applications will likely include some machine learning (ML) component. This is where things become tricky as you need to peer into the black-box to fix certain problems (e.g. bias). Invest time during the design phase to think through the ethics and how ML models are trained.
“How easy is it to take an software upgrade?” – This will depend on the split between what is available in the ‘vanilla’ product, what is configurable and what is custom. If you get the balance wrong, then customer’s upgrade paths will be difficult and expensive , adding to a well defined Total Cost of Ownership (TCO) calculation.
“What is your product roadmap?” – The expected lifetime of large enterprise applications is over 10 years. An educated buyer is going to want to understand the stability of your organization including funding and how many customers in the same category. Equally they are going to want ongoing visibility to and influence over your product roadmap. Customer Advisory Boards, if run well and listened to can satisfy this buyer requirement.

Managing all of those buyers considerations while defending your engineering teams to releases can be shipped on time and making sure that the product can be sold and marketed is a challenge. Hence Enterprise Software Product Management is not an easy job.

The team at First Retail includes both Product Managers and previous Buyers of Enterprise Software. Poachers turned gamekeepers if you will. Not only can we help in the software development lifecycle but we can provide guidance and experience for your RFP and software selection process.

This post was also featured on Medium as ‘Why Enterprise Software Should be Expensive‘