The request often sounds straightforward.

“We need a dashboard.”

“Can we add notifications?”

“We should build a mobile app.”

“Customers are asking for this feature.”

A stakeholder presents a feature they believe is important. The engineering team begins discussing implementation. Questions arise about architecture, effort, dependencies, and timelines. The conversation moves quickly toward solutions.

And yet one of the most important questions often goes unasked:

What problem are we trying to solve?

Features Are Usually Proposed Solutions

When stakeholders request features, they are rarely asking for the feature itself. They are trying to solve a problem.

The dashboard is meant to improve visibility.

The notification system is meant to increase engagement.

The mobile app is meant to improve accessibility.

The feature is the proposed solution. The underlying need is the real issue. Good engineers understand this distinction. They recognize that the first solution presented is not necessarily the best one, or the only one.

The Stakeholder May Be Solving Their Own Problem

Stakeholders see the organization through a different lens. A sales leader sees customer objections. A support leader sees recurring complaints. A product manager sees adoption challenges. An operations leader sees inefficiencies.

By the time a request reaches engineering, the stakeholder may already have developed a solution in their mind. The challenge is that they are usually experts in the problem, not necessarily the solution.

Good engineers respect this distinction. The stakeholder’s insight into the problem may be invaluable. The proposed solution is simply one possible response.

Sometimes the Feature Is Not the Problem

Imagine a stakeholder asks for a dashboard. The conversation immediately focuses on reports, charts, and data visualizations. But a few questions later, something becomes clear.

The real issue is that managers do not know when projects are falling behind. A dashboard might help. So might automated alerts, or weekly summaries, or clearer ownership. Once the problem is understood, many possible solutions may emerge.

This is why good engineers spend time understanding the need before debating implementation.

Start With Curiosity

A common mistake engineers make is evaluating the feature before understanding the problem.

The discussion immediately becomes:

How difficult will this be?

How long will it take?

What technology should we use?

These are important questions, but they are not the first questions. Good engineers begin with curiosity.

They ask:

What problem are we trying to solve?

What is happening today that is not working?

Who is affected?

Why is this important now?

These questions often reveal information that was hidden beneath the original request.

The Feature Is Not the Outcome

Once the problem is understood, another question becomes important.

What change are we hoping this feature will create?

Teams often focus on whether a feature can be built. Far fewer discuss what will be different after it is built.

The dashboard is not the outcome. Better visibility is. More notifications is not the outcome. Higher engagement is. The mobile app that you’re ask to build is not the outcome. Improved accessibility is.

This distinction matters because multiple features can often achieve the same outcome. In some cases, a simpler solution may achieve it more effectively.

Good engineers therefore look beyond the requested feature and ask:

What are we hoping will improve?

How will people behave differently?

How will we know the situation is better than it is today?

These questions shift the conversation from implementation to impact. The goal is not to build the feature that was requested. The goal is to create the outcome that was intended.

Who Gets Affected?

A stakeholder request often arrives from a specific perspective. A sales leader wants a feature that will help close deals. A support leader wants a feature that will reduce customer complaints. A product manager wants a feature that will improve adoption.

Each perspective is valuable. But no single stakeholder sees the entire system.

Good engineers therefore ask a broader question:

Who else will be affected?

A feature that helps one group may create additional work for another. A workflow that improves efficiency for customers may increase operational complexity behind the scenes. A reporting capability that helps managers may introduce new maintenance burdens for engineering teams.

Understanding these trade-offs is part of good judgement. The goal is not to satisfy the loudest stakeholder. The goal is to understand how the decision affects the broader system of people who must live with it.

Consider the Whole System

Features rarely exist in isolation. Every new capability interacts with something that already exists. It affects workflows, processes, dependencies, operational procedures, and user expectations. A stakeholder may see the feature itself. Engineers must also see its consequences.

A seemingly simple request can introduce new failure modes, additional support requirements, performance implications, security concerns, or maintenance costs. None of these considerations necessarily invalidate the feature. But they should be part of the discussion.

Good engineers look beyond the immediate request and ask:

What changes if we add this?

What becomes more complex?

What new responsibilities are created?

What unintended consequences might emerge?

This broader perspective helps teams avoid solving one problem while accidentally creating three new ones.

A Better Question Than “Can We Build It?”

Engineering teams are often asked whether something is possible. In many cases, the answer is yes. The more useful question is:

Should we build it?

That question requires a deeper understanding of the problem, the alternatives, the costs, and the expected outcomes. Technical feasibility is important, but feasibility alone is rarely sufficient justification.

Good judgement requires considering whether a proposed solution is the best use of time, effort, and attention.

The Goal Is Alignment

None of this means engineers should challenge every request. Nor does it mean stakeholders should stop proposing solutions. The goal is not opposition. It is alignment.

Stakeholders bring valuable context about business needs, customer problems, and organizational priorities. Engineers bring expertise in systems, implementation, and technical risk.

The best decisions emerge when both perspectives are understood.

Why This Matters

Many organizations spend enormous amounts of time discussing solutions. Far fewer spend time understanding the problem.

Good engineers resist the temptation to start with implementation. Instead, they begin with understanding. Because features are proposed solutions. Problems are where the real discussion should begin.