How to Say No to Feature Requests by Publishing What Your Product Does Not Do

Most teams already know what they do not intend to build. The knowledge exists: in a strategy document nobody outside the founding group has read, in a pinned message in a channel, in the head of whoever has been on the product longest. It is real knowledge, and in that form it does almost no work. It is present only in rooms where the person holding it is present, which means every request that touches it restarts the argument from the beginning.

That is the actual cost, and it is easy to underestimate because it never arrives as a single bill. A request comes in. Somebody in support hedges, because they are not certain. It escalates. Someone senior explains the reasoning again, competently, for the eleventh time. The requester leaves with a private impression rather than a stated position, and repeats that impression to somebody else in a shape you would not recognise. Multiply it across a year and a good deal of your most expensive attention has gone on re-deriving a decision that was made once and never written anywhere a stranger could find it.

So the practical question is not how to say no to feature requests. Most teams can manage a single no in a single meeting. The question is how to say it once, in public, in a form that keeps saying it: to the prospect reading your documentation at two in the morning, to the new colleague in their first week, to the support agent who joined last month and has no institutional memory to draw on.

The obvious objection is that publishing what a product does not do is advertising your weaknesses. That reading holds only where the items are weaknesses. Where a boundary is a decision with a reason attached, the reader learns something they were going to learn regardless; the difference is that they learn it now, cheaply, from you, instead of in week three of an implementation, expensively, from their own frustration. The buyer who walks away at the reading stage was never a customer. They were a support ticket with a delay on it.

The buyer who disqualifies themselves from your documentation costs you nothing. The same buyer, discovered in month two of an implementation, costs everybody.

Three things follow from putting the list up. Onboarding shortens, because a new colleague can read the shape of the product's intent rather than infer it from whatever happens to exist in the interface. Support load falls, because the most expensive tickets are rarely the difficult ones; they are the ones founded on a wrong assumption that nobody corrected early enough. And sales conversations start further along, because the person on the call has already selected against the thing you were otherwise going to spend the first fifteen minutes explaining.

Refusals are not interchangeable, and treating them as one thing is why so many published non-goals read as evasive. A list that says only that certain things are out of scope tells the reader nothing they can act on. Four distinct refusals are worth separating, because each has a different tell, a different sentence, a different objection waiting for it, and a different condition under which it should be reconsidered. Sorting a request into the right one is most of the work; once it is sorted, the wording tends to follow.

Wrong user

The request is coherent, well argued and entirely reasonable, and it belongs to somebody the product is not built for. The tell is usually structural rather than functional: the requester describes a workflow involving roles your product has no people to fill, or an approval chain that assumes an organisation several times the size of your typical account, or an administrative layer sitting above the individual you designed for.

The temptation is to serve them anyway, on the grounds that a feature is a feature. The cost is that the default path fractures. You now maintain two ways through the product, and the second exists for a user you are not otherwise investing in, which means it is the one that will rot. Say no here and the sentence is about fit: this is built for a particular person doing a particular job, and that is not the person you have described.

The counter-case deserves stating plainly, because this refusal is the one most often wrong. If the segment you are declining turns out to be the market that would actually have paid, the non-goal was not discipline; it was a strategic error you wrote down and defended in public. The evidence that should worry you is repeated requests from accounts that already bought and stayed, rather than from prospects who never did. Prospects describe the product they imagined. Retained customers describe the product they use.

Wrong moment

The request is right for your user and wrong for the product now, because something it depends on does not exist yet. This is a sequencing refusal, and it is the most delicate one to publish, because it shades into a roadmap claim the moment you word it carelessly.

The discipline is to state the dependency rather than the timing. Not built yet, because the thing it would have to sit on has not been settled, is a sentence you can defend indefinitely and revise honestly. Coming later this year is a promise, and a promise on a list of non-goals is a strange and unstable object: it invites the reader to wait rather than to decide, and it converts a boundary into a debt. If you cannot name the dependency, you probably have a wrong-depth or wrong-business refusal wearing a sequencing costume, and you should sort it again.

Wrong depth

The request asks the product to go a layer deeper than its shape supports. It is not a different user and not a matter of order; it is the point at which continuing would turn the product into a member of a different category, with different users, a different competitive set and a different maintenance burden.

Depth boundaries are the easiest kind to describe well, because the category on the other side usually has a name. Acrosite is described as a structured editor rather than a code editor, and the repository and architecture it publishes into are left as they are. Both halves of that are depth boundaries: one names the category the editing surface is not becoming, and the other names the territory the product does not reach into. A reader who wants a code editor learns it in a sentence, and a reader who was worried about what a publishing tool might do to their repository learns something too.

The failure mode here is the incremental one. Nobody proposes building an entirely different category of tool. They propose one small escape hatch for the case that does not fit, and then another, and the boundary is gone by accumulation rather than by decision. Naming the category on the other side is what makes each individual escape hatch visible for what it is, because the question stops being whether this one exception is reasonable and becomes how far along the path to a different product it takes you.

Wrong business

The request is feasible, valuable to the user, and would commit you to an obligation you have not agreed to carry. An integration whose upstream you do not control and would have to track forever. A compliance surface that changes the questions every future buyer is entitled to ask. A support commitment that only shows up as a cost in the second year. This is the refusal that connects to the standing cost of a product, and it is the one most often lost, because the build is small and the obligation is invisible at the point of decision.

The sentence to write is about the obligation rather than the effort. Saying that something would be difficult invites a customer to argue that it would not be, and they may well be right. Saying that it would make you the system of record for something you are not prepared to be the system of record for is a position rather than an estimate, and it does not collapse the first time somebody offers to pay for the engineering time.

One rule runs through all four kinds. A non-goal describes what a product does not do today, and why. It never says never.

Never is a claim about a world you cannot see. Markets move, dependencies land, and the reason that made a boundary sensible can dissolve without anybody noticing the day it happens. When it does, a published never leaves you two bad options: hold a position you no longer believe, or reverse it and teach every reader that your stated positions are provisional. The first exception to a never is not one exception. It is a general devaluation of every other line on the list.

There is an opposite failure, and it is worth naming because the correction for one tends to produce the other. Today can be read as soon, which is worse than never, because it puts the reader in a waiting posture on the strength of something you did not actually say. A prospect who defers a decision on an implied timeline you never gave will hold you responsible for it anyway, and they will be describing your product to other people in the meantime.

The fix is not a hedge, and it is certainly not a date. The fix is the reason. A boundary with its reason attached carries its own expiry condition, and a reader can evaluate that condition themselves. If the stated reason is that a dependency does not exist, everyone can see what would have to change. If the stated reason is an obligation you decline to take on, the reader can see that no amount of time alters it by itself. The reason is what makes today an honest word rather than an evasive one, and it is the part most often left out, because inside the team the reason feels too obvious to write down.

A non-goal is only tested when somebody with a budget pushes on it, so that is the condition it should be written for. The internal version, which is usually one line in a bulleted list, almost never survives, because it was written among people who already agreed with it and therefore never needed the argument spelled out.

A durable one has four parts:

• The boundary, stated in the reader's language rather than your architecture's. If understanding the sentence requires knowing how your system is built, it will fail with the person it most needs to work on.
• The reason, in one sentence, phrased so that a reasonable person could disagree with it. A reason nobody could argue with is usually not a reason at all; it is a preference wearing formal clothes.
• What the product does instead. Every boundary implies a positive commitment on the other side of it, and stating that commitment is what turns a refusal into a description of intent.
• Where to go if this is a dealbreaker. Naming the alternative is not weakness. It is the fastest available resolution of a conversation that was never going to end in a sale.

The commonest bad version is a sentence about simplicity. We keep the product simple is not a reason; it is an aesthetic assertion, and it loses to any specific argument the moment one is made, because the customer's request is concrete and your defence is not. Compare a boundary such as the one Acrosite draws around its editing surface, where the category on the other side is named outright. A named category can be discussed, and a reader can decide for themselves whether they wanted that category. Simplicity can only be asserted, and asserting it repeatedly in meetings is exactly the loop publishing was supposed to end.

A useful test costs nothing. Hand the written non-goal to somebody in a customer-facing role who did not write it, and watch whether they add a sentence when they use it. If they do, that sentence is the part the reader actually needed, and it belongs in the published version. Anything a colleague has to improvise at the point of contact is a gap you have not closed; you have only moved it somewhere you cannot see it.

The same missing capability can be read two ways. A limitation is something you would fix if you could. A boundary is something you decided. Readers make this distinction constantly and mostly without noticing they are making it, and their verdict determines whether the rest of your list is credible.

Two things separate the readings. The first is whether a reason is attached, which is straightforward. The second is whether the rest of the product behaves as though the decision was deliberate. If a boundary says one thing and three adjacent surfaces half-implement the excluded behaviour, the reader concludes, correctly, that this is a limitation with a story attached. Consistency is what makes a stated decision believable, and no amount of careful wording repairs its absence.

The error runs in both directions. Dressing a genuine limitation as a boundary is the more damaging one, because it is discoverable: anybody who has used a product that has the capability knows exactly what it looks like when it is missing rather than declined. But under-claiming costs too. A real decision, published as though it were a shortcoming you regret, invites every customer to lobby for its reversal, and leaves your own team no ground to stand on when they do.

When something genuinely is a limitation, the honest form is available and it is not embarrassing. Not today, and here is what we would have to change to do it properly, is a sentence that respects the reader. It also has an advantage the dishonest version lacks: when you eventually do it, you have already told everybody what the work was, so the release explains itself.

Boundaries are rarely reversed. They are eroded, one approved exception at a time, and the erosion is nearly always invisible from the inside, because each individual exception was defensible on the day it was made. Nobody ever decided to abandon the position. They decided six small things that added up to abandoning it, across enough months that no single decision looked like the one that did it.

Drift has tells, and they are cheap to look for:

• A configuration flag whose name describes the use case you say you do not serve.
• A support answer that explains a workaround for something the product officially does not do, circulated internally often enough that it has become a standard reply.
• Documentation that still states the boundary while the release notes have quietly crossed it.
• Customer-facing colleagues who have stopped raising the boundary on calls, because raising it now produces an argument they cannot win with what is actually in the product.
• An internal disagreement about whether a specific request counts as the excluded thing. Ambiguity about whether something counts is usually evidence that the boundary has already moved and the words have not caught up.

The test itself is simple and slightly uncomfortable. Read your published non-goals as though you were a customer who believed them, then go looking in your own product for the evidence that contradicts each one. Where you find contradictions, exactly two responses are legitimate: remove the exception, or remove the non-goal and say that it changed. Keeping both is the option that quietly costs the most, because a boundary the product does not honour teaches everybody who notices that your published positions are decorative.

Run this on a schedule rather than on suspicion. By the time a boundary feels shaky enough to prompt a review, the erosion has generally been visible in the product for a while, and somebody outside the team has already noticed it and drawn their own conclusion about what your documentation is worth.

There is a lazy way to justify a boundary, and it is to attack the thing on the other side of it. We do not do that because it is bloat. We do not do that because those tools are stuffed with things nobody uses. It is satisfying to write, it plays well internally, and it costs more than it returns.

It costs three ways. You have insulted a class of buyer whose need is genuine, and some of them are in your market for the part you do serve. You have made a claim you will have to eat if the boundary ever moves, which turns an ordinary product change into an embarrassment. And you have attached the boundary to a judgement about taste rather than to a statement about fit, which is a much weaker foundation, because taste is arguable and fit is checkable.

The better form is unglamorous. That is a real need; it is not what this is for; here is the kind of tool that does serve it. Naming the alternative, even where the alternative competes with you, does more for the credibility of the whole list than any amount of argument, because a list that only ever concludes in your favour reads as marketing, and a list that occasionally sends people elsewhere reads as information.

This also protects the decision from being re-fought internally on the wrong grounds. If the published reason is that the category is bad, then every colleague who privately thinks the category is fine has an argument to make, and they will make it every time a deal is lost. If the published reason is that it is not what this product is for, the argument that remains is about strategy, which is a conversation worth having, rather than about taste, which is not.

A list that never changes is not disciplined; it is unmaintained. Boundaries are decisions taken under conditions, and conditions move. The question is which movements count, because the ones that feel most urgent are usually the ones that count least.

Conditions that genuinely justify retirement:

• The stated reason no longer holds. The dependency exists now, or the obligation you declined has become one you already carry for another reason and can therefore extend at little marginal cost.
• The pressure comes from retained customers rather than from prospects. People who bought and stayed are describing the product they use; prospects are describing a product they imagined before they had one.
• It can be built on the default path. If serving the request requires a second way through the product, the wrong-user refusal is still intact whatever else has changed.
• You can carry the standing cost, in support, in documentation and in the questions it makes every future buyer entitled to ask, for as long as the capability exists rather than for as long as the project runs.

Conditions that do not justify it, however loudly they present themselves: the sheer volume of requests, which measures reach rather than fit; a single large deal, which buys you a customer and sells you an obligation that outlives them; and a competitor shipping it, which tells you something about their strategy and nothing whatsoever about yours.

Retiring one in public has its own discipline. Say that it changed, say what changed, and resist the temptation to present the reversal as though it had been the plan all along. Some people chose you partly because of that boundary, and they are owed the news from you rather than from a release note they stumble on later. This is also the moment to be clear about what class of thing you have just committed to, because a capability, a service commitment and a product, a service or a feature carry very different obligations, and the retirement of a non-goal quietly picks one of them for you.

What follows is invented. The product does not exist, it is not any Zealsync product, and nothing in it describes anything Zealsync builds or intends to build. It is here because an abstract rule is easy to agree with and hard to apply, and the application is where the difficulty actually lives.

Imagine a hypothetical scheduling tool for small teams that publishes a weekly rota. Requests keep arriving for time tracking. The published non-goal might read:

This tool does not record hours worked. It plans who is scheduled; it does not keep a record of who actually worked. Hours worked are a payroll record with legal weight, and being the system of record for that is an obligation we are not taking on today. If you need timesheets, keep them in your payroll system and keep the rota here.

Now the objection, which arrives with money behind it. Our payroll provider wants a file of hours. You already hold the shifts. This is a small export, a day of work at most, and we will pay for it.

The objection is right about the export and wrong about the commitment, and the non-goal survives only because it was written about the second thing. Producing a file is genuinely small. Becoming the place those numbers come from is not. Once figures leave for payroll, every subsequent edit stops being an edit and becomes a correction. Corrections need a trail showing who changed what and when. A trail needs permissions, because not everybody who can move a shift should be able to alter a record that determines what someone is paid. Disputes then arrive at your support desk rather than at the payroll provider's, and you have acquired a class of question your team is not equipped to answer. None of that was in the day of work being offered.

Notice what the written version does that the meeting version could not. It gives the requester the reason rather than the refusal, so they can work out for themselves whether it applies to them. It tells anybody reading it later exactly which fact would have to change. And it holds its shape when repeated by somebody who was not in the room, which is the only property that finally matters, because the room is not where most of a product's boundaries get tested. The examples worth studying, whether on the products Zealsync builds or anywhere else, are the ones stated as a category rather than as a preference.

Publishing narrows the set of people who can plausibly buy from you. That is not a side effect to be minimised; it is the entire mechanism. A product that could be for anyone has to be explained to everyone, one conversation at a time, indefinitely.