From knowing the customer to knowing the user

The world of enterprise software is moving to the cloud. There is no resisting this trend. This is true across industries including some typical late adopters like healthcare or banking. This move is often driven by the increasing risks of hosting your own infrastructure, the need to serve a more decentralized workforce, and the added complexity of supporting mobile devices.

I’ve had the opportunity to help many companies with this transition from a product model to a service model. Often, the most difficult part of the transition is to get the whole organization to start thinking of the user as the customer.

But we know the customer #

When I have encountered mature enterprise software organizations making the transition, I was always dealing with organizations that excelled at managing their customers. They spent years learning about the customer, what makes them tick, what convinces them to buy: Market research, competitive analysis, features, demos. The entire sales process is optimized to show that off and drive the buying decision.

When making the transition to a service organization, that knowledge is still useful but it is heavily weighed towards the front end of the relationship with the customer. Moving to a service organization requires the contact with the customer to be ongoing, long after the purchasing decision has been made.

In a service, UX and CX are inseparable #

Once you move to a service organization, the licensing model often forces the organization to keep convincing the purchaser to renew, month after month, for every single seat they purchase. Once you convince the purchaser to jump in, the ongoing point of contact lies with the user, that is, every individual user of the product within the customer’s organization. On the cloud, usage is metered, engaged users prove that the service is being used. Disengaged users put that purchase decision in question constantly.

What used to work before with the enterprise customer doesn’t scale to cater to individual users. Even if you push-out educational content through customer portals. Launch community initiatives for users to help each-other. In the end, individual users of the solution will engage more if the solution offers real value that they can successfully leverage every time they use it.

To do this, the approach has to switch from inside-out to outside-in.

This transition within the organization is harder than the technical transition from on-premise software to cloud software. It involves changing the way that we think of product features and prioritize our developement work.

Product team, meet your users #

One first step in the transition is to get good, firsthand feedback from the users. In most enterprise product environment, we have a good connection to the customer and the channel partners. But we often don’t have an established connection to the end-user. Here are some good places to start getting direct user feedback:

• Start with the support organization, use volume and frequency of complaints to push for improvements that will impact the largest number of users
• Look at the hacks and workarounds implemented by consultants using the APIs. See if the solution applies to a broader user population and if there is a way to bring some of those solutions into the product.
• Instrument the product and measure actual usage of features to help with prioritizing and to help to detect areas of the product that are misused or mis-understood

Use these improvements to rebalance the development effort of the team from an approach where you continuously add new content to the product to an approach where you remove user barriers to engagement. Where you create more end-user value with each improvement.

Now, really get to know your users #

Even when a company is lucky to have a direct connection with the end-user community, getting information about their needs and the blockers to their engagement is a tricky proposition. It is not enough to ask them what they want.

“If I had asked people what they wanted, they would have said faster horses.”

When end-users are asked to give feedback about their experience. They often express their needs in a very shallow way that is usually framed in the form of a solution. Something like: “Add a button here to print”.

Direct user feedback is useful but being directly responsive to is is a trap. As this quote (often mis-attributed to Henry Ford) implies, if I keep defining my product using user feedback, all I’ll get is a faster horse version of my product.

Getting to know the user is not about asking them what they want or what doesn’t work. It is about getting out of the office and meeting them where they use the product or service. To do this, we can leverage the tools of user research.

User research spans a wide variety of techniques from the simple to the complex, from the quantitative to the qualitative. In the end, the goal of user research is to make sure that you understand your users, their needs, goals, constraints, and what they aspire to become. This can be achieved by a combination of asking questions directly and by observing their behaviors and their environment.

This helps us craft a complete picture of who you we are designing the product for and it helps guide all our decisions. It helps us discover how the product is used today, where the limits currently are, and what we can do to break down those limits to help our users achieve their goals. Ultimately, what we want is our product to be a part of this journey towards success for our end-user.

If you want to learn more about simple, cost-effective techniques for user research; I recommend you start with this book called Just Enough Research. It illustrates how good research doesn’t have to be expensive and complex. It offers a good examples of what the techniques are and what problem they are best at solving.

This post originally appeared on Medium.