Why Spend Management Requires a ‘User-Centric’ Approach

Rob Bernshteyn
Rob Bernshteyn
CEO & Chairman, Coupa Software

Rob Bernshteyn previously served as part of the executive management team at SuccessFactors (now part of SAP), running product marketing & management for this leader in HCM SaaS software. He also worked in product management at Siebel Systems, management consulting at McKinsey, and SAP systems integration consulting at Accenture. Bernshteyn holds an MBA from Harvard Business School and a Bachelor of Science Degree in Information Systems from the University of New York at Albany.

Read time: 22 mins
U for User-Centric

coupa u only lgWhat does the “U” in C-O-U-P-A stand for? User Centricity. This is something I first started thinking about during my college days.

The Campus ATM

I was born in Russia, and came to the United States when I was seven years old. Going into the second grade, I couldn't speak a word of English. I worked very hard to learn the language, so I could get along and be successful.

When was in college at SUNY Albany, every weekend for four years, I would take out $60 for spending money at the same ATM at the University Center. It took too long, and it always frustrated me. I would stand front of it, put my card in and then it would ask me, "do you want Spanish or English?"

Every time, I'd lift my finger and press “English” to continue and get my money. Over 36 months of school, that’s roughly 144 times I pressed the “English” button. If you figure it took 10 seconds every time for that question to come up, for me to input my answer, and for the system to process my answer and take me to the next screen, I spent 24 minutes of my life on just this one technology interaction.

It made no sense. First, how much English did I really need to know to use an ATM? It can’t be that hard to figure out how to use an ATM in another language. But the bigger issue is that the ATM asked me, and every other user, the same question over and over. It was not user-centric. It was stupid.

How stupid? Let’s say you and your friend speak both English and Italian. Before you start to converse, do you ask, "Should I speak in English or Italian today?" That would be a ridiculous interaction. You establish your preferences early, and then stick with them, at least as a default. Why couldn’t my campus ATM do that? How many times did it need to see my debit card to know my preferred language? I was just here last week. In fact, I’m here every week. Remember me?

That experience really opened my eyes to how much technology demanded of us, and often still demands of us. It's the exact opposite of user-centricity—it’s technology-centricity.

Would You Like a Printer With That?

I was in business school the first time I saw something approaching user-centricity. I was shopping on Amazon for a laptop, and I got one of those messages telling me that people who bought that laptop also bought a certain printer. Amazon was also trying the same kind of thing with books and movies.

It wasn’t really a recommendation engine like the ones we see today. It was more rudimentary, more of a pattern presenter. To make it really user-centric, Amazon would have to know more about the actual reasons why I wanted to buy that specific laptop, and it would need many more data points, along with some ability to handle variability, in order to offer me a better targeted suggestion.

But the idea existed, and that alone was very interesting to me. It exposed me to the power of technology solutions to leverage user information to increase the value they added to those same users. A basic idea in theory, but revolutionary in practice.

Worlds Apart

While this was happening in consumer technology, we were far away from achieving anything remotely like this in enterprise technology. Just a few years prior to this, I had been working with products from SAP, one of the great legacy enterprise software companies. The only way to enter an SAP R/2 mainframe system was with a transaction code. There was no user interface beyond a box to type in a four character code. 

Was this lack of interface for security, I wondered? I did a little test to find out. I knew that transaction code TM31 would take you to a table where you could access a list of all transaction codes and which ones specific people were authorized to use. For every transaction code, you could turn access on and off for individual users. 

For fun, I wrote a piece of code that ran across those tables and turned off access for all users to all transactions. I ran it via a batch job behind the scenes in our development, test, and production environments at a client. Within five minutes, I saw everyone stand up and come out of their offices, because the system had suddenly gone down. Thankfully, I had also written a script to restore it, which I deployed very quickly. So, now I knew that it wasn’t secure at all. It was just a very technology-centric system where no one had fully considered the user in any meaningful way. It was a big contrast from what Amazon was trying to do.

Consumer Infiltrates Enterprise

At the turn of the century, I had the chance to contribute to more consumer-oriented ways of thinking while I worked at Siebel Systems, and then at SuccessFactors. There was more thought given to the interface, but we were still up against a technology-centric way of building software. The common thinking at the time was that software vendors should pack as much functionality into the system as possible. User centricity took a back seat. Yes, there was an interface and some sort of organizing scheme, but for most users, it was still like sending them into Costco for a loaf of bread and some eggs. Many of them ended up lost and frustrated.

Not surprisingly, user adoption of enterprise software continued to be notoriously bad. In the CRM space, if your company had Siebel, but your salespeople didn’t use it, they could still close a sale. In the HRM space, if your company owned SuccessFactors, but your managers completed their performance reviews outside the system, the performance reviews still got done.

Yes, this arguably rogue behavior would be much less efficient, and more costly, and it would wreck your chances of accessing high fidelity data, but in CRM and HRM it is not so easy to quantify the business impact of technology adoption anyhow. So, while there was an acknowledgement that usability mattered, no one had drawn a direct line from user adoption to business value.

As I began to consider where I would like to go after SuccessFactors, I asked myself—where could a user-centric approach have the most business impact?

In eProcurement, if you don’t have a very high percentage of user adoption, you lose money. In the most simple terms, if you buy a pen through the spend management system for the pre-negotiated, discounted price of $0.80, versus going to the store and buying it for $1.00, your company saves $0.20. If you decide to go buy it for $1.00, your company loses $0.20. It seemed that there's virtually no other place in the enterprise where the business value equation is that crystal clear. Spend management is where user adoption matters the most, and where usability delivers the most value, because it's directly tied to a company’s bottom line.

The other thing about technology adoption in spend management is that it generates a tremendous amount of data about who is spending the company’s money and how. If you manage all your spending on Excel sheets—and many companies do--you could never get a complete, structured data set, which means that you could never generate meaningful reports, insights, or recommendations on how to operate more efficiently in the future.

I thought it would be interesting to apply usability principles with a view toward generating a tremendous amount of data on how companies spend money. That’s part of what got me going on Coupa.

A Dozen Personas

When I took the helm in 2009, we started by thinking first about the different people that would use the system, and we created personas for all of them. How would a casual user that needs to reorder business cards use the system? How about an AP clerk that needs to enter invoices? How would a controller use it differently? How would a category manager approve something? There were probably a dozen distinct personas in that first iteration of the procurement system, and we designed the application with their needs in mind first.

The person ordering the business cards might not need any functionality around approvals or invoicing. So, we optimize their experience, by only showing them the functionality that their persona needs at that time, so they’re not exposed to the added functions that other personas care about.

This is what is happening in so many areas of technology today. As an example, Facebook, based on the information you include in your profile, and thousands of data points about what you watch, read, and share, will show you things they think you’ll be interested in. They’ve distilled it down, and they are continually improving their algorithms.

That’s true user-centricity. It's a 180-degree shift from technology-centricity. The technology still has all the features and functions, but there are different experiences oriented toward different people at different times. It's about hiding the complexity, and presenting only that which matters to each person at just the right time.

People in procurement departments realized the value of this approach when they started seeing it, and that is how we won some of our earliest customers. Incumbent enterprise software players then tried to copy our user-centric approach with newer user interface overlays, but when compared side-by-side, across a broad set of important use cases, prospective customers quickly discovered that user interface overlays are only skin-deep, and that a full-stack user-centric approach cannot be easily replicated. The incumbents would need to rebuild their technology platforms from scratch in order to deliver the same experience and ultimate value.

Operationalizing User-Centricity

At Coupa, we've developed a core competency in developing user-centric applications, which we’ve now applied to a whole bunch of functional areas, like expense management, invoice processing, sourcing, inventory management, and supplier information management. Our product managers and engineers take great pride in the work they do here, and they continue to strive for excellence in this area with every release.

Part of this competency is continuous iteration through customer collaboration and data analysis. We develop in collaboration with key customers to get the product to market, and then we see where people are using it a little bit differently than we envisioned. Every time we do a new release, we make sure to solve user issues that came up in the interim.

This is where native, single-code-line cloud companies have a competitive advantage. With all our customers using the same platform in the cloud at the same time, every product manager can see how their product is being used. We can see how people navigate our system, where they get stuck, and how long they spend on each screen. We have stats—four seconds on this screen, six seconds on that screen—averaged across millions of users around the world, which means we can hone in on where we can improve user-centricity, shaving off seconds here and there.

The simplest example: the “Approve” and “Reject” buttons. Making “Approve” green and “Reject” red saves five or ten seconds for every person, because they're mentally conditioned that red means stop. They don’t even have to read the words, just locate the red button. It accelerates their decision-making.

The Best UI is No UI

Is our platform as user-centric as it could be, in all areas? No. We can always do better.

Our vision is that the best UI is no UI, and that is what we are driving towards. In other words, we want to eliminate the need for user interaction as much as possible, so that people are only asked to interact with the technology when they can add some value. Whatever the system can do on their behalf, it should do without asking. And, users shouldn’t even have to lift a finger if they don’t want to—they can tell the machine what to do with their voice. This is where technology is heading.

Nowadays, most ATM networks know your preferred language, without asking. They even know your preferred transaction, and they offer it up right off the bat: “Hello Rob. Would you like to withdraw $60?” You don’t have to pick checking or savings, because they know your default habits. If you always withdraw from checking but don’t have the funds this time, it would tell you that and ask if you would like to withdraw from savings instead. It gets more user-centric with each passing day. In the future, maybe there is no ATM, and we access our money in a way that is even easier.

I’m not trying to pick on the ATM, which just turned 50 earlier this year. It was a revolutionary piece of technology when it first arrived—more convenient than having to go to a bank and transact with a bank teller during bankers’ hours. But the technology itself was never designed in a fully user-centric way.

I joke about spending 24 minutes of my life answering the English question for my campus ATM, and I’m also dead serious. Technology now permeates every aspect of our lives. We interact with all day, every day, but a lot of our interaction does not add any value. A lot of our time is wasted unnecessarily.

It doesn’t take much to see the massive opportunity in making technology more user-centric, and  spend management is arguably the area where we can best quantify the impact of user centricity. The more users adopt your spend management system, the more money you save and the more data you collect to figure out more ways to save money in the future. That’s why our vision is to continue building upon our user-centric approach, and to push the boundaries of what is possible in this critical area.