Building for Your Customers

“Be more customer-focused.”

It’s the mandate of every product development team. We have customer advisory boards, customer relationship managers, customer support, and “voice of the customer” panels in our scrum-of-scrums. But do we really know who the customer is, or how we can best serve them? After two decades of building software products, I’m afraid that the majority of the time the answer is “No.”

Whether you’re building enterprise software or a mass-market consumer product, you need to understand your customer before you can build the best product for them, and to do that, you need to ask yourself a few questions:
  1. Do we know who our customer is?
  2. Do we really know what they need?
  3. Are we meeting those needs in the best possible way?

Who is our customer, really?

When you make commercial software, it’s easy to forget who will be using it, to confuse your user and your buyer. This is especially easy in enterprise software, where a few large customers often gain a disproportionately loud voice in new feature requests and ask for what they think their users need rather than allowing you to talk to the users directly. I’ve seen many products that showed beautifully during the sales demos but were reviled by the people who were forced to use them. Those companies lost track of who their customer was.

To determine whether you’ve found your customer, ask yourself these questions:
  • When was the last time that we talked to an actual user of our product?
  • How many different kinds of users do we have?
  • Who is our primary user?
  • Can we tie the users’ needs back to the perceived value of our product?
I like to memorialize these user types in personas, which provide a kind of shorthand and ensure that the entire development team has a consistent view of their customer. Determining which users/personas are primary and which are secondary can also help focus a team’s efforts on specific needs.

What do they really need?

Customers are famous for making very specific requests and then being unsatisfied with the results. “You gave me what I asked for, but not what I wanted,” they say, and then request another enhancement.

On my product teams, we talk about “finding the unspoken need” that lies behind these requests. The effective product team understands that their customers can’t possibly know all of the capabilities of the technology, so they shouldn’t be expected to design their own solutions. The team needs to understand what the customer is trying to accomplish and then leverage technology to help them do it in the easiest possible way.

The best way to find this unspoken need is to ask probing questions, focusing on why users want to do something rather than what they want to do. Understand the context of the activity, how it fits into their day, and what they want to get out of it, and then you’ll know how to help them accomplish their objectives.

What’s the best way to meet that need?

The best solutions are often the simplest. Now that you know who your customer is and what they really need, ask yourself: what’s the simplest way to meet this need? How can you help your customer achieve their outcome with the fewest clicks, the least amount of input, and the smallest time commitment? 

As product designers, we have a tendency to overcomplicate our solutions by trying to account for all possible permutations of the solution. Fight that urge. Instead of designing for the exceptions, design for the majority case and handle exceptions gracefully. This way, you’ll be making most of your users happy most of the time, while ensuring that your product doesn’t break when a user wanders into the fringe. The result is a clean, easy to use product that helps users do what they need to do with the least amount of fuss.

Trust me, your customers will thank you.


Top Posts

Do You Really Want to Be CTO?

My Year of Giving Dangerously