Feature Requests: How We Decide What Actually Gets Built

Every product with real users accumulates a feature request list faster than any team can build it, and the instinct to build whatever the loudest or most recent customer asked for is a reliable way to end up with a product that's a patchwork of everyone's individual preferences instead of a coherent whole.

The questions we actually ask about a request

• How many people are asking for this, versus how loudly is one person asking for it? Volume and volume of enthusiasm are different signals.
• What are they actually trying to accomplish, independent of the specific feature they described? The requested solution and the real underlying need are often different.
• Does this fit the direction the product is actually going, or is it a detour that happens to be easy to build this week?
• What's the cost of not building it — will these users actually leave, or is this a nice-to-have they'd forget about in a month?

Why saying no is part of the job

A product that says yes to every reasonable-sounding request ends up serving no one particularly well. The discipline of saying no to good ideas that aren't the right ideas right now is what keeps a roadmap coherent — the same discipline behind cutting scope in an MVP.

Not every good idea deserves to be built now. The question isn't whether it's a good idea — it's whether it's the best use of the next two weeks of engineering time.

The clients whose roadmaps we help shape most successfully are the ones willing to have this conversation explicitly, the same clear-eyed thinking we look for in a good discovery call — not the ones hoping to build everything eventually.