Three Steps To Achieving A ‘Wow’ Moment In Customer-Centric Software Development

Last year, while attending a leadership summit, my colleagues and I observed that customers increasingly want their business applications to work very similarly to their personal applications. They love the interconnections between Google apps, social platforms that allow cross-posting, and the ease of use of having everything right on their phones. They want their business apps to work in the same seamless manner.

In the B2C space, there’s generally more focus on the customer and creating an exceptional user experience. But B2B companies, especially those producing vertical-specific software, often work inside-out and make assumptions about what customers need. Instead, I believe they must put customers at the center of everything they do and create solutions that cater to clients’ workflows, from the most minute details to the biggest pictures.

Keeping customers at the center of your product design isn’t a moonshot. In fact, I’ve outlined three simple steps I’ve used in my own software development work to achieve that end.

1. Conduct a contextual inquiry.

The first step to adopting a customer-centric mindset is to truly know your customer, which you can generally only accomplish by going and spending time with them as they conduct their day-to-day work to understand how your product works within their process. The goal is to understand customers at a task level — not just by their roles, titles or backgrounds. How do they actually do their work? What are the main pain points they have in those processes, and how can you help ease those without a dramatic overhaul of the established workflow? It doesn’t do any good to build a great product that isn’t solving your customers’ problems — or, worse, one that won’t get used because it requires too much change for change’s sake.

It may be tempting to ask what they want and deliver based on their responses. Sometimes, however, customers aren’t even aware of the technologies and conveniences that are possible. For instance, a customer may not realize they don’t necessarily need to switch back and forth between email and various apps. Customers in the legal space, for example, could benefit from combining their Microsoft Office applications and spend and matter management programs under one “roof.”

In my experience, the only way software developers can know how to design that type of all-in-one solution is if they see the struggles of their customers firsthand. This type of contextual inquiry is a necessary investment — it should be the foundation of your entire design. It’s not just how they’ll use the software that should be considered, either. You should take everything from awareness to work practices to customer support challenges — the end-to-end workflow of the entire customer experience — into consideration. Plot this out before you dive too far into product design. In fact, thinking of your deliverable as a product may be part of the problem. Instead, you can think of “offerings.” This term better represents a wider, more customer-centric lens.

2. Continue customer engagement during development.

When it is time to get started with development, it’s important to validate your assumptions with customers on an ongoing basis — particularly because customer expectations are rapidly changing in today’s world. I won’t forget the time in a previous role when I diligently completed the first step outlined in this article. Once I understood my customers’ pain points, I pushed my team to get the product out as fast as possible. But in doing so, I failed to continue engaging with my clients throughout the development phase. When the product was complete, a customer — probably our biggest based on revenue — told us that while we indeed delivered on what we’d discussed, things had changed drastically in the industry over the last few months. New pain points had emerged. Put simply, the product did not hit the mark.