Sometimes, a feature request sounds like a clear direction. But if we take it at face value, we risk solving the wrong problem.

I know this because I’ve made that mistake myself.

Even when a request comes directly from customer feedback, it doesn’t guarantee you’re solving the right problem. There’s a deeper pain point hiding underneath.

Why start with a problem?

When research is used to confirm a chosen solution, we risk overlooking the underlying problem.

What we should focus on is the why, not just the what users ask for.

How do we find the real problem?

Not every designer has full control over the research process. In my experience, working closely with customer-facing teams helped me uncover valuable insights hidden in support tickets, feature requests, or casual conversations.

Even when users request a specific solution, we can still find a deeper need behind it. The key is to ask the right questions.

• What’s their goal?
• What’s their current behavior?
• What’s frustrating about it?

Let’s look at the example.

Imagine a user of a CRM (Customer Relationship Management) software says

“I want to set up automated email reminders for my follow-ups because I have many leads to manage and it’s hard to keep track of all of them. Right now, I rely on my memory or manual calendar alerts, but I often miss opportunities, especially when my workload is high.”

At first glance, it sounds like a simple feature request. But to really understand what’s going on, I try to interpret the meaning behind the feedback.

Here’s a simple structure I use to break down:

• Solution - Automated email reminders.
• Objective - Keep track of leads and stay on top of follow-ups
• Underlying need: Manage a growing number of leads efficiantly.
• Current behavior: Relying on memory or manual calendar alerts.
• Pain Point: Missing follow-up opportunities, losing potential leads, and feeling overwhelmed by lead management

Now, does the requested solution “reminder” solve the deeper problem?

It might help them remember, but it doesn’t solve the overwhelm. If the user has hundreds of leads, reminders could just pile up and create more noise.

If we had built reminders, we would have solved the symptom (forgetting), but the cause (too many leads to manage) would remain unresolved.

Breaking down this way helps us step back and see whether the requested solution addresses the underlying needs.

This might not be the most ideal approach for UX research, but making the most of the data you do have is far better than doing nothing at all.

In the end, understanding the user’s goals and struggles is what leads us to solving the real problems, not the requested features.

P.S. I came across the video How to Get and Evaluate Startup Ideas. One of the four mistakes it mentions is starting with a solution in search of a problem. That helped me realize why my approach felt off.

While the video isn’t directly about product or UX design, the message resonated with me deeply. If you’re curious, it’s worth checking out.