Saying no to a feature (with an alternative)

Sometimes a request is reasonable from the business side and destructive to the model. Editing a settled invoice. Deleting a delivery that already happened. Assigning stock that doesn’t exist yet.

The instinct is to explain why it’s wrong. That rarely works: from the client’s side the explanation sounds like an excuse, and they have a real problem right now.

Separate the request from the solution

Almost always there’s a genuine need underneath, and the specific implementation asked for is just the first one that came to mind:

• “Let me edit this invoice” is usually “I made a mistake and I need the customer to have the right document”. The answer is a credit note and a reissue — which they may not know exists.
• “Delete this delivery” is usually “this shouldn’t count in the report”. That’s a state, not a deletion.
• “Let me sell stock I don’t have” is often a real business practice — backorder — that deserves modelling rather than a workaround.

So the reply isn’t “no”. It’s: here’s what I understand you need, here’s a way to get it that the system can support, and here’s what the original version would cost us later.

The two things I’ve learned to be firm about

Anything that makes the audit trail lie doesn’t get built, in any version. That’s not my preference: it protects them.

When I do accept a shortcut knowingly, I write down that it’s a shortcut and why — so it’s a decision instead of an accident.

Saying no without an alternative is just being difficult.