How to say no to feature requests

The request is almost never the problem

When a customer asks for a feature, they have already done a piece of product design on your behalf, using an incomplete model of your product and about forty seconds of thought. The request is their first idea, not their requirement.

So there is one question that goes before everything else: what were you trying to do when you needed this?

The answers separate into three groups, and they need completely different responses:

The first case is the most common and the most valuable, because it means you can solve their problem today and improve the product for everyone who never asked. Every request that turns out to be a discoverability failure is a free usability study.

Triage: what is actually signal

The trap is responding to intensity. The person who writes three paragraphs and copies you on a follow-up feels urgent, but they are one customer with a strong personality, and building for them is how products become incoherent.

1. Count distinct customers, not messages. Three different people mentioning the same underlying problem in passing beats one person raising the same request five times.
2. Weight by whether they pay, and stay. A request from an engaged paying customer is worth more than one from someone on a trial who has logged in twice. Not because their money is better, but because they have more context.
3. Check it against who the product is for. A legitimate request from someone who is not your customer is still a no. Serving everyone is how you serve no one well.
4. Discount anything that arrived as a comparison. "Competitor X has this" is a statement about their anxiety, not about their workflow. Ask when they last needed it.
5. Prefer the boring request. The unglamorous thing several people work around quietly is usually worth more than the exciting thing one person is excited about.

The underlying discipline is the same one that governs early customer research: sort by frequency, not volume. What people do repeatedly matters; how loudly they said it once does not.

The script

Four parts, in this order, and short:

1. Name the problem back to them. "So when a client pays late, you are chasing it manually and losing track of which ones you have already chased." This is the part that makes the rest land, and it is the part most people skip.
2. Give the answer, first word clear. "I am not going to build that." Not "that is an interesting idea" and not "maybe down the line". A maybe is a no that wastes their time and yours.
3. One line of why, about the product not about you. "This is built for solo freelancers and that feature only makes sense with a team, so it would make the product worse for most of the people using it." Not "we are a small team and very busy".
4. Offer the nearest real thing. A workaround, a partial solution, an export they can use elsewhere, or an honest recommendation of a different product. Ending on something useful is what preserves the relationship.

The part founders find hardest is the clear no, because a maybe feels kinder in the moment. It is not. A maybe means the customer waits, checks back, and eventually concludes both that you will not build it and that you were not straight with them. You spent the goodwill and got nothing for it.

When it is your biggest customer

This is the genuinely hard case, and the honest answer is to convert the opinion into a transaction. Ask:

1. Would you pay for this specifically, on top of what you pay now?
2. Is this blocking you from using the product, or is it an improvement you would like?
3. If I built it in three months rather than three weeks, does that still work?

The answers resolve it almost every time. A customer who will pay, is genuinely blocked, and can wait has a requirement. A customer who goes quiet at the first question had a preference, and preferences from large customers are still preferences.

If you do build it, price it to include what you are actually taking on, which is not the build. It is supporting, documenting and maintaining that feature for as long as the product exists, including for every future customer who never wanted it.

The cost of yes

Every feature you ship is a permanent liability. It has to keep working through every future change, be explained in the interface, be supported when it breaks, and be carried by every user who has to scroll past it to reach the thing they came for.

That is why the accumulation of reasonable yeses produces the product everybody complains about:

User signs up, lands on a dashboard with 47 options, has no idea what to click first, and churns in a week.

via r/SaaS

Nobody built that dashboard on purpose. It is forty-seven individually defensible decisions to help a customer who asked. The compound interest on saying yes is paid by every user who arrives afterwards, and it is charged against the one thing that most determines whether they stay.

A clear point of view about what your product does not do is not rigidity. It is the thing that makes it possible for it to do something well, and customers recognise it as confidence rather than obstruction.

BigIdeasDB Research. (2026). How to say no to feature requests. BigIdeasDB. Retrieved from https://bigideasdb.com/guides/how-to-say-no-to-feature-requests