Why 'Asking the Customer What They Want' Keeps Producing Products That Fail

You’re about to design a product for someone who will never touch it.

Not on purpose. It happens the way most expensive mistakes happen: reasonably, one sensible step at a time. Your customer asks you to improve the product. You ask them what they’d like changed. They give you a list. You build the list. Everyone is being professional. And somewhere in that professional, reasonable process, the one person who will actually use the thing every day never gets asked a single question.

That person is the empty chair. And whether it’s a frozen-drink machine behind a fast-food counter or a two-million-dollar line on a plant floor, the rule is the same: win over the person who runs it, and they’ll sell it for you.

How the chair goes empty

Here’s the pattern, and you’ve probably lived it.

A buyer asks for changes. The changes become features. The features get built. And because “add a feature the customer named” feels like progress, nobody stops to ask whether the feature creates any value for the human who has to live with it.

Call it feature theater. Not fakery, nothing so cynical. Feature theater is sincere. It’s expensive. It’s a screen bolted onto a machine because someone in a conference room asked for a screen, engineered and tooled and shipped, without one person who uses it every day confirming that they needed the screen or if raising the hopper to accommodate the screen would be an issue. It presents the appearance of value. It just never checks whether the value is real.

Why smart companies do this on purpose

It would be easy to call this laziness. It isn’t, and pretending it is will lose you the reader who’s done it. This is a rational trap, and it has at least four walls.

Fear. Asking your customers’ users what they need can feel like admitting you don’t already know. And if you don’t know, why are they paying you? So you guess, confidently, because confidence looks like competence.

Lane. You may not even be a hardware company. You sell frozen drinks, or chemicals, or a service, and the hardware is incidental to all of it. User-testing a machine feels outside your expertise, so it quietly falls off the list.

Instruction. Sometimes the customer tells you to guess. “Just take your best shot; we’ll ask them if they liked it after.” Now caution feels like defying the client.

Ownership. And underneath all of it: nobody inside the building actually owns “go talk to the person who presses the button.” So it defaults to no one.

These are smart people inside a bad structure. That’s exactly why it keeps happening and why willpower won’t fix it.

Even the pilot lies to you

Here’s the trap inside the trap. Say you do run a pilot. You put the machine in front of real users. You ask how it went. You’re doing everything right.

You still get a lie.

An owner walks up to a frontline worker after the pilot and asks, “This saves us time and money. Did it work for you?” And the worker, who is twenty-two and being addressed by the person who signs the schedule, says, “Yeah, it worked.” And then goes quiet. What they do not say is that it’s miserable to load, that the hopper is too high, that they’ve started dreading their shift because of it.

The power imbalance guarantees the comfortable answer. The questions feel like diligence but function like leading the witness. And the one honest signal that does slip out, “the hopper’s too high,” gets waved off as a one-off because it doesn’t fit what you were hoping to hear.

So the companies that don’t ask are flying blind. And a lot of the companies that do ask are asking in a way engineered to produce a lie.

The flip: the user is the shortest path to the sale

Now the part that turns all of this from a soft “be nice to users” argument into a hard commercial one.

The user is not a nice-to-have. The user is your fastest route to the buyer’s signature.

Because when the person who runs the machine actually loves it, they don’t stay quiet. They walk up to their manager and say, “You have to buy this. It’s so fast. It does everything.” Those exact sentences are what managers actually buy. Not your spec sheet. Not your feature list. The unprompted endorsement of the person who has to live with it.

Talk to the user, and you’re not taking a detour away from the sale. You’re taking the most direct road to it that exists.

What that looks like, all the way up

Please the user, and it stacks. The user champions the product. The manager, hearing it unprompted from their own team, buys with conviction instead of hope. The buyer looks good for having chosen it. And downstream, their customers get served by people who don’t hate their tools.

The alternative stacks too, in the other direction. Users resent the product, so they use it grudgingly. Turnover climbs. The floor is grumpy. The experience your buyer is trying to sell degrades, and the machine that was supposed to help gets quietly blamed for it. Look at the gap between the companies famous for how their people show up and the ones famous for the opposite. That gap doesn’t come from the equipment. It comes from whether the equipment was built for the person using it.

How we make sure the chair is never empty: failure is a requirement

This is the entire philosophy behind how we develop products at Product Insight, and it’s the opposite of how most of it gets built.

Most development spends real money to discover failure late: at the pilot, in front of the customer, when it’s most expensive and most embarrassing to fix. We do the reverse. We treat failure as a requirement, and we force it early, on purpose, while it’s still cheap.

The front half of our process exists to try to kill the concept before you’ve spent a dollar engineering it. Fast iteration. Cheap tests. Real data on whether the core idea even holds. And one of those early gates, one you cannot skip, is a single provable question: did we actually understand the user’s needs? Not the buyer’s wish list. The user’s needs. We prove that before anyone builds a complete product, because if you’re wrong about the user, everything you build on top of that is expensive scaffolding around a mistake.

Concretely, that can be as simple as putting mock-ups in front of the actual operators before you engineer a single system. Show the twenty-two-year-old the screen. Watch them reach for the hopper. Find out in an afternoon, what the drink-machine company was about to find out the hard way.

That’s the difference between failure that costs you a Tuesday and failure that costs you the account.

The empty chair is the most expensive seat in product development. We make sure someone’s in it before you build, not after.

If you’ve got a bet coming that you can’t afford to guess on, that’s the conversation to have with us. Make the right bet, before you build.