There is a divide between consumer and enterprise experiences. It’s not as big as it used to be, but it’s definitely there. So what is it? Most enterprise products still don’t have the ease of use and polish of their consumer counterparts. We’ve seen more and more B2B companies investing in great experiences for their users, but these efforts often fall short of the mark.
To better understand the divide we need to understand what makes consumer and enterprise products different.
The key difference between enterprise software and their consumer-facing counterparts is present at the very start of the user’s journey – user acquisition.
With consumer software the decision whether to use it is in the customer’s hands. Usually after reading a few reviews, carrying out some research or comparing to other options, the end user decides. This isn’t the case for most enterprise software. The average employee doesn’t often have a choice over what software they use for work.
Consumer products allow for free trials or low-commitment options so users can try multiple competing services at once and take as long as they need to make their decision. The enterprise software sales and acquisition process is completely different, here a small group of people are responsible for deciding on a software for, potentially, hundreds or thousands of people.
These differences in user acquisition can lead enterprise product owners to believe that their customers are purchasing managers and not end users. That’s why in the enterprise world, individual sales have a much higher value. A successful consumer product may make tens of thousands of sales per year, while many successful enterprise products will only make dozens if not fewer.
So when an enterprise sale is made, it is understandably a big deal. With each sale having such a high value for the product, complex requirements often get added to serve a single sale. If a prospective client requires features X & Y to be added to the road map, and they will account for a third of your upcoming revenue, who is going to be brave enough to say no?
And so a cycle begins, a sale is made on the prerequisite that a feature is added. The request is made by someone in the purchasing department who is ticking a box or by someone who will ultimately not use the product. The feature is released and not used or not used as imagined, leaving the developers to maintain it. Or as we like to call it a ‘phantom feature’ that ultimately takes the team away from developing features that deliver real value and solve genuine user needs.
We know that it’s not always straightforward to measure the success of enterprise software. A lot of the common metrics we see used to gauge impact for consumer software don’t really apply. Monthly active users for example doesn’t translate well to products who’s users have little choice in what software they use.
Sales or revenue targets can be appropriate goals, but won’t give any indication about user satisfaction or task success. Other metrics that can be easily mined from traditional software analytics will suffer from the same issues. Qualitative testing can be extremely useful but often isn’t given enough emphasis by enterprise software teams.
So without assigning the correct metrics, progress is often measured in features released or sales made, neither of which will tell us about perceived ease of use, whether we’re actually meeting user needs, or the impact it will have on the businesses.
The phrase “less is more” gets discussed a lot when talking about design. We prefer “less but better” from seminal product designer Dieter Rams. It’s a design principle we can use to describe the best consumer products. But we can’t say the same thing for enterprise apps and that is why enterprise apps feel different. In the worst case enterprise apps embody “more but worse”.
New features, settings and options are added because “the powers that be” need them for a single use case. Product owners need to show they’re making progress, so they add more to the product. More features, more settings, more use cases, more customisation, just more of everything.
This kills the experience for two reasons.
Firstly, complexity. A product with fewer features is going to be easier to use. There’s less for your users to learn, less to understand, and less to remember. When a person opens an app for the first time and they have two options, their next step is obvious. If they log in to a product and are presented with nine places to look at things, it gets a little muddier.
To make matters worse, complexity scales exponentially. Each feature added has to work with every existing feature. Every setting has to take all the existing controls into account. Add a new feature with two settings, now you have to deal with how both those settings work with everything else in your app. Simple additions can double the possible states you, and your users have to work with.
The second killer is quality. It’s nearly impossible to describe what makes a feature “good” or “bad”. But what we can say for certain is that if you build more features you’ll be able to spend less time on each of them. Spending more time working on a feature means more time for research, more time for iteration, more time to get it right. More time for quality.
Now we understand how user acquisition can impact the experience of our enterprise projects, how do we move to a more user centric point of view?
Firstly we should budget more time for primary research. By talking to our customers we can avoid the pitfalls of building features specifically for sales or managers. But just doing the research and acting on it isn’t enough to solve our organisational issues. To do that product leaders need to be diligent in recording and presenting research in a way that resonates with other leaders in their businesses. Shifting the focus of conversation from a solely sales to one that prioritises customer needs.
Defining metrics that focus on user success rather than measuring sales or features added is a great place to start. Remember, monthly active users won’t be a helpful metric if all your users have no choice about using the product so try switching to measuring net promoter score, task success, or feature usage to gather more valuable insights.
Even with mountains of research and the best metrics in the world sometimes you’ll still need to build a feature that doesn’t quite fit. Every product owner will have feature requests they simply can’t ignore. When this happens it’s best to consider how to minimise any negative side effects of adding to the product. A great strategy is to only enable certain features for a subset of your users. This way the bulk of your users are protected from any extra complexity.
If you’re in the business of building enterprise software, understanding what effects user acquisition will help you make better decisions and build better products. Knowing why features get added will help you defend against software bloat. Appreciating the power of research, and targeted measurement will let you build for users, not just sales.
We’re always excited to work on projects focusing on great experiences, not just box checking features. If you’re developing an enterprise product and you want to supercharge your product strategy, user experience, and design get in touch.