Every feature request comes from a real person with a real problem, and saying no feels like rejecting them. It isn’t — you’re rejecting one proposed solution. Conflating the two is how founders end up with bloated products built to please the last person who complained.

Separate the problem from the request

A request is a proposed fix, not the actual need. “Can you add CSV export” is a request. The actual need might be “I want to see my data in a spreadsheet to send to my accountant” — which might already be solvable a different way, or might reveal that ten other people want the same underlying thing through a request that sounds nothing like CSV export.

Ask one question before answering: “What are you trying to do with that?” Half the time the answer changes what you build, if you build anything.

flowchart TD
    A["Feature request comes in"] --> B["Ask: what are you trying to do?"]
    B --> C{"3+ unrelated customers asked\nfor this in the past month?"}
    C -->|No| D["Use the response template: say no"]
    C -->|Yes| E["It's a pattern — move it up the roadmap"]
  

The response template

Use this shape every time:

1. Acknowledge the problem, specifically. “Sounds like you need a clean export you can hand to your accountant.”
2. Say no to the literal ask, plainly. “We’re not going to add a CSV export in the near term.”
3. Give the real reason. “It’s a narrow use case and we’d rather put the next two weeks into fixing sync reliability, which affects everyone.”
4. Offer the workaround, if one exists. “You can pull the numbers from the API right now — here’s a five-line script that does it.”
5. Leave the door open, honestly. “If this comes up from a few more people, it moves up the list.”

Don’t skip step 3. “No” without a reason reads as dismissive. “No, because X” reads as a decision, which people respect even when they don’t like it.

What kills trust

• Saying “maybe” to avoid the conversation. Maybe is worse than no — it costs the customer nothing to keep asking, and costs you a mental tab that never closes.
• Promising a timeline you’re not committing to. “We’ll look into it” with no plan is a lie by omission.
• Building it anyway, quietly, because you felt bad. Now you’ve shipped for one loud customer instead of your roadmap, and you’ll do it again next time someone pushes.

When to say yes instead

If three unrelated customers ask for versions of the same thing within a month, that’s not a one-off request, that’s a pattern, and the answer flips. Track requests somewhere simple, even a spreadsheet with a tally column. The moment you’re saying no to the same underlying need for the fourth time, you’re not protecting focus anymore, you’re ignoring data.

The keep-the-customer part

Customers rarely leave over a “no.” They leave over being ignored, or being told yes and getting nothing. A clear, reasoned no, with a workaround if you have one, usually earns more trust than a vague yes, because it proves you have a plan and aren’t just improvising to whoever emailed last.

---