How to Decide What Features to Build Next (and What to Cut)
Build the feature that helps the most people do the one thing your product exists for, and cut everything that only helps a few people do something else. That’s the whole decision. The hard part isn’t knowing the rule. It’s having the discipline to follow it when a shiny new idea shows up and your brain screams “just add it.”
You’re going to feel the pull to build more. A user asks for a dark mode. Your co-founder wants a leaderboard. You watched a startup on TikTok add AI and now you want AI too. Every one of these feels like progress. Most of them are quietly stretching your product thinner and pushing your launch further away.
Why do founders keep adding features they don’t need?
Adding features feels productive, and it’s more fun than the boring work of getting people to use what you already built. That’s the trap. Building a new feature is pure creative energy: you sketch it, you code it, you feel like a founder. Meanwhile, doing customer interviews or writing launch copy feels like a chore. So you reach for the feature. The word for this is feature creep: your product slowly swells with stuff nobody asked for until it’s bloated, confusing, and still not launched.
Here’s the part people miss. Every feature you add has a cost that shows up later, not now. More features mean more things that can break, more buttons that confuse new users, and more time before you ship. A high schooler building on nights and weekends can’t afford that. Your real constraint isn’t ideas. It’s hours. Every hour spent on a feature two users wanted is an hour not spent on the thing all your users actually need.
If you catch yourself constantly wanting to build the next new thing instead of finishing the current one, read why good ideas are killing your startup first. Feature creep is that same disease pointed at a single product.
Start from the one job your product does
Before you can prioritize anything, you need one sentence: what is the single job your product does for people? Not five jobs. One.
Say you’re building a tool that helps students find quiet study spots on campus. The one job is “find a quiet place to study, right now.” That sentence is your filter. A feature that makes finding a spot faster or more reliable is in. A feature that lets people rate the coffee at each spot, or chat with other students, or earn badges? That’s a different job. It might be a good idea someday. It is not this product’s job today. If you don’t have that sentence yet, go write your startup one-liner before you write another line of code.
Almost every “should I build this?” question answers itself once you’re honest about the one job. The feature either serves it or it doesn’t. Most of your ideas serve a different job you’ve quietly invented in your head.
A simple way to score any feature
When two features both seem worth building and you can only do one, stop arguing with yourself and score them. Rate each idea 1 to 5 on three things:
- Reach: how many of your users does this touch? A feature all 100 users hit beats one that helps 6.
- Impact: for the people it touches, how much better does their experience get? A tiny nice-to-have is a 1. Something that makes them stay is a 5.
- Effort: how many hours will it actually take you to build, honestly, including the parts that always go wrong? Here, low is better, so a fast build scores 5 and a two-week slog scores 1.
Add the three numbers. Build the highest score first. Here’s what that looks like for the study-spots app:
| Feature | Reach | Impact | Effort (5 = fast) | Total |
|---|---|---|---|---|
| Live “how full is it” indicator | 5 | 5 | 3 | 13 |
| Search spots by “has outlets” | 4 | 4 | 4 | 12 |
| Dark mode | 3 | 1 | 3 | 7 |
| Study-buddy chat | 2 | 3 | 1 | 6 |
The scoring doesn’t make the decision for you, but it drags your gut feeling into the open where you can argue with it. Dark mode felt important because you personally wanted it. On the board, it’s near the bottom. The chat feature felt exciting because it was new. It’s dead last because it’s a huge build that helps almost nobody find a study spot faster.
How do I know if I should cut a feature?
Cut a feature when it fails one of these three tests. Run each idea through them in order and stop at the first “no.”
- Does it serve the one job? If it belongs to a different job you invented, cut it. Save it in a “later” note and move on.
- Would real users notice if it vanished? Not “would it be nice.” Would anyone actually complain? If you can’t name a specific person who’d miss it, cut it.
- Is it worth the hours right now, before launch? Even a good feature can be the wrong feature this week. Polish and extras come after you’ve proven people want the core thing.
The tests that trip people up are two and three. You will convince yourself that everything would be missed and everything is worth it right now, because you’re emotionally attached to your own ideas. The fix is to stop guessing and go ask. Real signal beats your opinion every time, and the fastest way to get it is talking to actual users. Ask them what they’re trying to do and where they get stuck. They’ll tell you which features matter and which ones you dreamed up alone at midnight.
One warning: don’t confuse “a loud user asked for it” with “users need it.” One person emailing you for a feature is not a roadmap. Look for the same request from several people, or a request that clearly serves the one job. A single loud voice can pull your whole product off course if you let it.
Keep a “not now” list instead of saying no forever
Cutting a feature feels like killing it, which is why founders resist. So don’t kill it. Park it. Keep one document called “not now” and drop every cut idea in there with a note on why. This does two things. It gets the idea out of your head so it stops nagging you, and it lets you say a soft no instead of a hard one, which is easier to actually do.
When you finish your current priority, open the list and re-score the top ideas. Half of them won’t feel important anymore, which tells you they were never worth building. The ones that still matter, and that real users keep asking about, rise to the top on their own. Your roadmap basically writes itself if you’re honest in the scoring and patient enough to wait.
This is the exact muscle we drill in the Build sprint at batch0. You’ve got one week to turn a validated idea into something real, and one week is brutally clarifying. There’s no time to build the study-buddy chat. You build the one thing that makes the product work, ship it, and everything else goes on the “not now” list where it belongs. If that kind of forced focus sounds like what you need, applying is free and you only pay if you get in.
The takeaway
Your instinct will always be to add. More features feel like more progress, and building is more fun than finishing. Fight that instinct with a boring, repeatable process: name the one job, score by reach, impact, and effort, and run every idea through the three cut tests before it touches your codebase. Then let real users, not your own excitement, decide what’s next.
The founders who ship something people use aren’t the ones with the most features. They’re the ones who cut the hardest and finished the one thing that mattered. When your product does one job well, you can launch it for real instead of tinkering forever on a product nobody’s seen.