They Built It and Nobody Came: Why Listening Beats Assuming Every Single Time

I was talking to a VP of Product last month. Smart person, great pedigree, worked at all the right companies. They’d just launched a feature their team had been building for nine months. Months of engineering time, design iterations, stakeholder meetings, the whole deal.

Three weeks after launch, adoption was basically zero.

“I don’t understand,” they told me. “We built exactly what we thought users needed.”

And there it was. That word. Thought.

“Did you talk to any users before you started building?” I asked.

Long pause. The uncomfortable kind.

“We looked at usage data. We had hypotheses. The leadership team agreed it was the right direction.”

“But did you actually talk to users?”

“We were going to do that after we launched to get feedback.”

I’ve had this conversation so many times it’s almost a script at this point. Different companies, different products, same fundamental mistake. They built something in a conference room, shipped it into the world, and then wondered why nobody wanted it.

Because they assumed instead of listening. They fell in love with their own ideas instead of falling in love with solving real problems for real people.

The Disease of Assumption

Here’s what I keep watching happen across the tech world, and it’s driving me crazy because it’s so preventable.

Smart people sit in rooms and talk to each other about what users want. They look at dashboards and analytics. They run A/B tests on existing features. They have product reviews where they debate and discuss and decide. And they convince themselves they understand the problem.

Then they spend months building. Refining. Perfecting their solution to what they think the problem is. They get attached to their idea. They start believing in it. They build momentum internally around this thing they’re creating.

And then they launch it and the market shrugs. Or worse, the market actively rejects it. And they’re baffled because from inside their bubble, it made so much sense.

I’ve watched companies burn millions of dollars and years of time building products nobody wanted because they never bothered to ask if anyone actually wanted them. They assumed they knew. They designed in a vacuum. They fell in love with their own brilliance instead of staying curious about actual human needs.

The hospitality industry figured this out decades ago. You can’t run a great restaurant by sitting in the kitchen deciding what you think people should want to eat. You watch them. You talk to them. You notice what they order, what they send back, what makes them smile, what brings them back. You design the experience around what they actually need and want, not what you think they should need and want.

But somehow in tech, we convinced ourselves we’re smarter than that. We can intuit what people need from our desks. We can derive the right solution from data and frameworks and best practices. We don’t need to actually talk to the humans we’re building for.

That’s not confidence. That’s arrogance. And the market has a way of humbling arrogance every single time.

What Voice of Customer Actually Means

Let me get clear about what I’m talking about here, because Voice of Customer isn’t just some corporate buzzword or nice-to-have research activity.

Voice of Customer means you actually go talk to the people you’re building for. Not after you’ve built the thing to validate your assumptions. Before you write a single line of code. Before you create the design mocks. Before you commit resources to a direction.

You sit with them. You watch them work. You understand their context, their constraints, their actual problems. You listen to how they describe their pain points in their own words, not the language you impose on them.

You ask open-ended questions and then shut up and listen. You notice what they struggle with. You pay attention to workarounds they’ve created. You get curious about why they do things the way they do them instead of judging it or trying to immediately fix it.

You bring genuine curiosity instead of confirmation bias. You’re not trying to validate your idea. You’re trying to understand reality so you can build something that actually fits into it.

And here’s the thing that great product people understand: users often can’t tell you what they want. They can tell you what frustrates them. They can show you how they work. They can describe problems they face. But they can’t design the solution for you. That’s still your job.

Voice of Customer isn’t outsourcing product strategy to users. It’s grounding your strategy in actual human reality instead of theoretical assumptions.

Service Design as a Mindset

Service design thinking takes this even further. It’s not just about talking to users, it’s about designing the entire experience with the user at the center of every decision.

I learned this from watching great hospitality leaders. Will Guidara talks about unreasonable hospitality, going absurdly far to make people feel seen and cared for. Danny Meyer built an empire on enlightened hospitality, making every interaction about serving the person in front of you. These aren’t just restaurant principles. They’re design principles.

Service design says: walk the entire journey your user takes. Not just the five minutes they’re in your product, but the hour before and the hour after. What are they trying to accomplish? What else is competing for their attention? What emotions are they feeling? What would make this easier or more delightful or less frustrating?

It means designing for the context, not just the feature. Understanding that your brilliant solution exists inside someone’s actual messy life with competing priorities and limited time and emotional states that range from stressed to distracted to exhausted.

I was talking to someone recently who’s building a product for busy executives. They showed me this feature that required seven clicks and three different screens to complete a simple task. When I asked about it, they said “well, users can learn the workflow.”

Can they though? Or will they just abandon it because they don’t have time to learn your complicated workflow when they’re trying to do twelve other things and just need this one thing to work simply?

Service design means having the humility to recognize that your user’s time and attention are scarce, and if you make them work too hard, they’ll just stop using your thing. No matter how clever you think it is.

Why This Keeps Not Happening

So if this is so obvious, why do companies keep building in vacuums? Why do smart people keep assuming instead of listening?

A few reasons I’ve observed:

First, talking to users is slower than assuming you know the answer. In a world that rewards speed, taking time to do discovery feels like a luxury companies convince themselves they can’t afford. So they skip it and move straight to building, telling themselves they’ll validate later. Except later means after you’ve already committed the resources and built attachment to your idea.

Second, leadership often doesn’t value it. I’ve placed product leaders who wanted to do proper discovery and got told by their executives to just ship something. The pressure from above is to show progress, to hit dates, to deliver features. Deep user research doesn’t look like progress on a roadmap. So it gets skipped.

Third, it’s uncomfortable. Talking to users means confronting the possibility that your idea isn’t as brilliant as you thought. That the problem you want to solve isn’t actually the problem they have. That your elegant solution doesn’t fit their messy reality. It’s way more comfortable to stay in your conference room with people who agree with you.

Fourth, companies hire product people who don’t have service design training or mindset. They hire people who are good at project management and feature delivery but who’ve never actually watched a user struggle with software. Who’ve never worked in hospitality or service industries where you learn viscerally that what you think people want and what they actually want can be wildly different.

And fifth, there’s this weird arrogance in tech that we’re different. That we’re building the future, so we can’t ask users what they want because they don’t know what’s possible yet. Some Steve Jobs mythology about users not knowing what they want until you show them.

But that’s not what Jobs actually did. He was obsessed with experience design. He sweated every detail of how people would interact with products. He just didn’t do focus groups asking people what features they wanted. Big difference between ignoring users and deeply understanding human needs and designing for them.

What Happens When You Get It Right

Let me tell you about a company I worked with that actually gets this.

They were building a product for healthcare workers. Instead of sitting in a conference room deciding what healthcare workers needed, they spent three months just observing and talking to them. Watching them work. Understanding their day. Seeing their pain points in context.

What they discovered completely changed their product strategy. The problem they thought they were solving wasn’t actually the biggest problem. The users had workarounds for that thing already. The real problem was something totally different that nobody had even thought to ask about.

So they pivoted. Built something different than what they’d originally planned. Something grounded in actual observed reality instead of assumptions.

That product launched and immediately got traction. Healthcare workers loved it because it solved a real problem they actually had in a way that fit their actual workflow. The company grew like crazy because they’d built something people genuinely wanted instead of something they thought people should want.

That’s what happens when you listen instead of assume. You build things that matter. That people actually use. That create real value instead of sitting unused while you wonder why your brilliant idea didn’t take off.

The ROI of Listening

I know what you’re thinking. User research takes time. Service design is a whole discipline. We’ve got deadlines and limited resources and pressure to ship.

But here’s the math that matters: what’s more expensive, spending a few weeks talking to users before you build, or spending nine months building something nobody wants?

What costs more, hiring someone with service design expertise, or burning engineering resources on features that don’t get adopted?

What’s the opportunity cost of shipping things that miss the mark versus shipping things that actually solve problems people have?

Every VP of Product I respect has learned this lesson, usually the hard way. They’ve shipped things that flopped because they assumed instead of listened. And they’ve learned that the time invested in real discovery is the best time they’ll ever spend. It saves time, money, and heartbreak on the back end.

You know what the best product leaders do? They build discovery into their process as a non-negotiable. They don’t ship without it. They protect time for it even when everyone’s pushing them to move faster. They hire people who are good at it and give them space to do it right.

Because they’ve learned that speed without direction is just expensive wandering. And assumptions without validation are just guesses you’re betting your company on.

How This Connects to Everything Else

Here’s what I’ve realized through watching this pattern play out: the same companies that build products in a vacuum are usually the same companies that hire in a vacuum.

They write job descriptions based on what they think they need without talking to the people who’d actually do the job. They design interview processes that test for things that don’t actually matter. They make offers based on what they think the market is without actually understanding what candidates care about.

And then they wonder why they can’t attract talent or why people leave after six months.

It’s the same disease. Assumption instead of listening. Designing for a theoretical person instead of actual humans.

The companies that get Voice of Customer right in their product development also tend to get it right in their hiring, their culture, their customer service, everything. Because it’s not really about a technique or a framework. It’s about a fundamental orientation toward the world.

Are you curious about reality as it actually is, or are you in love with your assumptions? Are you designing for real human needs, or for what you think those needs should be? Are you listening with genuine interest, or just waiting for your turn to talk?

That orientation shows up everywhere. In how you build products, how you hire people, how you serve customers, how you make decisions. It’s either genuine service and curiosity, or it’s arrogance dressed up in fancy processes.

What Product Leaders Should Actually Do

Let me get practical because I’m not just here to point out problems. Here’s what I think should be standard practice for any product organization:

Before you build anything significant, go talk to at least ten users. Not surveys, actual conversations. Watch them work. Understand their context. Ask open-ended questions. Shut up and listen. Take notes on their exact words. Notice what frustrates them and what delights them.

Hire at least one person whose job is service design and Voice of Customer. Not as a nice-to-have research function, but as a core part of your product leadership. Someone who’s trained in understanding human needs and designing for them. Someone who can challenge assumptions and bring real user insight into every decision.

Build discovery into your product development process as a phase that happens before design and engineering. Make it non-negotiable. Don’t let schedule pressure force you to skip it because that’s how you end up building things nobody wants.

Create mechanisms for your product team to regularly interact with users. Not just reading research reports, but actually talking to people. Customer support rotation, user testing sessions, field visits, whatever makes sense for your business. Keep the team connected to reality.

Measure success by user outcomes, not just feature delivery. Did usage go up? Did satisfaction improve? Did we solve the problem we set out to solve? Those are the metrics that matter, not whether you hit your sprint commitments.

Hire product people who have service design mindset and training. Ask about it in interviews. Look for people who talk about users with genuine curiosity and empathy. Who default to discovering before deciding. Who can tell you stories about learning they were wrong and pivoting based on user feedback.

And here’s the biggest one: create a culture where it’s safe to say “we were wrong.” Where pivoting based on what you learned is celebrated, not seen as failure. Where assumptions get challenged and listening is valued. Because if your culture punishes being wrong, people will never admit when their assumptions don’t match reality. They’ll just keep building things nobody wants and making excuses about why they didn’t work.

The Heart of the Matter

Here’s what this all comes down to for me.

Building products is an act of service. You’re creating something meant to help people do something they need to do or want to do. If it doesn’t actually help them, if it doesn’t fit into their reality, if it doesn’t solve a problem they actually have, then you haven’t served anyone. You’ve just built something for yourself.

Great hospitality starts with seeing people. Really seeing them. Understanding what they need, often before they articulate it themselves. Designing experiences that make them feel cared for and understood. Going out of your way to solve their actual problems, not the problems you think they should have.

Product development should work the same way. You’re in service to your users. Your job is to see them clearly, understand their reality deeply, and build things that actually help them. Not to impose your brilliant ideas on them and hope they adapt.

That requires humility. The humility to admit you don’t know everything. The humility to be wrong and change direction. The humility to serve instead of trying to be served by having people validate your ideas.

And it requires genuine curiosity. Real interest in how people work and what they struggle with and what would make their lives better. Not curiosity about whether they’ll like your idea, but curiosity about their reality so you can build something that fits into it.

Those aren’t just product management skills. Those are human skills. Listening skills. Service skills. And they’re becoming more valuable every day because so few people have them or practice them consistently.

Why This Matters Right Now

We’re in this weird moment where AI is supposedly going to revolutionize everything and everyone’s racing to add AI features to their products.

And I’m watching the same pattern play out. Companies building AI features because they think they should, without asking if users actually need them or want them or if they solve real problems.

It’s assumption on steroids. “Users must want AI in everything” without ever checking if that’s true. Building features because competitors are building them, because investors want to hear about them, because it sounds innovative. All without ever asking users “would this actually help you?”

The companies that are going to win aren’t the ones with the most AI features. They’re the ones who actually understand what problems their users have and build AI features that solve those problems in ways that fit into how people actually work.

But you only know that if you talk to users. If you watch them work. If you understand their reality deeply enough to design for it.

Same principle applies whether you’re building AI features or any other feature. Listen before you build. Understand before you assume. Serve instead of imposing.

The Invitation

So here’s what I’m saying to every product leader, every founder, every team building things for humans to use:

Go talk to your users. Really talk to them. Before you build the next thing, spend time understanding the current thing. What works, what doesn’t, what they struggle with, what they wish was different.

Hire people who are good at listening and service design. Make it a core capability, not a nice-to-have. Build a team that defaults to curiosity instead of assumption.

Create space in your process for real discovery. Protect it from schedule pressure. Value it as much as you value engineering and design. Because it’s the foundation everything else builds on.

And most importantly, stay humble. Stay curious. Stay in service to the people you’re building for. That’s not weakness, that’s the path to building things that actually matter.

Because here’s what I know after watching hundreds of companies and thousands of product launches: the ones that succeed long-term aren’t the ones with the smartest people or the best technology. They’re the ones who stay relentlessly focused on serving real human needs instead of falling in love with their own ideas.

They listen instead of assume. They discover instead of decide. They design for reality instead of theory.

That’s how you build products people actually want. That’s how you achieve product-market fit. That’s how you create something that lasts.

Everything else is just expensive guessing. And the market has no patience for that anymore, if it ever did.

So listen. Really listen. Your users are trying to tell you what they need. The question is whether you’re curious enough to hear it.