You have to listen to your customers.

This is well understood. If you don’t, you’re setting yourself up to fail. The heart of the product nerd’s job is to understand the problems of a target market. You have to make decisions based on data and the real experiences of users*, not just your own intuition. I don’t know where the adage actually originates but I first heard it from Pragmatic Institute: “Your opinion, although interesting, is irrelevant.”

But…the customer isn’t always right. They tend to talk in terms of what solutions they want instead of telling you what problem they’re actually trying to solve. This is the idea behind the quote, “If I had asked people what they wanted, they would have said faster horses” (even if Henry Ford almost certainly never actually said it). Sometimes they’re using your product in a way that’s unintended, unsupported, or borderline illegal. Perhaps they’ve grown accustomed to (even fond of) a bug and are perturbed that you’ve fixed it. Two different customers may have conflicting ideas for how your product should function. If you dedicate yourself to blindly carrying out every feature request, your product will be unfocused and impossible to maintain.

Does this mean you actually shouldn’t listen to your users?

No, of course not. The trouble here is with the word listen, which has two meanings:

1. hear and pay attention. (“listen to a podcast”)
2. obey. (“listen to your parents”)

This allows us to reconcile the apparent dilemma. While we absolutely should hear and pay attention to our users, we shouldn’t always simply obey them.

Your customers can’t solve their problems on their own. (If they could, they wouldn’t be your customers.) It’s the job of the product (and the product nerd, by extension) to help them solve those problems.

To help them solve those problems, we need information. The more information we have, the better our solutions will be. To be effective product nerds, we must be curious. We must be comfortable with the notion that there are things we don’t know (yet), and seek persistently to fill in those gaps, especially when it means challenging our preconceptions. We must ask questions. And we must listen to the answers.

This matters because if we’re not careful we can trick ourselves into thinking our users are our enemies. We may be trapped in a frustrating loop:

1. The customer tells us to build something.
2. We turn around and tell the engineers to build that thing.
3. Turns out, the solution isn’t a perfect one, or doesn’t actually solve the problem (shock! horror! who could have seen this coming!)
4. The customer is unhappy.
5. We are also unhappy.
6. We are less willing or able to empathize with customers in the future.

The failure here is that we’ve reduced our function as product nerds to a game of telephone (and let me tell you, some days it does feel like that’s my job). But we can break free from this cycle of frustrating both customers and ourselves, if we understand how to listen effectively.

Customers aren’t being unhelpful on purpose when they tell us exactly what button they think we should build for them. They may think they’re saving us time or effort. The “Don’t bring me problems, bring me solutions” mindset is pervasive, despite rarely being helpful. The product nerd’s job is to uncover the problem nestled inside of whatever solution the customer is describing. For example, the problem is probably not that your image hosting website is missing a ‘create account’ button, per se; it might be that users want a way to save interesting items to a list for later, or that they want to be able to comment on images. But to learn that, we often have to walk them back a step, to before they decided how the problem might best be solved.

In my experience, customers tend to respond positively to a request to walk us through their workflow. I don’t even always have to explicitly ask for their pain points; as they explain their process, they aren’t secretive about the parts of it that could be easier.

Some product nerds may happen to be members of their target market. Often, we’re not. I’m not. But even if you are, there are going to be angles, use cases, workflows, possibilities, and pain points you haven’t considered. Your customers have information you don’t have. Every customer interaction is an opportunity to acquire some of that information; it doesn’t have to be a battle. Each customer story, complaint, and request is a data point, not a backlog item. This is also why it’s important to talk to a large, representative sample of users. One plot point does not a trend line make. In order for patterns to emerge in the data, we need data—more than one. (Did you know the word “data” is plural? The singular is “datum.” You probably did know that, you’re smart.)

Those emergent trends inform our backlog items, our roadmap, or even our product strategy. But if we treat customer interactions like an arcade game where our objective is to knock out every feature request that flies across the screen, we need look no further than how that game ends to know why it’s a bad idea: you become overwhelmed, and then you explode.

I haven’t gone into specifics here about good discovery techniques, because that’s not really the point of this post. Before we can understand or engage in effective customer discovery we have to know what it means to listen for a problem rather than listening to a demand.

And here we are, right where we started: Customer discovery is the solution. And if we take it for granted, if we jump straight into it without considering what problem it exists to solve—that we need to know what our customers know—we may not be using it effectively, and we may wonder why it’s not working.

(And you may ask yourself, “Well, how did I get here?”)

*I’m using “customer” and “user” interchangeably in this post. There may be cases where these two terms represent different groups of people, but for my purposes here, let’s assume they’re the same. ^Back