Saying no, and the true cost of yes

Most requests don't survive the question "why."

Not because people ask for silly things.

A large share of feature requests are a proposed solution attached to a problem nobody examined. Examine it, and either the problem is smaller than it looked or there's a cheaper way to solve it.

Asking early and often is the highest-yield habit available to an engineering leader. It costs one uncomfortable conversation each time.

The alternative is a roadmap that's a queue of other people's conclusions.

The cost of yes, in full

The reason to be hard about this is that the usual accounting is wrong.

A feature gets priced as build time. Build time is the smallest of four costs.

Build. The visible one, and usually the only estimate anybody debates.

Run. It's in production now, so it's in every deploy, every dependency upgrade, every migration, every security review. Forever.

It takes a slice of the on-call rotation whether or not anybody uses it.

Support. Somebody answers questions about it, documents it, explains it in demos.

And each feature makes every other feature slightly harder to understand, a cost paid by users and by whoever onboards them.

Remove. The one nobody prices.

Getting rid of it later means finding out who uses it, migrating them, and having a conversation with whoever asked for it originally. In practice that cost is high enough that most features never get removed, which is precisely why the run cost is permanent.

Add those up and the honest multiple on the build estimate is somewhere between three and ten, over a few years.

That's the number to carry into the conversation. It changes what "small feature" means.

Trade instead of refusing

A flat no makes you the obstacle.

It also starts an argument you'll have again next month, with more political weight behind it.

Better move: make the request compete.

Here's what we're doing now. Here's what yours would displace. Which do you want.

That converts you from the person blocking things into the person holding the ledger. It also moves the decision to where it belongs, which is often the person asking.

Half the time they look at the trade and withdraw, because the request was worth having but not worth that.

A much better outcome than your refusal. They arrived at it themselves, and they'll remember it that way.

The trade only works if the current list is real and visible.

If nobody can see what the team is doing, "this would displace something" sounds like an excuse. Which is the actual argument for a public roadmap. Not transparency for its own sake. So that no is structural rather than personal.

Two variants worth carrying.

The smaller-thing trade: I can't do that, I can do this narrower version in a week, and let's find out whether it solves the problem.

The later trade: yes, in Next, and here's what would have to become true to move it up.

When the answer is really no

Some things get refused rather than traded.

The tell is that they'd change what the product is rather than add to it.

The single-customer feature no other customer will ever want.

Worth naming explicitly, because it's the most common source of permanent liability in B2B companies.

Sometimes the contract genuinely justifies it. Then the honest framing is that this is paid custom work carrying a maintenance cost, not a product decision, and somebody should be pricing it that way.

The thing that exists to satisfy an internal fear rather than a user. A dashboard nobody will open. A configuration option added because one person imagined an objection.

The thing that's genuinely somebody else's job. Not everything a stakeholder wants needs software. Quite a lot of requests are process problems in a trenchcoat, and building the software makes the process permanent.

Say it plainly, once, with the reason, and don't soften it into a maybe. A soft no is the worst outcome available: the requester keeps hoping, brings it back in six weeks, and eventually concludes you're indecisive rather than that you disagreed.

Sunsetting, and why it's harder than it should be

Removing a feature is the highest-return work most companies never do, and the obstacle isn't technical.

It's that removal has an identifiable loser. Somebody pushed for this, or uses it, or built it. Adding has diffuse costs and a specific winner; removing has diffuse benefits and a specific loser, and organisations are built to avoid the second.

What makes it possible is a mechanism that isn't a debate. Something like: once a year, every feature gets checked for usage, and anything below a threshold goes on a list with a proposed removal date. The default is removal, and keeping something requires an argument rather than the reverse. That inversion is the whole trick, because the effort now falls on the person who wants to keep it.

Then run the removal like a small product launch. Tell the users, give them a route, keep it visible for a month. The reason removals go badly is almost never the deletion, it's a customer discovering it by accident.

And measure what you got back: the deploys that got faster, the on-call load that dropped, the code nobody has to understand. Nobody gets credit for deletion unless somebody counts it, and if nobody gets credit, it stops happening.

The list worth keeping

Keep a written record of what you said no to and why. It takes a line per item.

Three reasons it earns its place. It stops the same request being relitigated every quarter by someone new, because you can point at the reasoning rather than re-deriving it. It gives you a check on your own judgment, since some of those no's will look wrong in a year and you should know which ones. And it's the only real evidence of your strategy: what a company chose not to build says more about what it is than any of the things it did.

If that list is empty, you don't have a strategy. You have a queue with a nice name.