Why has "we do not have time" stopped working as a reason to decline?

Because it is often no longer true, and the person asking knows it. When a working version can be produced in an afternoon, an effort-based refusal sounds like an excuse, so the honest argument has to be about the maintenance cost, which cheap AI-written code did not reduce.

What is the real cost of an extra feature?

The permanent work it adds rather than the time to build it: it must be tested on every release, kept working through every dependency upgrade, accounted for in every future design, explained to each new engineer, and supported when a customer finds an unusual case years later.

What should you ask before answering a feature request?

What problem it solves described without naming the solution, what happens if it is never built, and what it will cost to keep in five years. The first question alone completely changes a large share of requests, because people tend to arrive with a solution rather than a problem.

How do you decline without damaging the relationship?

Give the reason, name what is being protected, and record the decision where it can be found later. People accept a no that comes with a trade-off they can argue with, and they resent a vague deferral because it hides the decision instead of making it.

Why is "not right now" worse than a clear no?

Because it creates a list nobody looks at again and lets everyone avoid the conversation. The request sits on the list of later work for years, the requester assumes it is coming, and the decision that was actually made never gets written down or challenged.

What if the request comes from your largest customer?

Then the question becomes whether it belongs in the product for everyone or in a separate part built for that customer, such as configuration or an integration point. Building one customer's specific workflow into the shared product is how a product slowly turns into custom software with a single user paying for it.

How do you handle a request from an executive?

The same way, with the reasoning made explicit and in writing rather than in a meeting. Most executive requests are a sign of a real problem they have observed, and asking what they saw usually produces a better statement of the problem than the feature they proposed.

When is the right answer actually yes?

When the problem is real, common among users you intend to serve, and unsolvable with what already exists in the product. The third test matters most, since a large share of requests are for something the product already does in a way nobody could find.

Does saying no more often make a product worse?

It generally makes it better, because every feature competes for attention in the interface and for time in maintenance. A product that answers a narrow set of needs clearly is easier to learn and easier to keep working than one that answers many needs partially.

What should you do about features you already built and nobody uses?

Measure usage, then remove the ones nobody depends on, with notice and a way to move to something else where anyone does. Removal is the only action that reduces ongoing work, and teams usually find that far less is in use than anyone assumed.

How does cheap AI-written code change the discipline of limiting scope?

It removes the natural limit that slow building used to provide, so the team now has to apply that discipline on purpose and in writing. The constraint now is how much can be reviewed, understood, and maintained, and that constraint is set by people rather than by tooling.

How to say no to a feature request: Reveneau

"It is only a small change."

It usually is, and that was never where the money went.

For most of the history of this profession, the reason to decline a feature was effort. Building took weeks, weeks cost salary, and so the argument made itself without anyone having to be a difficult person about it. The shortage of time made the decision for you.

That argument has gone. When a model can produce a working version of a request in an afternoon, "we do not have the capacity" is no longer true, and the person asking usually knows it. Continuing to use the old reason makes you sound unhelpful rather than careful.

So the argument has to be about where the cost always was.

The cost that did not fall

Writing the feature is the smallest expense it will ever generate.

After it is released, it is tested on every release forever. It has to keep working through every dependency upgrade and every framework migration. It appears in every future design conversation as a constraint. It gets explained to every engineer who joins. It has to be supported when a customer finds an unusual case in it three years from now, probably by someone who was not there when it was built.

None of that got cheaper. If anything it got harder, because output rose while the number of people who actually understand the system stayed the same. The 2025 DORA report, drawn from nearly 5,000 professionals, found AI adoption relating positively to delivery throughput and negatively to delivery stability, and summarised the effect plainly: "AI doesn't fix a team; it amplifies what's already there". A team that is bad at limiting scope now shows that weakness much faster.

This is the honest version of the refusal, and it works in the meeting: we can build it this week, and we will maintain it for a decade.

Three questions before you answer

What problem does this solve, described without the solution?

Most requests arrive as a solution. Someone has already decided what should be built and is asking for the build.

Ask what they were trying to do when they decided they needed it. A large share of requests change completely at this point, and a good number turn out to be solvable with something the product already does that nobody could find. That is a problem of people not finding an existing feature, presented as a feature request, and building the feature would leave the actual problem in place.

This question is also the one that keeps the conversation collaborative. You are asking about their problem rather than judging their idea.

What happens if we never build it?

Ask for the specific consequence. A customer leaves. A workflow stays manual and costs someone six hours a week. A deal does not close.

If the answer is that it would be nice, or that a competitor has it, that is your answer. Matching a competitor is the weakest reason to build anything, because it assumes their prioritisation was correct and copies their mistakes into your product.

What does it cost to keep?

Ask about five years, not this sprint. Does it add a permanent extra path to a main flow. Does it need its own permission rules. Does it create a data format that has to be migrated forever. Does it constrain a change you already know is coming.

Some small features are structurally expensive: a single toggle that doubles the number of states an important flow can be in will be paid for on every future change to that flow. Some large features are cheap, because they are separate from the rest of the system and change nothing else. Size in the request is a poor guide to either.

The practical test is where the feature is placed rather than how big it is. Something separate from the main system, with its own data and its own screen, can be built and later removed without disturbing anything. Something built into a main flow becomes a condition that every future change has to satisfy, and it cannot be removed later without taking apart the flow it was built into.

So ask where it will be placed before asking how long it takes. A week of work in a separate part is usually a better trade than a day of work in a main flow.

How to actually say it

Give the reason. Name the trade-off. Write it down.

"No, because supporting this would slow down the checkout work we agreed matters most this quarter" is a decision someone can argue with, and being able to argue with it is what makes it acceptable. "Not right now" avoids a decision. It puts the request on a list nobody looks at again, and the requester spends two years assuming it is coming.

We think the deferred maybe is the least honest thing in product management, for a simple reason: it lets everyone avoid the conversation while the real decision gets made anyway, silently, by nobody. Related reading is in why your MVP should do less than you think and why scope creep happens and how to stop it.

Record it where it can be found. The same request will arrive again in eight months, possibly from the same person, and a written decision converts a repeated argument into a short conversation about whether anything has changed.

Two harder cases

The largest customer. The question is whether this belongs in the product for everyone, or belongs in a separate part: configuration, an integration point, an export. Building one customer's specific workflow into the shared product is how a product turns slowly into custom software with a single user paying for it, and everyone else pays for the complexity in the interface.

The executive. Same method, in writing rather than in the meeting. Most executive requests come from something real they observed: a customer call, a demo that went badly, a competitor conversation. Asking what they saw usually produces a clearer problem statement than the feature they arrived with, and it treats their input as information rather than as an instruction.

The part nobody schedules

Removal is the only action that reduces ongoing work, and almost no team does it deliberately.

Measure what is actually used. Teams are routinely surprised by how much of the product nobody uses, and each unused feature is still being tested, maintained, and displayed to users who have to scan past it. Take those out, with notice and a way to move to something else for anyone who does depend on them.

A review once a quarter is enough. It is also the most reliable way to make the case for saying no in the first place, because a team that has removed things has direct experience of what keeping them cost. Our note on the surrounding decisions is in what is technical debt and when to pay it, and the review-side version of the same volume problem is in what good code review looks like when nobody wrote the code.

What replaces the old constraint

Slow building used to limit scope by accident. It was never a good method, only a reliable one, and it is gone.

What replaces it has to be chosen on purpose. The real limit now is how much a team can review, understand, and keep working, and that limit is set by people rather than by tooling. Faster code does not change it.

Thanks to the product teams who let us attend while they turned things down, and were candid about the requests they wished they had declined. The yes they regretted was almost always a small feature, in a central place, that quietly made every later change harder.

Building it is a week. Maintaining it lasts for the rest of the product's life, and only one of those two numbers is on the estimate.

Related guide: How to prioritize features.

Sources

2025 DORA report announcement, Google Cloud: nearly 5,000 respondents; AI adoption relates positively to delivery throughput and negatively to delivery stability, and amplifies a team's existing strengths and dysfunctions.

How to say no to a feature request