Deciding What to Build Next

Startups are default dead. The thing that kills them most often is not running out of money directly. They run out of money because they run out of time. And they run out of time because they spend it building the wrong things.

The pressure to build is immense. Customers ask for features. Investors want to see progress. Competitors launch something new. Your own team has a hundred ideas. The temptation is to do more. To add one more feature one more integration or one more setting. This is almost always a mistake.

More features mean more code more complexity and more things to break. Each new feature is a tax on your future development speed. The best startups are not the ones with the most features. They are the ones that have most viciously focused on solving one problem exceptionally well. Everything else is a distraction.

So how do you decide what to build and what to ignore? You need a filter. A simple set of questions that you can apply to every idea no matter how exciting it seems.

The Illusion of More

Before we get to the filter you have to internalize one truth. Adding features does not add value by default. It often subtracts value by making the product harder to understand and use.

Think of your product as a sharp knife. Its purpose is to cut one thing perfectly. If you start adding a screwdriver a bottle opener and a magnifying glass it is no longer a great knife. It is a mediocre multi tool. Early on you need to be a great knife.

Your goal is not to build a product that does everything. Your goal is to build a product that a small group of users absolutely loves for doing one thing. Once you have that you have a foundation. Until you have that you have nothing.

Every feature you build should be a step toward making that core thing better for those core users.

A Three Question Framework

When you have an idea for a new feature run it through these three questions. If it fails any one of them you should probably not build it. At least not right now.

1. Does it solve a top 3 user problem?
2. How small can we make the first version?
3. What will we learn from shipping it?

Let’s look at each one.

The first question is about focus. You cannot solve every user problem at once. You have to be ruthless. What are the most painful problems your target users face? Not annoyances but real hair on fire problems. You should know these because you should be talking to your users constantly. If you don’t know the top three problems stop everything and go find out. Any feature that doesn’t directly address one of these is a distraction.

The second question is about speed and effort. Your most limited resource is time. The bigger a feature is the more time it consumes and the more risk it carries. The question is not “what would the perfect version of this feature look like?”. The question is “what is the absolute smallest thing we can build to test our hypothesis?”. Can you deliver 80 percent of the value with 20 percent of the work? A feature that takes three months is a huge bet. A feature that takes three days is an experiment. Early on you want to be running experiments not placing huge bets.

The third question is about learning. The other purpose of building things early on is to reduce uncertainty. You have a set of hypotheses about your users your market and your product. Every feature you ship should be designed to test one of those hypotheses. Shipping a feature and having users not engage with it is not a failure if you learn something important. For example you might learn that users don’t actually care about the problem you thought they had. That is an incredibly valuable lesson. It saves you from building more things they don’t want.

Putting It to Practice

Let’s make this concrete. Imagine you run a project management tool for small teams. Your users love it for its simplicity. You have two feature ideas on your list.

Feature A: Customizable User Avatars Feature B: The Ability to Assign a Task to Multiple People

Let’s run them through the framework.

Feature A: Customizable User Avatars

• Solves a top 3 user problem? No. Users have never mentioned this. It’s a “nice to have” that an engineer thought would be cool. It fails the first question immediately. We can stop here. Don’t build it.

Feature B: Assigning a Task to Multiple People

• Solves a top 3 user problem? Yes. Your top user request is “How can two people be responsible for one task?”. It’s a constant point of friction. It passes question one.
• How small can we make it? The perfect version might have complex permissions and notifications. But the smallest version? Just allow the “assignee” field to accept more than one user. No UI changes beyond that for now. This seems like it could be a one week project. It passes question two.
• What will we learn? We will learn if joint ownership of tasks actually solves the collaboration problem users are describing. We’ll see if it creates confusion or clarity. This will inform our entire collaboration model going forward. It passes question three.

The decision is obvious. You build Feature B and ruthlessly ignore Feature A.

What to Ignore

This framework helps you say yes to the right things. Just as importantly it gives you a clear reason to say no to the wrong things.

You should almost always ignore:

• Features to achieve competitor parity. Playing catch up is a losing game.
• Requests from a single large customer that don’t apply to your other users.
• Ideas that are cool from a technology perspective but don’t solve a user problem.
• Anything that would take more than a month to build an initial version of. The risk is too high.

Your job as a founder is to protect your team’s focus. A simple framework is your best tool for that. It turns vague debates into clear decisions. It helps you build a product that matters instead of a product that is merely busy.

— Rishi Banerjee
September 2025