Every team I’ve worked with can produce a ranked list of what matters. Almost none can tell you what happens to item four once item one is finished, or which of the ten items still matters if the company changes its pricing model in March.
That second question is the one that decides whether a quarter of work compounds or evaporates.
Impact ranking is only half a framework
The standard move is to score each task on impact and effort, sort, and work down the list. It feels rigorous. It produces a defensible order you can show a stakeholder. It also quietly assumes the tasks are independent, which they almost never are.
Real work has a dependency structure. Some tasks are load-bearing: finishing them changes what the other tasks cost. Others are leaves: valuable, but nothing hangs off them. A ranked list flattens that structure into a line and throws away the most useful information you had before you started sorting.
The reframe is small and it moves the order a lot. Rank by what is most impactful and makes the next thing cheaper.
Building the dependency tree
Take the list and, for each item, ask one question: if this were done today, which other items become smaller or unnecessary?
Three things fall out almost immediately.
Some items collapse others. A proper CI pipeline delivers faster feedback and removes three separate “manually verify X before release” tasks sitting further down the list. That item is eating the others.
Some items are downstream of everything. They look urgent because someone is asking for them, loudly and by name. They can’t start until four other things land. Their real position in the order has nothing to do with where their impact score put them.
Some items are genuinely isolated. Nothing depends on them, they depend on nothing. Be honest about these: they can be done any time, which usually means later, which often means never, and that’s fine as long as it’s a decision rather than a drift.
The output isn’t a line. It’s a tree, and the work starts at the trunk.
The permanence test
Here’s the part most frameworks skip, and the part I care about most.
Once you have the tree, apply a second filter to each candidate:
If the business model changed tomorrow, would this still be worth having?
Some work is permanent. A test suite that pins down actual behaviour is worth having whether you sell to enterprises or to individuals, and a documented, repeatable process for handling an incident survives any pivot or reorg.
Other work is contingent. A feature built for one customer segment. An integration with a partner whose contract is up for renewal in the spring. All of it can be correct and genuinely worth doing, and all of it can be worth nothing in six months through no fault of the person who built it.
Most product work is contingent, and it has to be, because that’s where the revenue comes from. The mistake is not noticing the difference, and therefore not noticing that a quarter spent entirely on contingent work leaves you exactly where you started the moment conditions move.
So: deliberately spend a fixed share of every cycle on permanent work, positioned at the trunk of the tree. A share, and one you don’t trade away when something urgent arrives, because urgent things are almost always contingent things wearing a costume.
What counts as permanent
A working definition: work is permanent when it’s about the system that produces the product, rather than about the product itself.
- Feedback loops, tests, monitoring, alerting, anything that shortens the distance between a mistake and knowing about it
- Deployment and rollback paths
- Documented processes that let a second person do what only one person can do today
- Data you can’t reconstruct later if you fail to capture it now
- Removing a dependency on a single human being
Every one of those keeps its value across a pivot, a market shift, a bad quarter, or a change in who works there.
It’s also, not coincidentally, the category most teams never get round to. Which is why it pairs so well with pointing AI at the work you reliably skip: the permanent list and the never-done list overlap almost perfectly.
A worked example
Take an invented quarter, so the shape is clear. The backlog going in, ranked by impact in the order a normal grooming session would produce:
- Rebuild the onboarding flow (biggest requested win)
- Add SSO for one enterprise prospect
- Fix the flaky test suite everyone ignores
- Manual QA checklist before each release
- Write the incident runbook
- Add three dashboard widgets sales asked for
- Reduce deploy time
Run the dependency question over it and the shape changes. Item 3 collapses item 4 outright (nobody needs a manual checklist when the suite is trustworthy) and it makes items 1, 2 and 6 cheaper and safer to ship, because they all touch code nobody currently dares refactor. Item 7 makes every other item faster to land. Item 5 removes a dependency on the one person who knows what to do at 3am.
Now the permanence test. Items 3, 5 and 7 survive any pivot. Item 1 is mostly permanent: a working onboarding flow matters under any model, though its specifics don’t. Items 2 and 6 are pure contingent: one prospect, one sales request, both of which can evaporate before the quarter ends.
The re-sorted order: 3, 7, 5 at the trunk, then 1, then 2 and 6 with clear eyes about what they are. Item 4 doesn’t get done at all, because item 3 deleted it.
Notice what happened to the top-ranked item. It moved down. And the ignored flaky test suite (the one that was never going to get prioritised on impact, because “fix the tests” has no impact story a stakeholder wants to hear) moved to first, because it’s the item that made everything after it cheaper.
Sequencing in practice
The order I actually work in:
- Trunk and permanent. Load-bearing, survives a pivot. Highest priority regardless of how it scores on a naive impact ranking, because everything after it gets cheaper.
- Trunk and contingent. Load-bearing for the current plan. Do it, but know what it is, and prefer the version that leaves permanent residue behind.
- Leaf and permanent. Small compounding wins. Good filler for the gaps between larger pieces.
- Leaf and contingent. The bulk of the visible backlog. Necessary, and the category to be most ruthless about, because it produces the most motion and the least accumulation.
The uncomfortable consequence is that the highest-scoring item on a normal priority list frequently lands in bucket four.
What this is not
This isn’t an argument for infrastructure over features. A permanent system that produces a product nobody wants is a very durable failure. Contingent work is how you find out what to build; permanent work is how you keep what you learned.
It’s also not a licence to spend a quarter on tooling. The share of permanent work is a share, and it’s small. What matters is that it’s non-negotiable. A consistent fraction of every cycle beats an occasional heroic rewrite by a wide margin, for the same reason dependency order beats impact ranking. It compounds.
If you’re wondering where the effort should concentrate more generally, that’s the same question about narrow windows and unspent effort, seen from the other side.
One distinction is worth carrying alongside the ranking: a few items are expensive to reverse in the way a construction drawing is, and those deserve a different process rather than a higher position on the list.
Impact ranks what is worth doing; dependency ranks what is worth doing first.
Which item on your list this quarter would still be worth having if the pricing model changed next month?