A feature request is usually not the problem

Why good product decisions start by understanding the job behind the request.

When you build products, customers often speak in very concrete terms.

“Can you add Excel export?”
“Can you send alerts more often?”
“Can you expose this through an API?”

Early in my product career, I thought collecting more of these requests was one of the best ways to understand customers. If the same request came up repeatedly, it seemed reasonable to raise its priority.

Over time, I started to see the flaw in that approach.

A feature request is usually a real signal of need, but the request itself is not necessarily the best product answer.

1. Users often describe problems as solutions

When I worked on predictive-maintenance products, customers sometimes asked for Excel export.

At first glance, the requirement was simple: let users download the data as an Excel file.

But when we asked what they wanted to do after exporting it, the answers were different. One person needed the file to prepare a report for management. Another needed to share equipment conditions with the production team. Someone else had to copy the data into an existing company template.

In some environments, Excel was simply the easiest way to move information because API integration was not practical.

The feature request was the same, but the underlying jobs were different.

So the more useful question was not:

Should we build Excel export?

It was:

What are you trying to do after you export the data?

That distinction matters because users often experience a problem, interpret it, and then describe the solution they have already imagined.

A feature request can be less like a problem statement and more like a proposed answer.

2. Good product teams do not simply collect requirements

One idea from Marty Cagan’s INSPIRED has stayed with me for a long time.

In his contrast between good and bad product teams, he writes:

“Bad teams gather requirements from sales and customers.”[1]

His broader point is not that product teams should ignore customers. It is that good teams go deeper than collecting requests.

They draw product ideas from the company’s vision and objectives, observe where customers struggle, study how people actually use the product, analyze the data those interactions create, and continuously explore new technologies that may solve problems in better ways.[1][2]

I like this distinction because it clarifies the role of the customer.

Customers are usually excellent sources of information about their pain, context, priorities, and constraints. But they are not necessarily in the best position to design the optimal product solution.

A product has to satisfy more than customer desire alone. It also has to be technically feasible and commercially viable.

A customer may know exactly what is frustrating them, but they may not know which architecture is sustainable, which trade-offs matter, or which solution can be supported economically across thousands of users.

The product team’s job is to translate that technology into value.

3. A feature request is a clue, not an answer

Suppose a customer says:

“We need real-time data.”

It is easy to treat that as a requirement and immediately start thinking about streaming, faster communication, and a new data pipeline.

But “real-time” can mean very different things.

Does the customer need updates every second, every hundred milliseconds, or simply faster than the current system? Are they trying to control equipment, or do they just want to know about important changes sooner?

Once you understand the actual job, a different solution may appear.

The product might need a shorter measurement interval. It might make more sense to detect specific events at the edge and send only important changes immediately. A better alerting mechanism might solve the real problem without introducing the cost and complexity of continuous real-time streaming.

This is why I now respond to feature requests with questions such as:

• What do you do after you get this?
• Who needs the result?
• What decision does it support?
• How do you do this today?
• What happens if you cannot do it?

Those questions move the conversation away from the requested feature and toward the user’s workflow.

A feature request is a bit like a patient asking a doctor for a specific medicine. The request may be reasonable, but the doctor still needs to understand the condition before deciding on the treatment.

The proposed solution is useful information.

It is not the diagnosis.

4. Product teams have to translate the request back into the problem

The product team’s role is not to assume it knows better than the customer. It is also not to reject feature requests simply because they came from customers or sales.

The job is to treat those requests as evidence and work backward.

I think about the process like this:

Request → Why → Workflow → Problem → Constraints → Solution

The customer gives you the request. The product team asks why. That leads to the workflow, which reveals the actual problem.

Then technical and business constraints enter the picture.

Only after that should the team decide what the solution needs to be.

When this order is reversed, product teams can easily become feature factories. Sales collects requests, product adds them to the backlog, and engineering implements them.

It can look customer-centric because the team is responding to customers.

But responsiveness is not the same thing as solving the right problem.

Customer-centric product development is not about building everything customers ask for. It is about understanding what they are actually trying to accomplish and finding a better way to help them do it.

That is the difference between a team that implements requirements and a team that solves problems.

The feature request is usually not the problem

Customer requests should never be ignored. They usually come from real friction.

But they should not automatically become the product definition either.

A feature request is often a clue, not the answer.

Customers understand their problems through lived experience. Product teams have to observe those problems, understand the surrounding workflow, study the data, explore what technology makes possible, and account for the constraints of the business.

The product emerges from the intersection of those things.

So when I hear a feature request now, the first question I try to answer is not:

Should we build this?

It is:

What problem is this request trying to solve?

And once you start asking that question, another issue appears.

Much of the context people use to make decisions is never written down in the first place.

That is what I want to explore next: Tacit Knowledge is the missing dataset.

References

[1] Marty Cagan, INSPIRED: How to Create Tech Products Customers Love, section on “Good Product Team / Bad Product Team.” Cagan contrasts bad teams that gather requirements from sales and customers with good teams that derive ideas from company vision and objectives, observing customer struggles, product analytics, and continuous exploration of new technologies.

[2] Marty Cagan, “Good Product Team / Bad Product Team,” Silicon Valley Product Group. The essay presents the same distinction between teams that collect requirements and teams that discover solutions by understanding customers, business constraints, and technology.