Imagine a customer who tells you, with total conviction, that they need a custom field type your product does not have. They describe it in detail. They tell you how many seats depend on it. You are a small team and a big request is on the table, so you very nearly build exactly what they specified. Then someone asks the question that should shape how you do product from then on: what are you trying to do with that field. The answer has nothing to do with custom field types. They are trying to roll up status across forty projects for a Monday leadership review, and the field is just the workaround they invented to fake it. You do not build the field. You build a portfolio view, and it serves not just them but everyone who had the same underlying problem and never thought to ask. That is the shape of the decision I try to make in Atlas over and over.
This is the whole discipline of customer feedback in one story. Customers are extraordinary at describing their problems and unreliable at proposing solutions, and the two arrive welded together in almost every feature request. The advice to listen to your customers is correct, and it is dangerously incomplete, because it does not tell you which part to listen to. Listen to the solution and you become an order-taker building a Frankenstein product. Listen for the problem underneath and you can build something that actually solves it, often better than the thing they asked for.
Customers own the problem, you own the solution
The division of labor here is clear once you name it. The customer is the world's leading expert on their own pain. They know what is slow, what is confusing, what costs them hours, what makes them want to throw their laptop. You should treat that knowledge as close to sacred. What they are not an expert in is your product's architecture, the tradeoffs between options they cannot see, or what is technically cheap versus ruinously expensive to build. So when a customer hands you a solution, they are doing your job with a fraction of your information, and politely. The request is real signal. The specific feature is just their best guess at a fix.
Henry Ford is supposed to have said that if he had asked people what they wanted they would have said faster horses. Whether or not he said it, the lesson holds, but most people draw the wrong conclusion from it. The lesson is not that you should ignore customers because they only ask for horses. It is that "I need to get places faster" was completely valid, and the horse was just the only vehicle they knew. Your job in product strategy is to hear "faster" and to know about the car. Dismiss the request and you miss the need. Build the literal horse and you miss the opportunity. The skill lives in the gap between those two failures.
Ask why until you hit the real problem
The practical move is almost embarrassingly simple, and almost nobody does it consistently under the pressure of a customer call. When you get a feature request, do not write it down and move on. Ask what they are trying to accomplish, and then ask again about the answer, and keep going until you reach a problem rather than a solution. The custom field was a solution. Rolling up status was closer. "I look unprepared in front of my leadership every Monday" was the actual problem, and it is one you can build for with confidence because you understand the stakes.
This is the core of useful user research. You are not collecting votes on features, you are excavating the job the customer is trying to get done. A few habits make it work:
- Ask about the last time, not the general case. "Walk me through what happened the last time you tried this" surfaces real behavior. "Would you use a feature that does X" surfaces polite fiction.
- Count how often a problem appears, not how loudly it is stated. One emphatic request is one data point, even from a big account.
- Separate what they say from what they do. Usage data is a customer telling you the truth without realizing it.
Aggregate the pain, do not chase the loudest voice
The danger in listening is being led, and you get led most easily by volume. The largest customer, the angriest email, the request that happens to come from someone with your CEO's ear. Any of these can drag a roadmap toward solving one account's problem at the expense of the many. The defense is to treat feedback as evidence to be aggregated rather than instructions to be executed. A single vivid complaint is not more important than fifty quiet ones describing the same underlying issue, but it feels more important, and product development goes sideways when feeling beats counting.
We hold a deliberate bias toward building for the problem that shows up across many customers in different disguises, because that is where the real product opportunity hides. Ten customers asking for ten different features that all trace back to the same root problem are, together, telling you something none of them said individually. Hearing that requires you to listen past the specific words to the pattern, and it is the difference between a product strategy and a backlog of one-off requests that never adds up to a coherent whole.
Validate the solution without outsourcing it
Owning the solution does not mean designing in a vacuum. Once we have a hypothesis about the real problem and a way to solve it, we go straight back to customers, but we change the question. We stop asking what they want and start showing them what we are considering, then watch whether it actually relieves the pain. That is the part you can and should validate with them, because they are once again the experts on their own experience. The mistake is asking them to invent the solution. The right move is to invent it yourself and let them tell you the truth about whether it works.
This is how I try to build across both Atlas and Portfolio, and it is why a roadmap should rarely read like a straight transcription of feature requests. Take customer feedback more seriously than almost anything, and precisely because you take it seriously, refuse to stop at the surface of it. Listen hard enough to truly understand the problem. Then have the confidence, and it does take confidence, to solve it your way. Build exactly what every customer asks for and you will ship a product no one quite loves. Solve the problems beneath what they ask for and you will build something they could not have described, which is the only kind of product worth building.