Why We Don't Chase Every Feature Request We Get

The first time a customer emailed asking for a feature, we built it within the week. It felt like the right way to treat someone who'd taken the time to write in. A few requests later, we noticed something uncomfortable: the product had started to feel like it belonged to whoever had emailed most recently, not to anyone in particular.

That's the problem with saying yes by default. Each individual request is reasonable, and each one deserves a real answer. But a product is the sum of every yes you've given, and if you never sort the requests, the product drifts toward whatever the loudest users happened to need that month.

We've changed how we read feature requests. When someone writes in asking for a specific feature, they're describing a solution to a problem they have. The problem is real, and it's worth understanding. The proposed solution is one of several possible ones, and often not the best fit for the product as a whole.

So the first thing we do with a request is ask what the person was trying to get done when they hit the wall. A request for a CSV export on Sorted Nexus might really be a request to get invoice data into their accountant's software. Those lead to different features, and sometimes the right answer is something much smaller than what was asked for.

We run a request through a short set of questions. Does it solve a problem for many of our users, or for one? Does it fit what the product is already for, or does it pull the product toward being something else? And what would we have to keep maintaining forever if we said yes?

That last question does the most work. Every feature is a promise to maintain it, document it, test it, and keep it working through every future change. A feature that took two days to build can cost far more than that over a year. With two people running six products, we can't afford to accumulate promises we didn't deliberately choose to make.

Most of the requests we decline fall into a few patterns. Some are for something that would serve one customer's unusual workflow and nobody else's. Some would turn a focused tool into a general one, which is how simple products slowly become confusing ones. And some are for things that other tools already do well, where building our own version would just be a worse copy.

Declining isn't the same as ignoring. We write back, explain what we're not building and why, and where it makes sense, point to something that does solve their problem. Most people accept a clear no far more readily than a vague "we'll look into it" that never goes anywhere, and the clear answer is more honest.

There's a fairness angle to this that took us a while to see. When we build something for one vocal customer, we're spending the same limited time that every other customer is implicitly relying on us to spend on reliability, speed, and fixing bugs. Customers who never write in still depend on the product continuing to work.

A focused product is easier to keep dependable. The features that survive our filter tend to be the ones that make the core job easier for most people, which is what most subscribers are actually paying for.

We don't throw declined requests away. We keep a simple record of what people asked for and how often, because repetition is a signal. A request we hear once is an anecdote. The same request arriving from five unrelated customers over three months is a pattern, and patterns are what change our roadmap.

That record has changed our minds more than once. A few features we initially dismissed made it into products after the same need kept surfacing from different directions. The difference is that they got built because the evidence accumulated, not because one person asked loudly.

We see the same dynamic in the consulting work we take on. Teams build whatever the most recent stakeholder asked for, and a year later nobody can explain why the system works the way it does. Having a clear way to evaluate requests, and the willingness to turn some down, is one of the cheapest forms of technical discipline there is.

If your team is struggling with a backlog that keeps growing in every direction, our services page describes how we help with exactly that kind of prioritisation, and you're welcome to reach out through our contact page to talk it through.