The anatomy of a good no.

A yes creates continuing work. A no leaves someone with an unresolved need. Both belong in an account of the choice.

The request is reasonable. A customer wants an extra option and an engineer can build it in a day. Saying no now requires a better explanation than saying the team needs to stay focused.

The day of development is only the visible part of the commitment. Once the option exists, someone has to explain it, check it when other things change and help customers who use it differently from the original requester. People who never wanted the option may still have to understand why it is there.

The cost on the other side

Continuing cost is a reason to examine the feature, not a sufficient reason to refuse it. Every useful addition creates some work. The fair comparison includes what the customer does when the product declines to help: perhaps they repeat a manual step, buy another tool, or abandon a task the business claims to serve. Refusing the feature does not remove the need.

A useful decision compares those alternatives. Which part of the customer's job improves, which existing commitment becomes harder and could a narrower change deliver enough of the benefit? A request from one person may expose a difficulty others have not articulated. It may also require a special arrangement the business cannot sustain. Neither the number of requests nor the development estimate settles that distinction.

This makes "It doesn't fit our strategy" an incomplete answer. A refusal should name the conflict: the option would complicate a particular workflow, commit a resource already needed elsewhere, or take the service beyond an obligation the team can support. Specific reasons give the requester something to challenge. They also prevent focus from becoming a respectable name for the decision maker's preference.

A boundary or a limit for now?

There is another distinction worth making explicit: a boundary and a capacity limit are different answers. The business may never intend to provide a particular service. Or it may want to provide it when demand, evidence, or resources change. Leaving both requests on the same indefinite roadmap creates an expectation the team has not decided to meet.

Being clear about the reason makes a future review possible. If the answer depends on sufficient demand, the team can say what it needs to learn about that demand. If the design is the problem, another design may deserve consideration. A no that cannot name any condition under which it might change may be a firm boundary, but it should not pretend to be a pending investigation.

A reasonable request can remain reasonable even when the business cannot accept it. That is the part of saying no we would like to keep in view. The person asking still has a job to finish after the conversation ends. Understanding that cost may change our answer or leave us with a refusal we can explain more honestly.