When everyone wants a different feature, how do you decide what to build next?

Years ago at Citi, my manager introduced me to a feature prioritization framework that I've been adapting ever since. I use a version of it with early-stage teams today because it brings structure to a decision that can get surprisingly emotional.

At a startup, the problem usually isn't a lack of ideas. It's deciding which one deserves the team's limited time and engineering capacity. One customer wants better reporting; another is asking for a new workflow; sales has something that could help close a deal; the founder has ideas of their own.

They may all be reasonable, but they can't all come first.

Start with what matters right now

Before I look at individual features with a team, I want to understand what the business is actually trying to accomplish.

That sounds obvious, but it's often where the prioritization problem starts.

I typically narrow this to three to five priorities and weight them based on what matters most to the business right now. I've built versions of this tool where support and operational efficiency carried half the weight because that was the biggest pain point for the company at the time. For another team, onboarding and credibility with buyers mattered much more.

The "right" criteria are different for every company, and they will change as the company changes. The framework is nimble enough to evolve alongside the company.

Make the case for what you want to build

One of the biggest benefits of this framework is that it forces the team to get clearer about what they are actually asking the engineers to build.

A feature request often starts as a sentence: a customer wants better reporting, sales needs a particular capability to close a deal, or someone thinks the dashboard needs to work differently. But we first need to understand what that actually means. What would we build? Who would it help? What problem does it solve? And why does the person proposing it believe it will have an impact on the things we've agreed matter most?

That extra step of "scoring" the feature against the stated objectives helps flatten some of the emotion that naturally comes with prioritization. Someone can still advocate strongly for an idea, but enthusiasm alone isn't enough. They have to explain why it matters in terms the rest of the team can understand and evaluate.

This is also why I like to make prioritization a team exercise. The founder, product, engineering, sales, and operations may all see something different in the same feature. And depending on the company, there may be other perspectives that are critical, like legal or compliance.

When those perspectives produce very different rankings, that's valuable information. The gap may mean the feature isn't clear enough or someone has information the rest of the team doesn't. That disagreement is doing exactly what we want the framework to do: surfacing something the team needs to resolve before it builds.

Effort is part of the trade-off, not the answer

Once we've clarified the features and looked at their potential business value, engineering provides a rough estimate of the effort involved.

The important thing is not to confuse effort with value.

A high-effort feature isn't necessarily something you shouldn't build, just as a low-effort feature isn't necessarily worth building because it's easy.

At Citi, we had multiple engineering teams, so we had more flexibility to distribute the work. Early-stage companies usually don't. Choosing one substantial feature may mean consciously doing less elsewhere.

That is exactly the kind of trade-off I want the team to consider. A feature may still be important enough to justify the effort. Or the conversation may lead us to ask whether there is a smaller version that delivers most of the value, a different technical approach, or another way to solve the underlying problem.

The tool isn't really the point

I've shared versions of this framework with a number of teams over the years, and what they tend to appreciate most isn't the final order of the feature list. It's that the process gives everyone a common way to talk about what should come first.

Prioritization is never completely objective. There is judgment in deciding what matters to the business, estimating the value of a feature, and understanding the effort required to build it.

But it doesn't have to come down to the loudest person in the room, the customer who asked most recently, or the feature engineering can ship fastest.

A good framework makes the assumptions and trade-offs visible. It gives the team something concrete to react to, disagree with, and refine together.

And, in my experience, that conversation is where the real prioritization happens.