Prioritization

Once a team starts collecting candidates, the list only grows in one direction. Customers ask for things. Sales writes down what a deal supposedly depends on. Engineers add the parts that need repair. The founder adds whatever a competitor shipped last week. Nobody deletes. Six months in there are forty items, and a quarter has room for six.

When there is no rule for ordering them, something else fills the gap — usually volume and recency. Sofia says in a meeting that a deal is lost without a particular feature, and that feature jumps to the top. The next week Grace comes back from looking at another company's product and says something similar, and that jumps to the top instead. Last week's top item slides to second place, and the half-written code from that week stops where it is.

Teams in this state end a quarter the same way. Two features finished, four half-built. Every one of them had a good reason to start and a good reason to stall. The trouble is that the hours spent across all six add up to far more than the two finished features are worth.

The harder moment comes when the choices have to be explained. Pick six out of forty and the remaining thirty-four each belong to someone who asked, and that someone wants to know why theirs is not in. "Next time" is not an answer, because both sides know the same thing will happen next quarter. An order with no stated grounds costs more time to defend than it did to set.

The thirty-four are not even the same kind of thing. Some of them mean customers leave if they're missing. Some mean one more deal closes. Some cost three times as much to fix six months from now. Line those three up in a single list and read from the top, and the first thing that stalls is deciding what the comparison is even measuring.

Prioritization exists to move that reasoning into the open. Writing down which few axes the choice was made on changes two things. The same basis works again next quarter, and the person whose item was cut can be shown what it fell short on. Judgment doesn't disappear — it moves from the mood of the room into the cells of a table.

The terms under prioritization fall into two groups: the frameworks used to order the candidates, and the concepts that supply the values those frameworks put in their cells.

Whichever framework a team picks, the sequence of work is much the same.

1. Collect the candidates in one place. Comparison is impossible while they're scattered, so something like a product backlog has to exist first.
2. Level the units of comparison. Rewriting a button label and replacing the payment system do not belong in the same table; any framework will return nonsense if they are. Keep day-sized and month-sized work in separate passes.
3. Choose the axes — this is where one of the seven below gets picked. If the team already uses one, keeping it usually beats switching, because a new framework makes this quarter's scores impossible to line up against last quarter's.
4. Score each candidate. Not alone: product, engineering and sales sit down together. The people who build the thing supply the effort number, and whoever can read the data supplies the reach.
5. Filter the resulting order rather than executing it. Something always has to move up regardless of score — a date written into a contract, a legal obligation, work that can't start until something else finishes.
6. Record what was cut. A single line on why each item is not happening this quarter means the same debate doesn't restart from zero next quarter.

Frameworks divide by what they use as axes, and there are seven.

1. RICE — multiply reach, impact and confidence, then divide by effort. A candidate reaching 2,000 people a quarter, with moderate impact, decent evidence and three person-months of work, scores 2,000 × 2 × 0.8 ÷ 3, or about 1,067. The number means nothing by itself; it means something once the candidate next to it, scored the same way, comes out at 240. Four axes make it the most laborious of the set, and also the easiest to argue with axis by axis.
2. ICE — score impact, confidence and ease from 1 to 10 and multiply. It's RICE with reach dropped and effort inverted, light enough to finish ten candidates in half an hour. The scale means different things to different people, so it works best when the same group scores in one sitting.
3. MoSCoW — grades instead of scores: must, should, could, won't. It draws a boundary rather than a queue, which suits a project whose ship date is already fixed and whose real question is what has to exist by then. If "must" covers more than half the list, the grading is wrong.
4. Value-effort matrix — effort along one axis, value along the other, candidates stuck into quadrants. No arithmetic, so a whiteboard and sticky notes finish it in half an hour, and the high-value low-effort corner becomes visible immediately. It isn't precise, which is why it works as a first pass that clears the obvious.
5. WSJF — divide cost of delay by job size. It pulls short, expensive items forward, which is what a large program spanning several teams needs when the question is sequence rather than selection.
6. Kano model — sorts features into must-be, performance and delight quality, and relates each to satisfaction. It separates things nobody notices when present but everybody complains about when absent, like autosave, from things that are pleasant extras. Skip the first category and no score on any other axis will save the product.
7. Opportunity scoring — asks users separately how important something is and how satisfied they currently are, then looks for high importance paired with low satisfaction. The other six rank candidates that already exist; this one tells you what is missing from the list.

The concept group holds the values that go into those cells, and right now it holds one. Cost of delay is what a month of waiting costs, expressed in money — the deal a competitor takes first, the monthly wage bill for work still being done by hand. Getting the figure exactly right is hard, but order flips on relative size alone. If one item loses roughly 800,000 won a month while another has two contracts riding on each quarter, the difference in magnitude settles the sequence. The group is thin because most other inputs borrow definitions that already exist on the metrics or finance side.

One question sits underneath the choice of framework: how much precision the decision actually deserves. A quarter's worth of work for one team rarely justifies four-axis scoring on forty items, because the effort of scoring competes with the work being scored. The rough sort usually comes from the cheapest tool on the list, and the careful one gets reserved for the handful of candidates that survive it. Teams that skip this step spend two days building a table whose top six were obvious on day one, and teams that skip the careful pass entirely end up ranking by whoever argued longest. The practical shape is two passes: something fast to cut the list down, something slower to order what remains.

Even with both groups in hand, something is left over. A framework produces a score; people decide what gets built. When two candidates come out close, the tiebreaker is which one points where the company is trying to go. The resulting order laid onto a timeline is a product roadmap, and a team that keeps overturning its order has a roadmap that is stale the day it's drawn.

"Here are the top six by RICE this quarter. I've also written down why numbers seven and below got cut."

More care went into explaining the exclusions than the selections.

"Let engineering set the effort numbers. When we set them they always come in under reality."

Someone who won't build the thing estimating its cost skews in one direction, and this heads it off.

"It scores third but we're moving it up. The contract says next month."

The place where a person overrides the framework — and states the reason for the override.

Pagedeck's quarterly planning meeting runs in that order. Mia first pulls the day-sized fixes out of the forty-one items in the backlog and groups them separately. The remaining twenty-three go into a RICE table, where Mia fills in reach, Theo fills in effort, and Sofia supplies the weight of anything tied to a contract. Once the table is full the list sorts itself, and that's where the conversation starts.

Last quarter Theo pointed out that two of the top six touched the same payment module, so one dropped to the following quarter. Grace moved an item up from eighth place because an enterprise contract had a completion date written into it. Mia wrote one line in the notes for each of those two overrides. Having a record of where the score was overturned is what keeps the same item from needing a fresh defense next quarter.

The seventeen that were cut stayed in the backlog with a reason attached to each. The people who asked were told there was no room this quarter and what went ahead of them. Next quarter a few of those will score higher, and for a few the requester will write back to say they no longer need it. That second outcome only happens because the cut was written down.

The most common mistake is believing the list should be built top to bottom by score. A number came out, so following it looks like fairness. But several things sit outside what any framework computes. Some work can't start until other work finishes. Some work has a date in a contract. Some work scores low alone while raising the value of the three items behind it. Execute the raw order and the task of reshaping the data model stays near the bottom forever, and the three features meant to sit on top of it all jam six months later. A score opens the meeting; it doesn't close it. How many items a team overrode is closer to a sign the framework is being used properly than a sign it failed.

The second misreading treats prioritization as the act of choosing what to do. The six selected items are the visible output, so attention goes there. The work that actually costs something is saying no to thirty-four. Leave the exclusions unsaid and the requesters assume their item is still alive, then ask for a status update two months later. As those questions pile up, the team starts quietly slipping unlisted work into the sprint, and by quarter's end the plan and the reality have nothing to do with each other. Teams that name what they dropped, as they drop it, field far fewer of those questions. Simply making clear that an item is parked rather than dead shortens the conversation considerably.