The Difference Between a Feature Request and a Customer Problem

A customer gets on a call and says, "We need a dark mode."

A founder writes it down, creates a ticket, and an engineer spends three days building it. The customer comes back six weeks later and says they barely use it. What they actually needed was to reduce eye strain during late-night sessions — and the real fix would have been an automatic brightness adjustment, not a theme toggle.

Dark mode was a solution. Eye strain was the problem.

The customer handed you a solution, and you built it without asking what problem it solved. This happens on almost every product team, almost every sprint. And it's the single most common reason teams build features that technically work but don't actually help anyone.

I built my first company, HireAhead, as a solo founder. Early on, I was on a call with Oxford University's talent team, scribbling notes as fast as I could. They said they needed "better candidate filtering." I built better candidate filtering. They used it twice. What they actually needed was the ability to filter by location — one dimension, not a full filter overhaul. I built the wrong thing because I never asked what problem they were trying to solve when they asked for it.

That mistake taught me more about product development than anything I've read since.

Customers don't naturally describe problems. They describe the fix they've already thought of.

That's not because they're unclear thinkers. It's because by the time they're on a call with you, they've already spent weeks or months living with the problem. They've done the diagnosis themselves. They're presenting you with their conclusion.

The problem is that their conclusion is almost always incomplete. They don't know your architecture. They don't know what you're already building. They don't know what a ten-minute fix looks like versus a three-week project. They have no visibility into what's actually feasible or what might solve the problem more elegantly.

When you build directly from their proposed solution, you inherit every one of those limitations. You build exactly what they asked for, potentially missing the underlying need entirely.

Not all feature requests are equal. Understanding which type you're dealing with tells you how much digging you need to do before writing a ticket.

The customer has found a painful workaround for something your product doesn't support natively. They're asking you to make the workaround easier rather than telling you the underlying capability is missing.

"Can you add a way to export to CSV so I can filter in Excel?"

The workaround is Excel filtering. The problem is that your in-app filtering isn't granular enough. Building a CSV export solves the workaround request without solving the underlying problem — and the customer will still be filtering in Excel six months later, just with one fewer click to get the data out.

The customer is describing a symptom of a deeper problem and proposing a fix for the symptom.

"We need better search so we can find things faster."

The symptom is slow search. The underlying problem might be that your information architecture is broken, making it hard to find things regardless of how fast the search is. Building a faster search engine fixes the symptom without fixing the problem.

The customer actually needs a capability your product doesn't have, and has correctly identified that the gap is the problem.

"We need multi-currency support because we're expanding to Europe."

This one is what it looks like. Build it.

Most teams treat all three types the same way. The skill is telling them apart in the moment — and it comes down to asking the right questions.

There is one question that separates a feature request from a customer problem almost every time:

"What are you trying to do when you hit this?"

Not "what do you want us to build?" Not "why do you need this feature?" But "what are you trying to accomplish when you run into this problem?"

That question takes the customer back from the solution they've proposed to the moment they felt the pain. The answer almost always reveals something the feature request didn't — context about what they were doing, what they expected to happen, and what the real obstacle was.

Follow it with: "How are you handling it today?"

The workaround they describe tells you more about the real problem than anything else they'll say. A workaround is a customer's solution to a problem your product doesn't solve. The complexity of the workaround is proportional to the severity of the problem.

A customer who exports to Excel and manually filters 200 rows every Monday morning is in significant pain. A customer who occasionally copies a value into a calculator is not. Both might request "better calculation tools." Only one of them needs it urgently enough to drive a sprint.

Then ask: "What happens if we don't build this?"

If the honest answer is "we just keep doing what we're doing," the urgency is low, and your sprint is better spent elsewhere. If the answer involves customer churn, manual work at scale, or a competitor who already has it — that's your priority signal.

• —You build less. Problems are almost always narrower than the solutions customers propose. "I need to filter my data by two dimensions" is a much smaller build than "I need a full data export with Excel integration." Building from problems means building less — fewer bugs, faster shipping, and lower maintenance overhead.
• —You solve it more completely. A solution built for the real problem addresses the root cause instead of the symptom. The customer stops experiencing the pain. A solution built for the proposed workaround might not solve anything — or might solve it partially, leaving a version of the problem in place.
• —You build things customers actually use. Features built from genuine problems are used because they solve real problems. Features built from proposed solutions often sit unused because the customer's hypothesis about what would fix their problem turned out to be wrong. Usage is the only metric that actually matters — and usage follows from solving real problems.

A ticket written from a feature request: "Add dark mode to the application interface."

A ticket written from the underlying problem: Users who engage in extended late-night sessions report eye strain from the interface's brightness. The current workaround is to reduce the system-wide screen brightness, which affects other applications. Acceptance criteria: users can adjust interface brightness or contrast independently of system settings; changes persist across sessions and are available in user preferences.

The second ticket gives an engineer everything they need to build something that actually solves the problem — including the freedom to implement it in a way that might be more effective than a dark mode toggle. The engineer gets to make that call with the right context, rather than guessing.

Before any ticket enters your sprint, ask one question:

Do we know what problem this is solving, or do we just know what we're building?

If you can describe who experiences the problem, when they experience it, what they're trying to do when they hit it, and what they do today as a workaround, you're building from a problem.

If you can only describe the feature — what it does, how it works, what it looks like — you're building from a request.

The sprint will always move faster with a feature request ticket. It will rarely produce the right outcome.

Customers give you solutions because they've already diagnosed their problem and want to be helpful. Your job is to accept the solution as a signal and find the problem underneath it.

That's where the real build lives. And it's almost always smaller, faster, and more impactful than what they asked for.

Specc extracts the underlying problem from messy customer feedback automatically — separating what customers say from what they actually need before it becomes a ticket. Try it free at speccapp.com