by Gary Worthington, More Than Monkeys

A common mistake I see in early-stage startups is building what users ask for. That might sound odd, surely listening to customers is the right thing to do?

The nuance most miss is that you should listen to your users’ problems, not their solutions.

The Illusion of Good Feedback

When you interview potential customers, they’ll often tell you exactly what they think they need.

• “Can you add a search bar so I can find old messages?”
• “We need a dark mode for the dashboard.”
• “Could you build an integration with Slack?”

It feels like gold dust — clear, direct guidance from the people you want to serve.

But there’s a catch. These requests are rarely solutions in any meaningful sense. They’re symptoms. The customer is trying to articulate a pain in the only way they know how; by sketching out a feature that seems to ease the discomfort.

If you take those requests at face value, you risk filling your backlog with other people’s half-formed ideas. You become a feature factory rather than a problem-solving company.

Why Problems Matter More Than Solutions

When you focus on the problem, you uncover the motivation behind the request.

• The “search bar” request might be about struggling to recall key information quickly, which could be solved by search, or by smarter summaries, tagging, or even reminders.
• The “dark mode” request might be about eye strain after long hours, but maybe the deeper issue is poor visual hierarchy and contrast in the current design.
• The “Slack integration” might actually be about wanting real-time alerts, not Slack itself. The right fix could be SMS, push notifications, or a custom webhook.

If you solve the real pain point, you not only make the customer happier, you also create a solution that generalises across your market. Problems are universal; solutions are personal.

The Psychology at Play

Users fall into a natural trap known as solution bias They jump to the fix they can imagine, not the one that’s truly effective. It’s the same reason patients walk into a doctor’s office asking for antibiotics, when what they really need is rest.

Founders and product teams often suffer from the mirror image: confirmation bias. When a user suggests a feature that matches their existing roadmap or pet idea, it feels like validation. “Look, the customers are asking for it!” In reality, it’s often a false signal.

A Practical Framework

Here’s how to shift from feature requests to problem discovery:

1. Note the request, but don’t stop there. Write it down, then ask: “What would that help you achieve?” or “What happens today when you don’t have that?”
2. Listen for friction. What inefficiency, frustration, or lost opportunity is hiding behind the request?
3. Reframe. “So what I’m hearing is that finding the right conversation quickly is the real challenge, not specifically a search bar. Is that right?”
4. Explore alternatives. Consider multiple ways of solving the pain, not just the one proposed.
5. Test the problem before the solution. Validate that the pain is significant and widespread before building anything.

This is the essence of Jobs to Be Done (JTBD) thinking: customers “hire” your product to do a job. Features are just different ways of delivering it.

Startups That Get This Wrong

I’ve seen startups treat every feature request as a ticket. Six months later, they have:

• A cluttered interface, because they bolted on every user’s suggestion.
• An exhausted engineering team working on low-impact items.
• A strategy dictated by the loudest customer, not the largest need.

The result is usually a product that feels unfocused, and a company that burns through cash without building real traction.

Startups That Get This Right

There are plenty of public examples of companies who built their success by relentlessly focusing on problems rather than features.

• Slack started life as an internal tool for a games company. Its founders didn’t build it because people asked for a chat app — there were dozens already. They noticed that teams struggled to keep track of conversations and context across fragmented tools. By solving that underlying problem of “where was that discussion?”, they created an entirely new category.
• Airbnb didn’t start with “we want to be a hotel replacement.” The founders’ own pain was struggling to pay rent in San Francisco while a design conference was in town. The core problem was that people needed short-term, affordable accommodation that wasn’t being served by hotels. That single pain point became the seed of a global platform.
• Dropbox famously validated the problem of file syncing before building the full product. Rather than adding features like “bigger email attachments,” they asked: “why can’t files just be everywhere you need them?” A short video demo addressed the underlying frustration, and tens of thousands of people signed up to the waiting list.

In my own consultancy work, I’ve seen the same pattern. The startups that thrive are the ones who insist every product conversation starts with the pain. The ones who flounder are the ones with backlogs full of unchecked feature requests.

Why This Is Hard

It’s not that founders don’t care about problems. It’s that it feels unnatural to not act on what customers directly ask for.

When you’re trying to land your first ten customers, saying “we’re not going to build that” feels reckless. You don’t want to lose the lead.

But reckless is building the wrong thing well.

The discipline is to say: “That’s interesting …can you tell me more about what makes that important to you?” You show empathy, keep the conversation open, and gather the insight you really need.

The Takeaway

Startups live or die on whether they solve meaningful problems.

• Customers describe symptoms, not diagnoses.
• Your job is to diagnose.
• Solutions come from you, informed by their context.

The best founders are not feature collectors. They are problem obsessives.

Listen intently to your users. Just don’t build what they tell you.

Build what they need.

Gary Worthington is a software engineer, delivery consultant, and agile coach who helps teams move fast, learn faster, and scale when it matters. He writes about modern engineering, product thinking, and helping teams ship things that matter.

Through his consultancy, More Than Monkeys, Gary helps startups and scaleups improve how they build software — from tech strategy and agile delivery to product validation and team development.

Visit morethanmonkeys.co.uk to learn how we can help you build better, faster.

Follow Gary on LinkedIn for practical insights into engineering leadership, agile delivery, and team performance.