Prioritization became sequencing
Prioritization frameworks exist because building was the bottleneck. What happens when the bottleneck goes away?
Every prioritization framework you know is a child of scarcity. ICE, RICE, effort-impact matrices: they all exist for a single reason. Build capacity was the bottleneck. The team shipped five things a quarter, the list had fifty, and almost everything on the list genuinely mattered. Someone had to decide what got left out, and needed a defensible method for it. Prioritizing was, in practice, choosing what not to do. And the scoring was less about math and more about giving exclusion an appearance of objectivity.
I spent years of my career in that liturgy. Collecting estimates, scoring impact, negotiating weights, presenting the matrix, reprioritizing the next quarter. Spreadsheets, workshops, sticky notes, round after round. And it made sense in its time: with engineering slow and expensive, a wrong bet cost an entire quarter. The method existed to protect the company's scarcest resource.
A real example of what changed. A module that, in a traditional team, would demand dozens of tickets, two or three epics, a refinement round and a prioritization ceremony to make it into the quarter. Today I describe that module in thirty minutes, with context and acceptance criteria, and it's built in forty. That's not a figure of speech: it's the actual ratio between describing and building that I live daily. Writing the spec now takes longer than implementing it. And the learning cycle shrinks with it: what ships today produces data tomorrow, and tomorrow's data decides the next build. In a traditional team, that same module would wait months in the queue.
When the bottleneck disappears, the question changes in kind. "What should we prioritize" assumes most of the list will die. If almost everything worth doing can be built, the question becomes a different one: what do we build next? It sounds like the same question. It isn't. Prioritization is about exclusion; sequencing is about order. And order is decided with a different input: not effort estimates, but usage evidence. Behavioral data in the product, real engagement, what users do and what they abandon. Sequencing hands the decision back to where it always should have lived: continuous discovery. Sequencing well is a different skill from prioritizing well: it takes less politics and more reading of evidence.
And the PM's busy work? It disappears, and I don't miss it. Writing ticket after ticket, managing the backlog, refereeing estimate disputes, updating the management tool so it could tell a story everyone already knew. None of that was the work. It was the scaffolding around the work. The time that went into scaffolding goes back to what should always have been the center: understanding the user and deciding the next step with evidence. Not with the loudest opinion in the room, but with data. I don't know a single PM who misses the scaffolding.
If your week is still dominated by backlog refinement, the question is worth asking: does the bottleneck that justified it still exist?