Feature Prioritization for Product Teams: Decide Before You Design

Take a typical backlog: 63 feature requests, and a founder asking which 1 to design first. 41 of them come from a single enterprise customer. 9 come from the sales team. 3 have any data behind them. The 1 already in development is the 1 the CEO saw in a competitor demo the week before.

That backlog is normal. Most product teams do not have a shortage of ideas, they have a shortage of a method for deciding between them, and a shortage of a scope once they decide. Design starts on a ticket with 1 line, and 3 weeks later the interface is built for a job nobody wrote down.

This post is how I do feature prioritization for product teams before any design starts: the 5 factor scoring method I use, the 1 page feature brief we write for every feature that passes, how I scope it in 1 day, and when I tell a team the answer is not a feature at all.

Why most feature backlogs are wish lists, not plans

A backlog written from requests measures who talks to you most, not what the product needs. Enterprise customers talk the most, because they have account managers. Sales talks second, because they lose deals and remember why. The 400 users who churned quietly in month 2 did not file a request.

The second problem is that requests arrive as solutions. "Add a Kanban view" is a solution. The job behind it might be "I cannot see what is blocked", and that job has 4 possible answers, of which a Kanban view is the most expensive. If I score the solution, the cheapest answer never gets scored.

So before any prioritization, I rewrite every request as a job. It takes about 2 hours for 60 items and it usually collapses the list by half or more, because 41 requests from 1 customer are typically 4 jobs asked 10 different ways.

Feature prioritization for product teams: the 5 factor scoring method

There are many scoring frameworks, and most of them fail in the same way: the effort column is guessed and the value column is a feeling. I use 5 factors, each scored 1 to 5, and I insist that 2 of them come from data and 1 from an engineer.

The score is reach + evidence + metric - effort - risk. A feature with a score of 8 or above goes to a brief. A feature between 4 and 7 waits for more evidence. Below 4 gets closed with a note, and the person who requested it gets told why.

2 rules make this work. The first is that reach comes from analytics and evidence from support, not from the loudest person in the room. If you cannot fill those 2 cells, the feature is not ready to score, it is ready for research. The second is that effort is estimated by an engineer on the job, not on the requested solution, because the requested solution is usually 3 times more expensive than the smallest thing that does the job.

Risk to existing flows is the factor most frameworks do not have, and it is the 1 I add as a designer. Every feature competes for the same navigation, the same settings page and the same first screen. A feature that scores well on value and quietly pushes the primary action of 80% of users 1 click deeper is a net loss, and nobody sees it in a spreadsheet.

A first pass you can do yourself

Before you bring in a designer, run this on your top 10 requests. It takes 1 afternoon.

Rewrite each request as a job in 1 sentence starting with "the user needs to", without naming a solution.
Merge requests that describe the same job. Expect the list to shrink by half.
For each job, pull 1 number from analytics: how many active users touched the related screen last month.
For each job, pull 3 support tickets or 3 quotes from calls. If you cannot find 3, mark it "research".
Ask 1 engineer for a rough size in weeks, on the job, not on the requested feature.
Ask what the feature would move, hide or break in the current interface.
Score, sort, and look at the top 3. If the top 3 surprise you, that is the method working.

How I scope a feature in 1 day

With the brief in hand, scoping is the first day of design work. I do 4 passes: the job, the entry points, the states and the edge cases. Most of the surprises are in the states. A ticket describes the success state, and a real feature screen has 6 to 9 states, each 1 a layout the engineers need to estimate.

The scoping day ends with a state list, a flow sketch and a revised size. Often the size on day 1 is bigger than the brief assumed, and the right move is to go back to the "not in scope" section and cut, not to stretch the timeline. Better to cut on day 1 than in week 3 when the interface is half built.

The full scoping process for mobile is in our post on designing new features for a mobile app. The passes are the same, the states and constraints differ.

Deciding between 3 features that all score well

Scoring narrows 60 requests to 5. It does not choose between the top 3, because at that point the scores are within 1 point of each other and the spreadsheet is false precision. This is where the decision is a product decision, and I use 3 questions.

Which 1 do we learn the most from?
A feature that tests a new assumption about who the user is teaches the team something even if it fails. A feature that adds a 4th export format teaches nothing.

Which 1 unblocks the next 2?
Some features are foundations: roles and permissions, a proper settings area, saved views. They score modestly on their own and make the next 5 features cheaper.

Which 1 can we ship and measure in 2 weeks?
If 2 features tie, the smaller 1 goes first, because 2 weeks of real data beats another 2 weeks of arguing. Shipping behind a flag to 10 percent of accounts is the fastest research a product team has.

Where AI tools help feature prioritization for product teams and where they do not

I use AI tools in 2 places in prioritization. Clustering 60 requests into jobs, which gives me a first grouping in 10 minutes that I then correct by hand. And summarising a few hundred support tickets into the 10 recurring problems with example quotes, which otherwise takes a full day.

Where they do not help is the scoring. An AI tool will happily produce a score for every feature, and every score will be invented, because the tool does not have your analytics, your engineer's estimate or your knowledge of what the feature breaks in the current navigation. The 2 factors that come from data and the 1 that comes from an engineer are the whole point of the method, and there is no shortcut for them.

Mistakes I see most often

Effort estimated by the person who wants the feature. It is always 1 week. It is never 1 week.

No "not in scope" section. The brief describes what the feature does, and then during design everyone adds 1 more thing, because nothing said they could not.

Treating the enterprise customer's list as the roadmap. 1 customer with 41 requests is 1 customer. If 8 of those requests match what 400 other users struggle with, score those 8 and close the other 33.

Skipping the measure step. The feature ships, the team moves on, and 6 months later nobody knows whether it worked. The metric in the brief is what makes the next prioritization better than this 1.

FAQ

What is a good method for feature prioritization for product teams?
Rewrite every request as a job, then score each job on reach, evidence, metric, effort and risk to existing flows. Reach and evidence must come from analytics and support, effort from an engineer. Features scoring 8 or above get a 1 page brief before design starts.

What is a feature brief?
A 1 page document written before design that states the job, the evidence, the metric, what is not in scope, entry points, states, edge cases, constraints, open questions and owners. It takes 2 to 3 hours and it is the document product, engineering and design all read.

How do I decide which feature to design next when several score the same?
Ask which 1 you learn the most from, which 1 unblocks the next 2 features, and which 1 you can ship and measure in 2 weeks. When 2 tie, the smaller 1 goes first.

How long does feature scoping take?
1 day for a feature that has a brief. The day produces a state list, a flow sketch and a revised size. When the size grows on day 1, the fix is to cut scope, not to extend the timeline.

Should the product designer be involved in feature prioritization?
Yes, for 1 factor: risk to existing flows. The designer is the person who knows what the new feature will move, hide or break in the navigation and the existing user flows, and that factor is missing from most scoring frameworks.

What should we do with feature requests we will not build?
Close them with a 1 line reason and tell the person who asked. A closed request with a reason is better for the relationship than a request that sits in a backlog for 2 years.

Working with us

We run the backlog review and scoring with product teams in 1 to 2 days, write the feature brief with your product owner in an afternoon, and scope and design the feature that wins in 3 to 5 days for a small 1 and 1 to 2 weeks for a medium 1. For teams that ship a feature every 2 weeks we do this continuously on a product design subscription, with a Monday queue review that is the scoring session.

We also say when the answer is not a feature. If your top 5 scored jobs are all versions of "I cannot find the thing", the problem is the information architecture, and we would start with a UX audit of the existing flows before designing anything new. And if your product has 200 users, you do not need a scoring method yet. Talk to 10 of them and build what 6 of them ask for.

If you have a backlog longer than 30 items and 1 feature you are not sure about, book a free 15 minute intro call and bring the list. We will tell you which 3 we would score first.