Every feature request that reaches a small product team sounds reasonable. Somebody took the time to write it. It describes a real situation. It usually ends with "it would only be a small change". Taken one at a time, almost none of them deserve a no.
That is the trap. The cost of a feature is never the feature. It is the feature plus everything it touches: the settings screen it needs, the documentation, the edge cases in the next release, the support questions, the slower onboarding for every new user who now has one more thing to understand. Forty reasonable requests, each accepted on its own merits, add up to a product nobody can explain in a sentence.
We are a small team, and we run six products of our own. One of the values we wrote down early was to choose simplicity over complexity. This post is about what that value costs in practice, and how we think about the requests we turn down.
The cost is the sum, not the item
When you evaluate a request in isolation, you are asking the wrong question. "Is this useful?" is nearly always yes. The better question is "what does the product look like after we have said yes to this and the nine requests like it?"
A useful exercise: write the request on a list with every other open request, then imagine all of them shipped. Look at the settings page. Look at the first-run experience. Count the concepts a new user has to hold in their head. If that imagined product is worse than what you have today, the request is not free.
Small teams feel this more sharply. There is no separate team to own the feature after launch; the people who built it will maintain it, document it and answer questions about it, and they were supposed to be building the next thing.
A real need and a loud one are not the same
The loudest request is not the most important one. Loud usually means one person feels strongly, or one person is good at writing emails. Neither tells you how many people share the need.
Some signs that point to a real need rather than a loud one:
- It arrives from different people who do not know each other, described in different words. Three unrelated users who each explain the same friction are worth more than one user who writes five times.
- The person describes the problem, not the solution. "I keep losing track of which invoices are overdue" is a need. "Add a red badge with a count" is one possible answer to it, and often not the best one.
- They already have a workaround. If somebody has built a spreadsheet to cover the gap, the gap is real. If nobody has bothered, it may not hurt as much as the email suggests.
- It sits on the path your product was built for. A request that helps people do the core thing better is different from one that asks the product to become something else.
A feature is not a fix
A lot of what arrives labelled "feature request" is really a bug report wearing a suit. The user cannot find the export button, so they ask for a new export screen. The form loses their input on a slow connection, so they ask for autosave.
This distinction matters because fixes and features go on different lists. A fix makes the existing promise true. It should almost always be done, and quickly. A feature extends the promise, and that deserves the slow, sceptical treatment described above.
Before adding anything, it is worth asking whether the request goes away if the current product simply worked as intended. Imagine a user asks for a "favourites" section because they cannot find things they used yesterday. The fix might be better search or a sensible recent-items list. The feature they asked for might never be needed.
Keep a "not now" list, not a "no" list
A flat no closes a door, and small teams do not know enough to close doors with confidence. A request that makes no sense this year may be obvious next year, once the product has moved and you have heard the same thing from thirty people instead of one.
So we prefer to keep a "not now" list. Every request that is not a fix and not a clear yes goes on it, with a line about who asked and why. The list is not a promise. It is a memory. When a new request arrives, the first thing to do is check whether it is already there, because a request that keeps returning from different directions is telling you something that a single email cannot.
The second-best product with a clear purpose wins
There is a kind of product that does everything anyone ever asked for. It has forty settings and three ways to do each task. Every one of those options was a yes to somebody. Together they are a no to everyone who arrives new.
Against that, a product that does one thing clearly and is second-best at a few details will usually be chosen, kept, and recommended. People can explain it to a colleague in a sentence. They can learn it in an afternoon. When something goes wrong, they can guess where to look.
The reason is not that simplicity is a virtue in the abstract. It is that a clear purpose is a feature that scales to every user, while a setting is a feature that serves only the people who find it. Every option you add is a small tax on everyone who did not ask for it.
How to say no without losing the customer
The way a no is delivered matters more than the no itself. Most people can accept that a small team has limits. What they cannot accept is being ignored, or being told yes and then hearing nothing.
A few things that help:
- Reply promptly, even if the answer is not yet. A fast, honest "not now" is kinder than a slow, vague "we'll look into it".
- Repeat their problem back in your own words. It shows you read it, and it often reveals that the underlying need is one you can meet a different way.
- Explain the reason briefly. Not a policy statement, one plain sentence: "We are keeping the product focused on X, and this pulls away from it."
- Offer what you can. A workaround, a related feature that exists already, or simply that the request is on the list and you will tell them if it changes.
- Never promise to placate. A yes you do not mean costs more trust later than an honest no costs today.
The customer who hears a clear, respectful no usually stays. The one who hears an insincere yes leaves quietly a few months later, and does not tell you why.
What we are really protecting
Saying no is not a sign that a team does not listen. It is the opposite. It is what listening to all of the users, including the ones who never write in, looks like in practice.
The thing being protected is the product's ability to be understood. A small team cannot afford a product that needs a manual, a training session, and a support desk to explain. The cheapest way to keep that from happening is to say no early, keep the reasons written down, and be honest with the people who asked.
