How to decide what to build next: product prioritization for small teams

Product prioritization is the order you do things in, plus the reason you can say out loud. Everything below is how to get that order without a meeting.

TL;DR

• Write down two or three bets for this quarter, in order. Every item sits under the bet it serves, or under none.
• Inside a bet: broken things first, then what customers asked for (counted by accounts and revenue), then ideas.
• Keep the evidence on every row: the customer's exact words, the account and what it pays.
• Frameworks like RICE are good tie-breakers and poor deciders. A person makes the call.
• When coding agents do the building, effort stops being the constraint. Deciding well becomes the whole job.

When to use this: when you have more than one place ideas arrive, more than one person with an opinion, or agents waiting for work. When not: if your whole list fits on a sticky note, just order it and write one line on why the top item is on top.

Why is deciding what to build harder now that agents build?

Because the slow part moved. A few years ago a small team was limited by how much it could build. A feature took a sprint, so the list sorted itself: you could only do three things a month, and arguing about the fourth felt academic.

Now Claude Code, Cursor, Codex and Grok can take a well-described job and finish it in an afternoon. Some jobs shrank from two weeks to two hours. That sounds like the end of prioritization. It is the opposite.

• More can ship, so more wrong things can ship. A feature built for nobody still has to be supported, documented and worked around in every later change. See feature creep.
• Agents need a clear next job. An agent that finishes in an hour asks "what next?" eight times a day. If the answer is a vague backlog, it will pick something, or sit idle.
• Agents find work too. While they build, they notice slow queries, flaky tests and confusing screens. Those findings are useful, and they land on the same list as customer requests.
• Customers did not get faster. A conversation still takes an hour, and a pattern still takes a few weeks of feedback to show.

So the question changed from "what can we fit in?" to "what is worth doing, and how do we know?" That is product prioritization now: less about capacity, more about evidence and direction. If you want the longer case for finding out before you build, read product discovery for a small team. If you came for the formulas, the prioritization frameworks guide has every one of them; this page is about the order.

Where do the ideas come from?

From four places. Name them, because each one fails in its own way.

Your customers

Support chats, sales calls, Slack channels, survey answers, emails to the founder. This is the richest source and the messiest. The same problem arrives in ten different wordings from six different people, and the loudest one is rarely the most important. Pull it into one place and group it before you count anything. The customer feedback hub covers collecting it, and feature request triage covers sorting it.

Your roadmap

The things you already promised: to a customer, to an investor, to yourself in a planning doc. These are real commitments and they belong on the same list, not in a separate one that nobody compares against the rest.

Your ideas

Yours and your team's. It is easy to feel your own ideas don't count unless a customer asked. They do. A good idea is how a product gets ahead of what customers know to ask for. It just has less evidence behind it today, so it ranks below what customers asked for until evidence shows up. Keep them all in one list; see idea management software.

What your agents find

This one is new. A coding agent working on one job often spots another: a query that takes eight seconds, an error message nobody can read, a test that fails one run in five. Treat a finding like a bug report from a very observant teammate. It needs a severity (how bad is it, really) and a person to confirm it.

What counts as evidence?

Evidence is what lets you explain a ranking to someone who disagrees with it. A feeling is a reason too, but it is not evidence, and it helps to know which one you are using.

Counts as evidence:

• The customer's exact words. "I export to a spreadsheet every Friday because I don't trust the totals" tells you far more than "wants better export."
• The account. Which company said it, how many people there, and what it pays you.
• Separate accounts. Five companies asking is stronger than one company asking five times.
• What they did. A workaround, a spreadsheet, a cancelled plan or a support ticket filed at 11pm is behavior. Behavior beats opinion.
• The date. Something said last week weighs more than something said last year.
• A severity a person confirmed. P0 means it fails or risks data, money or access. P1 means you can finish only with real friction.

Does not count, or counts for less:

• Vote counts on their own. Votes measure who showed up and clicked, not who needs it. See customer feedback prioritization.
• Mention counts. Ten messages from one account is one voice.
• A paraphrase. "Sales says enterprise wants SSO" is a lead, not evidence, until you have the customer's words.
• A score with no source. An impact of 8 that nobody can explain is a guess dressed up.

One habit makes all of this cheap: when something lands on the list, attach the quote and the account at that moment. Adding it later never happens.

Which prioritization frameworks are there, and how do they compare?

Most guides lead with frameworks. They are useful, mostly as a shared vocabulary and as tie-breakers. This page is the order; the frameworks guide is the formulas. Here is the compact version; the prioritization frameworks guide covers each one in depth, with who came up with it and when, plus weighted scoring and the rest.

Whatever you use, the output is usually a now, next and later roadmap: now is what is being built, next is the top of the ranked list, later is everything else. The ranking decides what moves from later to next.

For the one-line definitions, see RICE, MoSCoW, the Kano model and feature prioritization framework.

Why do formulas fall short for a small team?

They were built for a different problem: a product manager with a big team, months of usage data and a quarterly planning meeting. A four-person team with 40 customers runs into five walls.

1. The inputs are guesses. You don't have reach data for a feature that doesn't exist. An impact of 7 is a feeling with a number on it, and two people will give the same item a 3 and a 9.
2. Broken things don't fit. A bug that stops a paying customer from finishing their work is not a slightly higher score. It is a different kind of item. Putting it in the formula invites someone to argue it down.
3. The customer disappears. The score keeps the number and drops the words. Three months later nobody remembers that the "8" was one founder on one call.
4. Effort moved. Old effort estimates were made for people typing every line. With agents, some jobs shrank by ten times and some didn't shrink at all. A list ranked on last year's effort numbers is quietly wrong.
5. It hides the argument. The useful part of prioritizing is the disagreement, the "I think this matters more, and here is why." A formula can end that conversation before it starts, which feels efficient and isn't.

None of this means scoring is useless. It means a score should settle a tie between two items you already think are close, not decide the shape of the whole list.

What order settles most calls?

Four steps, in this order. Most items find their place by step 3, and you rarely reach the score.

1. Your bets

A bet is something you have decided to win this quarter, in one line: "new teams see their first report in week one." Write two or three, and put them in order. The order is the one ranking you set by hand, and it does the heaviest lifting. Work that serves bet 1 is read before work that serves bet 2. Work that serves no bet waits, however good it is. See bets and, for the bigger picture, product strategy.

2. What is broken

Inside a bet, if a person has marked something broken (P0 or P1), it goes first. A customer who can't finish the job is a bigger problem than any new feature. Severity describes how bad the problem is. Only a person confirms it, and a person's severity always wins over an agent's guess.

3. What customers asked for

Then the requests, ranked by how many separate accounts asked, then how much revenue sits behind them, then how urgent it is for them. Count companies, not messages. Keep their exact words on the row.

4. Ideas

Then ideas: yours, your team's and the useful findings from your agents. Ideas aren't second-class. They are early. When a customer starts describing the same thing, the idea gains evidence and moves up.

And a score, only for ties

If two items land in the same spot (same bet, same group, similar accounts), ask one question: what does a month of waiting cost? If that doesn't settle it, a quick impact times confidence over effort score will. Write down where each number came from.

This order is a default, not a lock. If something broken sits under bet 2 and it is hurting a customer today, move it. You are the one making the call. The order just means most days you don't have to.

What does that look like on a real list?

A hypothetical example. Say a four-person team sells reporting software to 40 small businesses. They have two bets this quarter, in this order:

• Bet 1: new teams see their first report in week one.
• Bet 2: accounts paying $500 a month or more renew.

Here are the ten items on their list, in the order they arrived:

Step 1: sort by bet

• Bet 1 (first report in week one): C, D, F, G, J.
• Bet 2 (big accounts renew): A, E, H.
• No bet: B, I.

Step 2: broken first, inside each bet

• Bet 1: C (P0) then J (P1).
• Bet 2: H (P1).

Step 3: then what customers asked for

• Bet 1: G, saved filters (5 accounts).
• Bet 2: A and E both have 4 accounts. Revenue breaks it: A ($2,400) above E ($1,200).

Step 4: then ideas

• Bet 1: D (founder's idea) and F (agent finding, P2). Neither has customer evidence yet. This is a tie, so this is where the score earns its place.

The tie-break

What does a month of waiting cost? Every new signup this month sees an empty workspace (D) and a slow first load (F). Both hurt the same bet. So score them:

• D, sample data: impact 7, confidence 5 (a hunch, no calls yet), effort 2 days. 7 x 5 / 2 = 17.5.
• F, slow dashboard: impact 5, confidence 8 (the agent measured it), effort half a day with an agent. 5 x 8 / 0.5 = 80.

F goes first. Notice why: not because it matters more, but because it is cheap and certain. With agents, small certain fixes often jump ahead of big uncertain ones. That's fine, as long as the big uncertain one gets tested next.

The final list

1. C: First report shows a blank chart (bet 1, broken)
2. J: CSV import fails on large files (bet 1, broken)
3. G: Saved filters (bet 1, 5 accounts)
4. F: Faster first dashboard load (bet 1, idea, won the tie)
5. D: Sample data in empty workspaces (bet 1, idea)
6. H: Invoice emails reach the right admin (bet 2, broken)
7. A: Bulk edit for reports (bet 2, 4 accounts, $2,400)
8. E: Google Sheets sync (bet 2, 4 accounts, $1,200)
9. B: Dark mode, parked: "9 accounts, serves no bet this quarter. Revisit at next planning."
10. I: Settings rewrite, parked: "No customer evidence. Bring back if setup complaints appear."

Two things stand out. Dark mode had the most accounts of anything on the list and still sits near the bottom, because it serves neither bet. That's not a judgment that dark mode is bad. It's the bets doing their job. And H is broken but ranks sixth, because it sits under bet 2. If an invoice going to the wrong person were costing a renewal this week, the founder would move it up, and that would be the right call.

Is there a prioritization template I can copy?

Yes. The prioritization template puts this order into a sheet: one row per item, with the bet it serves, whether it is broken, the evidence and the customer's words, then a tie-break score that is optional and comes last. Fill in the bet and the evidence first. If you find yourself filling in the score first, that is a sign the evidence is thin.

The template works for coding agents too. Give an agent the sheet and your bets, and it can propose where a new item belongs and why. You confirm.

How do I say no without a fight?

Most prioritization fights aren't about the item. They are about whether the person feels heard. A clear rule and a written reason do most of the work.

• Point at the rule, not your taste. "This doesn't serve either bet this quarter" is easier to hear than "I don't think it matters." The bets were agreed in advance, so you are not making it personal.
• Park, don't delete. Not now isn't never. Parking keeps the item and its evidence, so when the fifth customer asks, it is already there with four quotes on it.
• Write the reason for whoever reads it next. "Waiting on the new import flow" helps a teammate or an agent in three months. "Low priority" helps nobody.
• Say when you'll look again. A date or a trigger ("when 3 more accounts ask," "at next quarter's planning") turns a no into a not yet.
• Tell the customer. A short, honest no is kinder than a yes you won't keep. And when the item ships later, the person who asked should be the first to hear.
• Let evidence change your mind. If someone brings a new quote or a revenue number, the item moves. That is the system working, not you losing an argument.

The backlog post on prioritizing without a meeting goes further on keeping these calls out of long meetings.

How often should I re-rank?

Less often than you think for the shape, more often than you think for the rows.

A good weekly re-rank takes 15 minutes, not a meeting. Read the top ten. For each one, ask: is it still in the right bet, and did anything new arrive? Most weeks, two or three rows move and the rest hold. That is what continuous planning looks like for a small team.

A quick weekly checklist:

• Every new item has a bet, or is marked as serving none.
• Every broken item has a severity a person confirmed.
• Every customer request has at least one exact quote and an account.
• The top three each have a one-line reason a teammate could repeat.
• Nothing parked is missing its reason.
• Anything shipped last week has been told to the people who asked.

What changes when agents do the building?

The rules above hold. Five things shift underneath them.

Effort stops being the main filter

When a person typed every line, effort was a big input to the ranking. Now some jobs take an agent an afternoon. Re-estimate effort with the agent you would use before you trust an old score. Expect cheap fixes to move up, and big unclear features to stay where they are, because the hard part of those was never the typing.

The list becomes the instructions

An agent picks its next job from your list. So the list has to say what to do and why, in words an agent can act on. A row titled "improve export" will get built as something. A row titled "accounts can export last month's invoices in one click," with three customer quotes attached, will get built as the right thing. That written plan for a single job is the spec: the why, the evidence and the lines that say when it's done.

Agents add to the list

Agent findings are good evidence of what's slow or fragile, and weak evidence of what customers want. Rank them by the severity a person confirms. Keep them in the same list, so you compare them against customer requests instead of running two queues.

Speed punishes a wrong bet

If your bets are wrong, agents will build the wrong things very fast. This makes the quarterly bet review the most important hour of the quarter. It also makes talking to customers each week more valuable, not less.

Decisions need to stick

When five sessions are working in parallel, a decision you made in one chat is invisible to the other four. Write decisions down once, where every agent reads them: "we don't build per-user permissions until a customer over 20 seats asks." In a repo, that might go in AGENTS.md, the shared rules file several agents read. The point is the same: decide once, and every agent knows.

How does Annsa do it?

Annsa is the source of direction for your team and agents. It keeps the order on this page as one ranked list. A person makes the call.

• One list from four inputs: your customers, your roadmap, your ideas and what your agents find.
• Ranked inside your bets, in your order. What a person marked broken (P0 or P1) comes first, then what customers asked for, then ideas. Inside those: severity, how many accounts, revenue, then urgency. How often something was said is shown on the row and never sorted on.
• A person's severity always wins. Agents propose a severity with a reason. You confirm it or change it.
• Every priority keeps its evidence: the customer's exact words, the account and its revenue. Open any row to see why it sits where it does.
• You sign it: do this, do nothing, park it or dismiss it. Parking keeps the reason, and new feedback on the same problem still groups in.
• Agents read the same list. Claude Code, Cursor, Codex and Grok connect over MCP, claim the top job, read its spec and record evidence against each Done When line.

See Priorities for the screen, choosing what to build for how to read a row, and what to build next for the everyday version.