Somewhere along the way, backlogs became contracts. A customer asks for something, it goes in the backlog, and now it's a promise. Not explicitly. But implicitly. It's written down. It has a ticket number. Someone will ask about it eventually.
That's the problem. The backlog doesn't distinguish between "we should definitely do this" and "someone mentioned this once in a meeting."
How backlogs become obligations
Every ticket feels like a commitment because the system treats them all the same. Same fields. Same workflow. Same status options. A game-changing feature and a throwaway idea from a brainstorm sit side by side, looking equally legitimate.
Over time, the backlog becomes a list of things you feel guilty about not doing. Not a tool for making good decisions. A monument to every idea nobody had the courage to reject.
The promise problem
When customers or stakeholders can see the backlog, it gets worse. "I see my request is in there" becomes "when are you building it?" The backlog went from internal planning tool to external expectation.
Now you're not just choosing what to build. You're managing the disappointment of everything you don't build. That overhead is enormous and completely self-inflicted.
Why hypotheses work better
A hypothesis has a built-in expiration. "We believe that building X will improve Y for Z customers." That framing invites validation. It invites the question "is this still true?"
A backlog item that says "Build export feature" invites none of that. It just sits there, waiting to be done, regardless of whether the need still exists.
The shift
Stop adding to the backlog by default. Start requiring every new item to answer three questions: who needs this, why now, and how will we know if we were right?
If you can't answer all three, it's not ready for the backlog. It's just an idea. And ideas belong in a notebook, not a ticketing system.
Tom Pinder