87 items, 12 shipping, zero commitments

A head of product showed me his roadmap last quarter. It was a Notion page: 87 items, grouped by quarter. 12 were in flight. The rest were aspirational. He told me, with some pride, that the team had a clear roadmap. I asked which items would ship this quarter. He pointed to the 12. I asked which of the remaining 75 were committed for next quarter. He paused. He didn't know. The team didn't know. The page had been a place to file customer asks and internal ideas for over a year, and the list had grown without a single deferral to balance it.

That was not a roadmap. It was a backlog with categories. The team treated it as a roadmap because the document had been named one. Customers were told their requests were on the roadmap. The board was shown the roadmap as proof of forward planning. None of it was operationally true. The list held no commitments. It described nothing anyone had agreed to ship by a specific date.

Conflating backlog and roadmap is one of the most common product failures, and in retros it gets called a prioritization problem. The real problem is not prioritization. The problem is that the team has no mechanism for refusing to add to the list. Every customer ask, every internal idea, every executive request gets filed. The list grows. Nothing is deferred. Each quarter the team picks what it can ship and ships it, and the rest stays on the list, accumulating, with no decision about whether it will ever ship at all. This is the failure that turns an OKR nobody remembers into a wish: a goal with no owner and no cut.

The cost is mostly psychological, but it is real. The team feels buried by the size of the list. Customers see their request on the roadmap and wait, sometimes for years, for something the team never seriously intended to build. The product manager spends hours triaging items that should never have been added. The team's real focus, the 12 items in flight, is correct. The surrounding artifact only creates the false impression that another 75 features are coming. They are not.

The discipline that ends it is a deferral rule. An item joins the roadmap only when another item of similar scope leaves it. The team confronts the tradeoff at the moment of adding, instead of postponing it forever. The list stays a roughly constant size. Everything on it carries real commitment. Asks that don't make the cut get a straight answer, "we won't build this in the next year, and here's why," which serves the customer far better than "it's on the roadmap."

The backlog then becomes a separate artifact: the wishlist. Things go there to be remembered, not committed to. The product team reviews it each quarter and either promotes an item to the roadmap or kills it. The kill conversation is the one most teams have never had. Most backlog items deserve to be killed. They were filed in a moment of customer empathy or idle interest and have aged without earning a place anywhere. A roadmap you can defend in a board meeting is one where every item survived that cut, the same standard a meeting that ends in a decision holds against one that ends in notes.

Separate the roadmap from the backlog. Defend the line between them. Within a quarter the conversations about what to build get sharper, and the team feels lighter, because the list has finally been prioritized instead of merely collected. The long list was never a plan. It was a place to avoid making one.