A feature request is useful information. It tells you that someone is trying to make progress and the current product is not helping them enough.
It does not automatically tell you what to build.
Teams get into trouble when a requested solution moves directly into the backlog. Over time, the product becomes a collection of local fixes: more settings, more states, more permissions, and more paths that every future change must preserve.
Good product judgment begins by separating the need from the proposed feature.
Find the outcome behind the request
When a customer asks for an export button, the underlying need might be reporting to management, moving data into another system, creating a backup, or working around a missing view.
Those are different problems with different solutions.
Before estimating the feature, ask:
- What are you trying to accomplish?
- What happens after you use this feature?
- How are you handling this today?
- How often does the situation occur?
- What is the cost when you cannot do it?
- Who else has the same problem?
The purpose is not to challenge the customer. It is to avoid making them design the product for you.
Look for evidence of the problem
Urgency is not the same as importance. A request from a large customer can be commercially important, but it can also be a one-off workflow that adds permanent complexity for everyone else.
Useful evidence can include:
- Repeated requests from users with similar goals.
- Support conversations showing the same obstacle.
- Behavioral data that reveals where a workflow stops.
- Time spent on a manual workaround.
- Revenue, retention, or risk connected to the problem.
- A strategic capability the business has deliberately chosen to develop.
Evidence does not need to be perfect. It needs to be strong enough for the size and reversibility of the investment.
Count the cost after launch
The build estimate is only the first cost of a feature.
A new capability may introduce database migrations, permissions, analytics, documentation, onboarding, support cases, accessibility requirements, mobile states, security reviews, and future compatibility work.
It also consumes attention. Every new option makes the product harder to explain and the codebase harder to change. Engineers must consider it during future work even when no one actively uses it.
When comparing options, ask about the continuing cost:
- How many new states does this add?
- Which teams must maintain it?
- What happens when the underlying workflow changes?
- Can the feature be removed if it is not useful?
- Does it make the main experience clearer or more complicated?
A small interface change can create a large operational commitment.
Consider the smallest useful intervention
The alternative to a large feature is not always “do nothing.” Often there is a smaller way to test the need.
You might improve existing copy, change a default, add a saved view, expose a limited integration, automate an internal step, or handle an early workflow manually for a small group of customers.
The best first version should answer the most important uncertainty. If you do not know whether people need the outcome, build the smallest experience that lets you observe demand. If demand is proven but the technical approach is risky, prototype the integration or data model first.
A thin slice is valuable when it is complete enough to deliver the outcome. A collection of disconnected partial screens is not a thin slice; it is unfinished work.
Prefer reversible decisions when evidence is weak
Some changes are easy to reverse: a new onboarding message, an experiment behind a feature flag, or an optional report for a limited group.
Others are expensive to unwind: a public API contract, a permanent pricing promise, a new permission model, or data that must be retained indefinitely.
When confidence is low, choose an approach with a small blast radius:
- Limit the first release to a defined user group.
- Keep the data model simple until the workflow is proven.
- Avoid promising general availability too early.
- Decide in advance what success and failure look like.
- Set a date to review whether the feature should expand, change, or disappear.
Reversibility lets the team learn without turning every experiment into permanent architecture.
Make the tradeoff visible
Saying yes to one feature means delaying something else. That tradeoff is often hidden because backlogs show requested work without showing the opportunity it displaces.
A useful decision note can be short:
- The user outcome we are trying to improve.
- The evidence that the problem matters.
- The options considered, including doing nothing.
- The expected benefit and total cost.
- The main risk or unknown.
- The decision and when it will be reviewed.
This gives product, design, and engineering a shared reason for the work. It also prevents the team from reopening the same discussion without new information.
Saying no should still help the customer
A good “no” does not dismiss the request. It shows that the need was understood.
Explain what you heard, why the proposed feature is not the right investment now, and what alternative is available. If the decision may change, say what evidence would cause the team to reconsider it.
Sometimes the answer will still be yes. A feature may solve a frequent, painful problem and fit the direction of the product. The point of this process is not to build less for its own sake. It is to spend engineering effort on outcomes that justify the complexity they create.
The strongest products are not the ones with the longest feature lists. They are the ones whose capabilities feel deliberate.
