The Feature Request You Should Actually Build (And How to Tell)

You know how to say no to bad feature requests. You’ve learned to distinguish scope creep from core features. You’re protecting the boundaries of your product.

But now you’re in a different pickle: you have a dozen requests that all pass the test. They’re all for your app. They’re all reasonable. They’re all things your users actually want. But you can only build three of them.

Which three?

This is where most product decisions go wrong. Founders pick the ones that sound the most impressive, or the most profitable, or the ones that came from their most important customer. Sometimes they’re right. Usually they’re wrong.

The signals that matter

Signal 1: Unprompted repetition

If three separate users ask for the same thing without talking to each other, that’s a signal. They didn’t coordinate. They all just thought of it. If five users ask for it, that’s not a coincidence — that’s a genuine need.

The inverse is important: if one user asks and nobody else does, and you build it, you’ve now maintained a feature nobody else uses and that one user still might not be happy about (because you built it slightly wrong).

Count requests before you build. Not the ones from the loudest customer or your biggest client — count the unprompted repetition. Two or three independent users asking for the same thing is a much stronger signal than one important customer asking for five things.

Signal 2: The workaround matters

If you have users and they’re staying even though the feature is missing, they’ve found a workaround. Maybe they’re doing it outside your app. Maybe they’re doing it manually. Maybe they’re using another tool in parallel.

But they’re staying, which means they don’t need the feature to use your app. They need it to use your app better. That’s different from a blocker.

The features that matter most are the ones that prevent people from using your app at all. The features that are nice to have are the ones people work around.

Pay attention to which requests are blockers. Someone says “I can’t use this until you do X” vs. someone says “It would be great if you had X.” That distinction is gold.

Signal 3: The feature bundles with business model

Some features unlock entirely new ways to make money. “Invoice my customers” unlocks a business model where you charge for invoicing. “Export to Salesforce” unlocks integration revenue. “White-label for resellers” unlocks a partner channel.

But here’s the trick: you don’t know if those models will work until you’re already shipping. You can’t plan around them. You can only notice them after shipping and seeing if people actually use them.

The most successful feature additions are the ones where shipping the feature reveals a market you didn’t know existed. You built export. Turns out companies want to embed your export in their workflow. Now you have an integration story you didn’t plan.

Build features because your users need them. Then watch to see if your users need them in a way that creates new business. Don’t predict the business model first.

Signal 4: The ask for help

If a user asks you to build something, that’s a request. If a user asks if you could build something and offers to help test it, that’s different.

People who offer to help test are people who are invested in the outcome. They’ll use the feature carefully. They’ll report bugs. They’ll tell you if it actually solves their problem.

People who just request are people hoping you’ll magically build what they’re imagining. Sometimes you will. Often you won’t.

Build with the testers first. Everything else is secondary.

The temptation to build the prestige feature

Every product has one feature that, if you ship it, makes you sound more impressive. For scheduling apps, it’s integrating with Calendly. For task apps, it’s integrating with Slack. Everyone knows what those are. Everyone wants them.

Here’s the thing: everyone is also getting them from someone else. If your feature isn’t the best, easiest integration with Slack, it just adds complexity to your app without making you famous.

The features that make you famous are the ones you’re uniquely positioned to build because you understand your specific users’ problems better than anyone else. Those aren’t the prestige features. Those are the boring features that solve real problems for real people.

Slack integration is impressive. A tool that lets your users do one specific thing much faster than Slack ever thought about is valuable.

How to actually decide

When you have a batch of feature requests that all pass the “is this in scope?” test, rank them by:

1. How many users asked (independently)? More is better.
2. Is this a blocker or nice-to-have? Blockers are more urgent.
3. Can your users work around this today? If not, it’s more important.
4. Will someone help you test this? If yes, build it first.
5. Will this reveal a new market? If maybe, that’s a bonus, not a reason.

Then build in that order. Not the order of impressive-sounding. Not the order of your biggest customer. The order of actual signal from the people using your app.

The feature you won’t build (yet)

You’ll have requests that don’t make the cut. Don’t pretend you’ll build them someday. Tell the user: “We’re not building that right now. Here’s why. Here’s what we are building. Here’s an alternative that might work for you.”

That honesty matters more than you think. Users would rather know you’re not going to do it than wait six months hoping.

And sometimes, once you’ve said no, the user finds a workaround, or a different tool, or solves the problem a different way. That’s okay. You can’t be everything to everyone.

The products that win are the ones that do their job well and listen carefully to what users actually need, not the ones that try to be everything and end up being nothing.