The Anti-Backlog

A confession

I have walked into every PM job I've held with a backlog of 200 to 2,000 items waiting for me. I have looked at every one of those backlogs, felt overwhelmed, and tried to "groom" my way through them. I have failed every time.

Backlog grooming is a ritual we adopted because we couldn't think of anything better to do with the inheritance. The PM who left the team three years ago wrote 40 percent of the items. The customers who asked for them have churned, changed their minds, or had the underlying need addressed differently. The items remain. We pretend they're real input.

A 400-item Jira backlog is not a plan. It is a graveyard pretending to be an inventory. This chapter is the demolition.

What's broken

It's a memory nobody reads. Items written years ago by people no longer at the company, requested by customers no longer at their company, on top of products that no longer exist in their original form. We treat it as institutional memory. It's the opposite. It's institutional amnesia in tabular format.

It's a queue that's processed by no one. A queue is something you process. The backlog is processed by nobody. Items just live there. Calling it a "queue" is wishful thinking. Calling it a graveyard is the diagnosis.

It rewards capture over judgment. PMs are praised for "writing it down" rather than for deciding what matters. The act of capturing feels like progress. It's deferral. The PM who refuses to add to the backlog and instead says "we won't do this" is doing better PM work than the PM who captures everything.

It distorts conversations. When a stakeholder asks "why aren't we doing X," the PM points to the backlog. "It's there, just not prioritized." Implies "yes, eventually" when the actual answer is "no, never." The backlog is the lie that lets you avoid the no.

It loses information faster than it gains it. The customer who asked for X six months ago is not a fixed signal. Their context evolved. Alternatives in the market changed. The job-to-be-done may have shifted. The backlog item is a fossil. The signal in this week's call recording is the only thing that's actually current.

The live queue replacement

What I run instead has these properties.

It's small. Capped at two weeks of work for the team. If you can't see all of it on one screen without scrolling, it's too big. The discipline of a small queue forces real prioritization.

It's signal-fed. Items enter from one of four sources only: top customer signal cluster (from continuous listening), eval regression, incident post-mortem action item, cost spike investigation. No item enters because someone had an idea. Ideas go elsewhere.

It has explicit slots. Each engineer's coming two weeks has a fixed number of slots. Items map to slots. When slots are full, no more items go in. This is the part that breaks PMs used to "we'll figure it out" mode.

It empties. Items get done within their two-week window or they get kicked out. They don't migrate to "next sprint." They go back to the signal source. If signal still says they matter, they re-enter. If signal has faded, they were never as important as the original capture suggested.

Where ideas go (since not the backlog)

Three places.

The hypothesis library. Half-formed ideas get written as hypotheses, not features. "I think users would benefit from X because Y" instead of "Add feature X." The library is searchable, taggable, and used as input to the bet portfolio. It's not a queue. Nothing in it is "scheduled." It's reference material for the team's thinking.

The signal stream. The continuous listening system catches what customers actually say. If five customers say the same thing, it cluster-bubbles. You don't need to remember the one customer who said it three months ago. The system will resurface the pattern when it becomes one.

The kill list. Decisions you've already made not to do something. "We considered X. Here's why we won't do it. Here's what would have to be true for us to reconsider." This is the most underrated artifact a product team can keep. It prevents the same idea from being relitigated every quarter.

Three docs replace the backlog. None grows unboundedly. None pretends to be a queue.

How to migrate

You have a backlog right now with 200 to 2,000 items. Don't try to triage it. You will fail.

Do this instead.

Week 1: Archive everything older than 6 months. Single bulk move. To an "archive" status nobody looks at. If something matters, it'll come back through signal within a quarter. Almost never does.

Week 2: Sort the rest by signal evidence. Items with active customer signal in the last 30 days survive. Items without it get archived. Don't agonize. Signal-supported items are the ones that matter.

Week 3: Stop adding to the old backlog entirely. New items enter the live queue (if signal-fed) or the hypothesis library (if speculative). Old backlog freezes.

Week 4: Delete the old backlog. Or archive it to read-only. Team will feel anxious. Hold the line. Within two months they'll wonder how they tolerated it.

The discomfort is highest in week 4. It passes. What replaces it is a team that ships in response to signal rather than performing prioritization rituals against a graveyard.

The cultural fight

A stakeholder, sometimes the CEO, will find the backlog comforting. Killing it will feel cavalier to them.

The argument that lands: a 400-item backlog is not rigor. It's the appearance of rigor without the substance. The work that ships is not coming from the backlog. It's coming from this quarter's bets, this week's incidents, and the signal you saw on Monday. The backlog is theater.

If they push back, offer a compromise: keep the backlog read-only as an archive, but the team operates from the live queue. Track for a quarter what gets shipped from the queue versus the backlog. The data closes the conversation. The backlog won't produce a single shipped item that wasn't already a signal-driven priority.

Pick one thing this week

You're not going to delete the backlog Monday. Do this instead.

1. Open your current backlog. Sort by date created.
2. Filter to anything older than 12 months. Count the items. (You'll be surprised.)
3. Archive them. Bulk move. One action.
4. Tell your team you archived them. Watch what happens. (Spoiler: nothing.)
5. For the next two weeks, don't add anything to the backlog. If it's a real bet, it goes in the live queue (small, signal-fed). If it's a hypothesis, it goes in the library.

After two weeks, look at what you would have added to the backlog and didn't. How much actually mattered? Usually about 10 percent. The other 90 percent didn't survive even the smallest filter.

The backlog isn't memory. It's amnesia in tabular form. Burn it, and trust the signal to bring back what matters.