Show, Don't Tell: Why Users Can't Describe What They Need

The short version

Steve Jobs said "people don't know what they want until you show it to them." Users are great at telling you where it hurts (the problem) but bad at prescribing the medicine (the solution). Feature requests pile up and look like a roadmap. They're not. They're symptoms. I spent a year at one company where the entire roadmap was driven by sales-funneled customer requests. We shipped 40+ features and churn didn't move. What works: dig into the "why" behind every request, prototype before you plan (AI tools make this hours not weeks), use feedback as input, not direction. Listen to everything. Build what matters.

There's a thing Steve Jobs said that gets quoted too much and understood too little: "People don't know what they want until you show it to them."

Most people hear that and think it means you should ignore your users. That's wrong. What it actually means is that users are great at telling you where it hurts, but bad at prescribing the medicine.

I've seen this play out dozens of times across Microsoft, Salesforce, Adobe, and Smartcat. Feature requests pile up. They look like a roadmap. They're not. They're symptoms.

Feature requests are reactive by definition

When a user says "I need a date filter on this dashboard," what they're really saying is "I can't find what I'm looking for." The filter might help. Or you might need to rethink how the data is surfaced in the first place.

The trap is that feature requests feel like clear direction. Someone told you exactly what they want. It's tempting to just build it. But when you do that across a whole roadmap, you end up with a product that's a patchwork of fixes rather than something coherent.

I spent a year at one company where the entire roadmap was driven by customer requests funneled through the sales team. We shipped 40+ features. Churn didn't move. The product got more complicated and nobody's core problem was actually solved.

The gap between problem and solution

Users know their problems deeply. They live with them every day. But the solution they suggest is limited to what they know is possible, which is usually "a slightly better version of what exists."

Before the iPhone, if you'd asked people what they wanted in a phone, they'd have said better battery life and a nicer keyboard on their Blackberry. Nobody was asking for a touchscreen app platform. That didn't mean they didn't need it.

In PM work this shows up constantly. Users ask for more detailed analytics reports because they can't find insights in the current ones. The fix isn't more data. It might be better visualization, smarter defaults, or surfacing key metrics automatically. You won't get to that answer by taking the request at face value.

What I do instead

I still talk to customers every week. That hasn't changed and never will. But I've changed what I do with what I hear.

I dig into the "why" behind every request. What are you trying to accomplish? Why isn't the current approach working? If you could wave a magic wand, what would be different about your day? These questions get you past the surface request and into the actual problem.

I prototype before I plan. Instead of writing a spec based on what users asked for, I build something that solves the underlying problem in a way they haven't seen yet. AI tools make this fast now. The full workflow is in Instant Prototyping. I can have a working prototype in a couple hours. Then I put it in front of customers and watch what happens.

The reaction to a real thing is completely different from the reaction to a mockup or a requirements doc. People engage with prototypes. They push buttons. They say "wait, can it also do this?" That's where the real product insights live.

I use feedback as input, not direction. Customer feedback is one signal among many. It's not the roadmap. It sits alongside usage data, market trends, competitive moves, and your own product vision. The job is to synthesize all of that into a direction, not to build a feature backlog sorted by vote count.

How this connects to AI-era PM

This approach has gotten way more powerful with AI tools. Before, building a prototype to test an idea took weeks. Now it takes hours. That changes the math completely. The Continuous Discovery chapter shows how to run this at scale with agents handling signal extraction.

Instead of: hear request > write spec > get approval > design > build > test > learn It's now: hear request > dig into the problem > prototype in two hours > test with customers > learn

The feedback loop compressed from a month to a week. Which means you can explore more ideas, kill bad ones faster, and find the right solution before you've invested serious engineering time.

I've started treating every customer conversation as a potential prototype trigger. Someone describes a problem, and by the next day I have something clickable for them to react to. The quality of the conversation changes completely when you can say "is this what you mean?" with a working thing in front of them.

The balance

None of this means ignoring users. It means respecting what they know (their problems) while owning what you should know (the solution space). The best products I've worked on happened when we deeply understood the customer's world but didn't let their feature requests drive the architecture.

Listen to everything. Build what matters. For a structured approach to turning customer signals into a testable opportunity tree, see Your First Opportunity Solution Tree.

Sources: Steve Jobs.