Closing the empathy gap is the bedrock of building awesome product experiences

Developers and companies alike have been saying they’re customer-centered for years. But customer-centricity is table stakes these days. We’re now entering a new era where product experience takes precedence over everything else.

Why? Because we need to create awesome product experiences that lock in customer loyalty. If we don’t zero in on product experience, then we’ll keep building technologies that cause frustration, churn, and customer remorse.

What’s so tough about product experience? Often, it’s about failures of empathy — misreading the perspectives of people who build the products (developers), who operate them (DevOps/IT), who use them (end users) and who support them (SREs). Inside a company, the empathy gaps between various teams and departments are even higher. That creates suboptimal experiences for the customers.

What Lisa Taught Me About Empathy

I’ve had my own empathy breakdowns. Indeed, one incident stands out in my mind more than a decade later. It wasn’t about building a new feature or optimizing a process.

It was about lunch.

It happened like this: A top executive called a bunch of us engineering managers in for a luncheon meeting. Lisa, the exec’s assistant, sent us all an email saying we needed to go pick up lunch in the cafeteria and bring it to the meeting. Just stop by and grab a $10 coupon and you’re all set.

For some reason, this had me fuming. I didn’t have time to run off and get my own lunch. I didn’t need a coupon. I needed my lunch delivered to the meeting and I was certain that it was her job to get it done.

So, I dashed off an instant email to Lisa with words to this effect.

Minutes later, I got back Lisa’s reply. She was firm: She had a long list of pressing priorities to take care of and she wasn’t about to be pushed around.

Then it hit me. I hadn’t given any thought to her perspective. All I could think of was what I wanted.

Fortunately, I had enough sense to realize I was in the wrong. She was busy too. She had dozens of things to do that day and a dozen sound explanations for her approach to planning luncheon meetings.

I offered my apologies. She accepted them gracefully.

Later, I thought of what I could’ve done differently. I could’ve been kinder and more generous. I might’ve offered a productive suggestion that took a little friction out of her workday.

That is, I could’ve shown empathy for her perspective. I could’ve made an effort to improve her life instead of adding another aggravation. Isn’t that what technology is supposed to do?

Why Empathy Gaps are So Common

In the 25 years since I became an engineer, I’ve lived in the worlds of hardware, software and cloud services. And I’ve seen this time and again: Hardware people don’t talk to software people. Software people don’t talk to hardware people. Cloud services people don’t get much attention from hardware or software people.

They all live in their own mythical bubbles. They think their problem is the hardest, theirs solution the coolest. Unfortunately, just solving the problem is not good enough anymore: It has to deliver a frictionless experience for all stakeholders and customers.

Another common empathy gap: Developers are central to building software and services. Of course we cannot build products without developers. But we must acknowledge that there’s an entire ecosystem of people who never write code.

The job descriptions number in the dozens. Product managers, architects, engineering managers, sustenance engineers, technical program managers, release managers, technical marketing engineers, product marketing managers, sales engineers, support engineers, escalation managers, customer success managers and many more — they’re all critical to product development or we wouldn’t have them on the payroll. But they’re not developers.

Now let’s say, for example, that you’re building a new service to streamline the software-development process. Of course, you’d have to spend considerable time learning how coders get their work done. But to improve the overall development process, you’d also have to understand the needs of motivations of everybody in the software development ecosystem, including the experience for the end-users.

Breaking Down the Silos that Prevent Empathy

The people you understand best typically face the same challenges you face. You talk with them, work out your strengths and weaknesses, and learn to collaborate effectively. You grow close. Everybody else is a stranger by comparison.

These common interests and motivations form the bedrock of human relationships. They’re also the building blocks of silos that separate people across a company. How do we shatter these silos? It starts with bringing people and perspectives together.

It’s not enough to hold more meetings. You have to design processes and techniques that account for all the viewpoints of the people who will build, operate, support, sell, buy and use your product.

This was one of our guiding principles in my seven-plus years at Nutanix. We took the time to figure out what our users expected from our products. And as managers, we put in the effort required to make sure the developers had what they needed to design and deliver new products.

For example, we took pride in one-click upgrades. This wasn’t only about upgrading Nutanix’s core software (AOS, AHV, Prism). It was about upgrading the entire hardware, software and services stack without requiring complex setup or silos of tools.

This was hard — really, really hard — but we delivered the experience with LCM (lifecycle management) because people across different departments (hardware, software, services, support) came together. They took time to understand the real strengths and weaknesses of each other’s solution and approach, and came out with the best joint solution to provide the finest experience for the customer.

Of course, anybody can tell people to show more empathy. Building empathy into your processes — and your entire business — is another issue altogether. We’ve all encountered those times when we spent 11 months developing a feature and then learn six months later that only a few people actually wanted it. Listening to the end user, shortening the feedback loop, and developing deep empathy in their pain points can prevent these outcomes.

I’ve learned over the years that to build empathy, you need a mechanism to communicate an individual’s perspective to the group they work in. You also need communication pathways to all the groups that have a stake in the success of your product.

Those things don’t happen by accident. They have to be designed and built — with all the empathy you can muster.

Dedication: I’m dedicating this article to Lisa, the executive assistant who provided a crucial lesson in empathy that became the bedrock for my success in product development. A simple apology and deep empathy thereafter turned her into one of my biggest supporters.

Originally published at https://www.linkedin.com.