Why Users Don't Know What They Want Until You Show Them

Originally published on Medium.

The short version

Feature requests are reactive. Users know their problems but not the solution space, so they describe today's problem with today's mental model. As Steve Jobs put it: "people don't know what they want until you show them." The shift from feature-request-driven to visionary product development starts with better questions: "What are you trying to accomplish?" not "What feature do you want?" Treat user feedback as input, not direction. The power tool here is prototyping: a working prototype turns abstract vision into something tangible, and users react to what they see, not what they imagined. At SOCi, showing customers Applied AI and Genius Studio produced visceral reactions ("This changes how we think about our workflow") that incremental feedback never would have surfaced.

The Limitation of Feature Requests

Feature requests are inherently reactive. Users come to you with a specific request based on their current workflow, current tooling, and current understanding of what's possible. But they're solving today's problem with today's mental model.

This is where the danger of pure feature-request-driven development lies: incrementalism. You get better at incremental improvements, but you miss the opportunity to leapfrog the entire category. You're so focused on making the current solution 10% better that you miss the chance to make it 10x better.

Steve Jobs understood this better than anyone: "It's really hard to design products by focus groups. A lot of times, people don't know what they want until you show them."

The Gap Between Problem and Solution

Here's the critical insight: users know their problems. They're living with them every day. But they don't know the solution space.

A user might say, "We need a better way to manage our social calendar." What they really mean is, "Current calendar tools are clunky, disconnected, and require manual coordination across multiple platforms."

They've identified the problem. But the solution? They'll describe what they have in front of them, with minor tweaks. They won't imagine the possibility of AI-powered scheduling, predictive conflict detection, or autonomous calendar agents.

Moving Beyond Feature Requests

The shift from feature-request-driven to visionary product development starts with asking better questions:

Instead of: "What feature do you want?" Ask: "What are you trying to accomplish?"

Instead of: "Is this solution good enough?" Ask: "Why does your current solution fail?"

Instead of: "Should we build this?" Ask: "Is there a fundamentally better way to solve this?"

These questions force you into the solution space. They make you curious about the constraints users face, the workarounds they've built, and the future they wish for.

Balancing Vision with User Feedback

This doesn't mean ignoring users. It means treating user feedback as input, not direction.

User feedback shows you the size of the opportunity. If 100 customers are all experiencing the same problem, the problem is real. But how you solve it should be informed by vision, not prescribed by it.

Test your bold ideas. Iterate with users. But don't let their mental models constrain your thinking.

The Power of Showing, Not Telling

This is why prototyping matters so much. A prototype turns an abstract vision into something tangible. The mechanics of building fast are in Instant Prototyping. Suddenly, users can react not to what they imagined, but to what they're seeing.

At SOCi, this principle informed our entire approach. When we built Applied AI and Genius Studio, we weren't asking customers, "How should AI help you manage social media?" We showed them what intelligent, autonomous AI agents could do. Then we iterated based on what they experienced.

The reception was fundamentally different. Instead of incremental feedback, we got visceral reactions. "This changes how we think about our workflow." "We didn't know this was possible."

Connecting to Cagan's Product Operating Model

This aligns with Marty Cagan's thinking and with the Product Operating Model framework, which emphasizes:

• Cross-functional collaboration: Product managers, designers, engineers, and researchers working together to understand problems and imagine solutions
• Focus on outcomes, not outputs: Are we actually solving the problem? Or are we just shipping features?
• Continuous innovation: A cadence of discovery, prototyping, testing, and learning

When your team operates this way, feature requests become data points in a larger discovery process. They inform, but don't dictate.

The Courage to Lead

Visionary product development requires courage. You'll sometimes be wrong. You'll invest in directions users didn't ask for. The assumption testing playbook is how you keep that risk bounded: identify the riskiest assumptions, build a prototype that tests them, and let customer behavior tell you whether the vision is right.

But you'll also experience the magic of showing users something they didn't know they wanted - and seeing them immediately grasp its value.

That's when you know you're building something special.

Sources: Marty Cagan, SVPG, Steve Jobs.