The Customer is Almost Always Wrong...

When customers describe a solution, they are almost always wrong. When customers describe a problem, they are almost always right.

Your largest customer asks for a feature. Sales says it will close a million-dollar renewal. Engineering says it’s a two-month effort at least. Within minutes, the conversation turns to scheduling: Which release? What gets pushed out?

Nobody asks whether you should build it at all.

One of the highest-stakes versions of that conversation happened between Apple and the FBI.

A Legitimate Problem, a Contested Solution

In December 2015, two terrorists killed 14 people in San Bernardino, California. The FBI recovered an iPhone used by one of the attackers and wanted to know what was on it. Communications with other terrorists? Evidence of additional plots?

Those were legitimate questions. But the phone was locked.

Apple provided the data it had and assisted investigators. Then the FBI obtained a court order directing Apple to create special software that would disable the phone’s protections against repeated passcode guesses.

Apple refused.

Apple didn’t dispute the importance of the investigation. It disputed the proposed solution. Tim Cook argued that creating the software would set a dangerous precedent and undermine the security of Apple’s products. The FBI saw one phone in one investigation. Apple saw a capability that, once it existed, could be demanded again and again, or adapted for purposes it never intended.

Same request. Two very different perspectives. And that’s exactly the tension product managers face every day.

Customers Bring Solutions. Product Managers Find Problems.

Customers rarely arrive with problem statements. They arrive with requests. “We need a dashboard.” “Add this field.” “Can you turn off that security requirement for our account?”

I’ve long argued that when customers describe a problem, they’re usually right. When they describe a solution, they’re often wrong.

That’s not because customers are foolish. They are experts in their problems, or at least the symptoms. They know what frustrates them and what they’re trying to accomplish. They are not experts in your product. They don’t know your architecture, your strategy, or the needs of your other customers.

That’s your job. Product management isn’t simply a way to turn customer requests into engineering assignments. It’s a business discipline: understand the problem, evaluate the alternatives, and decide what’s right for the product and the market.

When Two Good Customers Disagree

Let me give you an example from my own experience.

At a customer advisory board meeting, one customer was adamant that we develop a particular feature. He had a real problem, and he made a compelling case. Then another customer spoke up. That feature, he said, would undermine our product. If we built it, he’d stop using it.

Both were good customers. Both were right about their own problems. They couldn’t both be right about the solution.

What I often see in this situation is a negotiation over which customer matters more. Who has the bigger contract? Who’s more likely to leave? That turns product management into refereeing.

The better questions are about problems. What is the first customer actually trying to accomplish? Why does the second customer see the feature as a threat? Is there an approach that solves the first problem without creating the second? And if there isn’t, which problem matters more to the market you’ve chosen to serve?

That’s the real value of a customer advisory board. Not a vote on features. Evidence about problems. And discussions—not decisions—about possible solutions.

Think About the Anti-Persona

That second customer was doing something product managers often forget to do: thinking about who else a feature affects.

We build personas to describe the people we want to serve. An anti-persona describes someone we don’t intend to serve, particularly someone who might use our product in ways that undermine its purpose or harm others. Social media platforms built to connect friends also became tools for harassment and disinformation. The capabilities didn’t distinguish between the people they were built for and the people they weren’t.

Apple asked the anti-persona question. The FBI was the immediate requester. But who else might want software that defeats iPhone security? Hackers? Cybercriminals? Anyone who got a copy?

Before you build, ask: Who else might use or misuse this capability, and what might they do with it?

There Was Another Way

In March 2016, the Justice Department announced that it had accessed the phone with help from an outside party. The government withdrew its legal action. Apple never created the software.

That doesn’t settle the broader debate about encryption, privacy, and law enforcement. But it illustrates something important. The customer’s proposed solution wasn’t the only possible solution. When we separate problems from solutions, we create room for alternatives.

Your Job Isn’t to Say Yes

Product managers face constant pressure to say yes: to customers, to sales, to executives. Saying yes feels productive. Saying no is harder.

But saying no to a proposed solution isn’t the same as saying no to the customer’s problem. A good product manager can say, “I understand what you’re trying to accomplish. I’m not convinced that’s the right way to accomplish it. Let’s explore the alternatives.”

Here’s something you can do this week. Take the top five requests in your backlog and rewrite each one as a problem: who has it, what they’re trying to accomplish, and what happens if it isn’t solved. Then ask who else the proposed solution would affect, including the people you’d rather not serve.

Customer requests are the beginning of product discovery, not the end of it.

Sometimes the most important word in product management is no.