Publishing Your Non-Goals: How to Say No to Feature Requests

A prospect asks whether the product imports data from the system they are leaving. It does not, and it never will, because that import needs a mapping layer nobody on the team is willing to own for the next five years. The answer they get on the call is “not yet.” That sentence has just bought two more meetings, a trial that will not convert, and a cancellation in month five.

‘Not yet’ is the most expensive phrase in software sales, because it is a promise wearing the clothes of an answer. The alternative is a written list of product non-goals: the things you have decided not to build, published, with a reason attached to each one. It is an unglamorous document. It also does more qualifying work than most of the pages you paid a designer to make.

This piece covers how to write one, where to put it so it reaches the people who need it, and how to change your mind later without looking like a team that does not know what it is building. The writing is the easy part. The decision the writing forces is not, which is why so many products have a detailed roadmap and no non-goals at all.

What a product non-goal actually is

A product non-goal is a capability you have consciously decided not to build, stated in public, with a reason a stranger can evaluate. All three parts carry weight. Decided, not deferred. Public, not buried in an internal wiki page three people can find. Reasoned, so it reads as judgement rather than as a shrug.

Three things it is not

• Not a backlog item. A backlog item is work you intend to do and have not scheduled. A non-goal is work you have decided against. If it moves onto the roadmap the moment a large enough customer asks, it was always a backlog item and you should have said so.
• Not a limitation. A limitation is an accident of the current build, and it embarrasses you. A non-goal is deliberate and it survives the next three releases. Publishing your limitations as though they were choices is a trick that buyers see through on the first call.
• Not a swipe at a competitor. “We refuse to be as bloated as the other tool” is positioning copy, not a decision. A real non-goal costs you something. If the sentence only makes you look good, it belongs in an advert.

A test that takes ten seconds

Ask what happens if a customer offers to pay for it next quarter. If the honest answer is that you would build it, it is a roadmap item and it should be described that way. If the honest answer is that you would turn the money down, and you can say why in one sentence a buyer would accept, you have a non-goal. Anything between those two is a decision you have not made yet, and publishing it will not make it for you. Most teams discover, doing this exercise for the first time, that roughly half their confident refusals are undecided.

What ‘not yet’ actually costs

Three groups hear that phrase and all three hear something different, none of it what you meant.

The prospect hears a date. Not a specific one, but a shape: soon, probably this year, likely before renewal. They buy on that shape and then measure you against it. Your own team hears permission, and once the phrase has appeared in the CRM a few times the feature drifts onto the roadmap by attrition rather than by anyone choosing it. Support hears an obligation and starts building workarounds, so the thing you never shipped now has maintenance costs. Every feature you do ship carries a standing cost for as long as it exists; the ones you almost ship carry a smaller version of the same bill.

There is a second cost that is harder to see on any dashboard. A product that has not decided what it refuses has not really decided what it is. Pricing turns defensive, because every tier has to hedge against a use case nobody has ruled out. Onboarding turns generic, because no one can say which job to lead with. Our parent company set out the underlying distinction in product, service or feature, and the answer to that question governs what you are allowed to refuse without sounding evasive.

How to write product non-goals

The document is short. Six to ten entries for most products, two or three sentences each. Longer than that and it stops reading as a set of decisions and starts reading as a wall of apology.

Start with the arguments you keep having

Do not start from a blank page and imagine what you might one day refuse. Start from the record. Pull the last fifty feature requests out of support tickets, sales notes and the internal channel where people paste screenshots at each other. Group them until the duplicates collapse. Sort by how many times the same conversation has been had. The top of that list is your non-goals document, already written for you by other people.

The repeat requests are the ones worth deciding, because they are already costing you time nobody is counting: the same objection handled from scratch by a different person every month, with a slightly different answer each time. Consistency is worth more here than eloquence. Five people giving the same plain no beats one person giving a beautiful one.

Write the reason, not the refusal

A refusal without a reason reads as arrogance. A reason without a refusal reads as a hedge. You need both, in that order: the decision first, then the sentence that makes it defensible to someone who wanted a different answer.

There are only a handful of honest reasons, and it helps to name which one is yours. The capability belongs to a different category of tool, and doing it badly would be worse than not doing it. The maintenance falls on every customer while the benefit falls on a few, which is the recurring bill described in the standing cost of a product. It would require data you have decided not to collect. Or it would make the product harder to use for the people it is genuinely for. Each of those is a sentence a buyer can weigh. “It is not a priority right now” is not a reason; it is a calendar observation.

1. List the repeat requests. Fifty raw requests is enough. Group them until you have ten to fifteen distinct asks with counts beside them.
2. Mark each one decided or undecided. Undecided is an allowed answer. It simply cannot be published as a non-goal, and pretending otherwise is how the list loses its authority.
3. Write one reason per decided item. One sentence. If it takes a paragraph to justify, the decision is shakier than the team believes.
4. Name what to do instead. Every entry should point somewhere: an integration, an export, a partner, a category of tool. A refusal with a route attached rarely loses a deal you wanted to win.
5. Ask sales and support to break it. They will tell you which entries they have been quietly contradicting for a year, which is the single most useful hour in this whole exercise.
6. Date it, then publish it. An undated policy document is treated as stale on sight, and readers discount everything on the page accordingly.

Where to publish it

A non-goals list that lives in an internal document changes nothing except the mood of the people who wrote it. It has to reach a buyer before they book a call, and a customer before they build a process on an assumption. Different placements reach different people and prevent different failures, so pick more than one.

The public page is the one that does the most work and the one teams resist hardest. Put it on the site as visible prose rather than folded inside an accordion that a hurried reader skips. Write it for the person deciding whether to trial you, which is also what search guidance on people-first content asks for, and the two goals stop competing. If you add structured data, describe only the answers a visitor can actually read on the page.

Tone matters more here than anywhere else on the site, because a refusal read in the wrong register sounds like contempt. This is ordinary messaging work, and it deserves the same care as the pages that say yes. The discipline that keeps a landing page selling the job rather than the tool applies in reverse: name the job you have decided not to do.

There is a bonus effect worth knowing about. When your category is unfamiliar, a non-goals page explains the product by negation, which is often faster than explaining it directly. Teams working out how to market something nobody is searching for yet frequently find that the sentence “this is not a replacement for X” lands harder than three paragraphs of description.

The buyers you want to lose

Here is the part that makes founders uncomfortable. A non-goals page is a filter, and filters remove things. Some of those things are deals.

That is the point of it. The buyer who reads that you will never build the thing they need, and quietly leaves, was going to leave anyway. The only variables were when, and how much of your team went with them. A trial that collapses in week three costs a demo, an onboarding session, a support thread, an internal champion’s credibility and a cancellation conversation. A page read on a Tuesday afternoon costs nothing at all. The cheapest churn is the customer who never signs up.

This is why non-goals belong in the same conversation as your trial model. Whether you run a free trial or a freemium tier changes how early the filter has to fire. A freemium tier lets a wrong-fit user settle in for months before they hit the wall, so the refusal needs to be visible before signup rather than during onboarding. Teams focused on conversion work usually measure the rate and not the fit, and those two numbers can move in opposite directions quite happily for a couple of quarters.

A non-goal that has never cost you a deal is not a non-goal. It is a sentence about focus.

Revising a non-goal without looking indecisive

The objection to publishing any of this is always the same: what happens when we change our minds. You will change your minds. Products that never reverse a decision are not disciplined, they are asleep.

What makes a reversal look bad is not the reversal. It is the silent edit. A buyer who was told no in March and finds the page quietly rewritten in July does not conclude that you learned something. They conclude that the page was never load-bearing, and that everything else on your site is negotiable too.

Three reasons that survive scrutiny

• The reason expired. You refused because it needed data you would not collect, and now the platform supplies the same result without that data. Say exactly that, and the reversal reads as consistency rather than drift.
• The category moved. What was a separate product two years ago is now a field every buyer expects. Admitting that reads as attention, provided you say what changed rather than pretending you always meant to.
• You were wrong. The plainest version is the strongest. You believed a small group wanted it and it turned out to be most of them. Write that sentence, keep it short, and move on.

What does not survive scrutiny is a reversal that lands on the same day as a large contract with no other explanation offered. If that is what happened, the honest framing is that a customer funded the work, which is a perfectly legitimate way to build software and an illegitimate thing to hide.

Mechanically, keep the history. Date every entry, leave the superseded wording visible with a note saying when it changed, and let the change log carry the reason. That is far easier when the page is a file under version control than when it is a field somebody edits in place. A structured content workspace such as Acrosite takes that approach: the edit becomes a commit in the repository and the configured deployment runs from there, so the document has a history whether or not anyone remembers to write one.

What it settles inside the company

The external case is the one people argue about. The internal case is the one that changes your week.

Three arguments end once the list exists. The roadmap meeting stops relitigating the same four requests every quarter, because each of them now has a date and a reason attached, and reopening one requires new information rather than renewed enthusiasm. Escalations get shorter, because a rep holding a written answer does not need a founder on the call to be believed. And scope creep during product improvement work loses its favourite excuse, since “while we are in there anyway” now runs into a decision somebody already made in public.

There is a hiring effect too, which nobody plans for and everybody notices. A candidate who reads what you refuse to build learns more about how you work than any careers page will tell them. Opinionated products attract people who want to hold an opinion, and repel the ones who would rather be handed a ticket.

Now the honest limitation. A published non-goals list is a bad idea early. A product still looking for its shape does not have decisions, it has guesses, and publishing guesses as principles hands you something to defend at exactly the moment you should be free to move. If you are still launching software nobody is waiting for, keep the list internal and dated, and publish the entries that survive a few months of real pressure. The opposite failure is just as real: a team that hides behind the list, refusing to think because the thinking was done once in a room that no longer exists. A good non-goals document should be uncomfortable to defend at least once a year.

Where we would start

One afternoon, and the order matters more than the effort. Open the support queue and the sales notes, and write down every request that has come up more than twice this year. Beside each one write yes, no, or undecided. Then take the no column to whoever answers the phone and ask them, item by item, whether they have actually been saying no. The gap between those two lists is the most useful document your product team will read this quarter, and it exists before you publish anything at all.

Publish when the no column stops changing week to week. Start with three entries rather than ten, because three defended properly beats ten hedged. Put them on a real page, link it from pricing and from onboarding, hand sales the same wording, and check in ninety days whether the answers have started to drift between people again. If they have, the reasons were never as settled as the page claimed.

The whole thing only works if the reasons are real. A list of non-goals invented to sound focused reads exactly like one, and any buyer paying attention will test it in the first ten minutes of a call. If you want a second opinion on which of your refusals are decisions and which are still arguments, tell us what you keep getting asked. The pattern inside those requests usually describes what the product is becoming more accurately than the roadmap does.