A prioritised, visible list of open research questions — each paired with the method to answer it, the decision it informs, the stakes, and an owner. What the delivery backlog does for engineering, this does for learning.
▸ Try the interactive toolThe Discovery Backlog is a prioritised, visible list of the open research questions a team needs to answer — each paired with the method that would answer it, the decision it would inform, the stakes of that decision, and an owner. It does for discovery work what the delivery backlog does for engineering: it makes the work explicit, prioritised, and trackable.
Without it, discovery questions live in people's heads, get researched ad hoc, and compete invisibly for attention. The backlog makes the team's open questions visible and prioritisable — and the discipline of pairing each question with the decision it informs is what keeps research tied to action. A question that informs no decision doesn't belong on the backlog, which is the filter that stops discovery from drifting into curiosity for its own sake.
The question · the method that would answer it · the decision it informs · the stakes of that decision · an owner. No decision → not on the backlog.
Discovery questions are easy to forget and impossible to prioritise when they live only in people's heads — so the important ones get crowded out by whatever's top of mind.
| The shortcut | What it costs | What it gives you instead |
|---|---|---|
| Questions live in heads | Open questions are forgotten or researched by whoever remembers. | A visible backlog captures and preserves them. |
| No prioritisation | Every question competes invisibly; the loudest wins. | An explicit backlog lets the team prioritise by stakes. |
| Research with no decision | Curiosity-driven research that informs nothing. | Pairing each question to a decision keeps research actionable. |
| No ownership | Questions everyone assumes someone else will answer. | An owner per item ensures questions actually get tackled. |
Write down the questions the team needs answered — from the assumption map, the OST, stakeholder debates. Get them out of heads and into one visible list.
For every question, state what decision the answer would change. This is the crucial filter: a question that informs no decision is curiosity, not discovery — drop it.
Note how you'd answer it (which research method), how much the decision matters (stakes), and who owns it. These make the item actionable and prioritisable.
Order the backlog so the highest-stakes, most decision-relevant questions rise to the top. The weekly rhythm pulls from here.
Pull the top questions into the weekly discovery rhythm, answer them, log insights to the repository, and keep adding new questions as they arise. It's a living list, like a delivery backlog.
A team did plenty of research, but it was driven by whoever was curious about what — some of it interesting, much of it informing no actual decision. Meanwhile a genuinely high-stakes question kept getting deferred because it lived in someone's head, not on any list.
Building a discovery backlog forced the discipline: every question had to name the decision it would inform. Several pet research ideas fell away immediately — they informed nothing — while the deferred high-stakes question rose to the top, got an owner and a method, and was answered within the week. Research effort shifted from interesting to consequential, simply because the backlog made stakes and decisions explicit.
The deliverable is a visible, ranked list — each question carrying its method, the decision it informs, its stakes, and an owner.
| Field | Why it's required |
|---|---|
| Question | The open thing to learn |
| Decision informed | The filter — no decision, no entry |
| Method | How it'll be answered |
| Stakes | How to prioritise it |
| Owner | Who ensures it happens |
The discovery backlog brings to research the same rigour the delivery backlog brings to building: explicit, prioritised, owned. And its single most valuable field is ‘the decision this informs’ — the filter that keeps discovery consequential.
That filter is what distinguishes discovery from idle curiosity. It's easy to generate endless interesting questions about users; the backlog forces each one to justify itself by naming a decision it would change. Questions that pass become prioritised, owned work that feeds the weekly rhythm; questions that fail get dropped before they consume research time. The result is that the team's limited discovery capacity goes to the questions that actually matter — and the backlog makes the whole programme visible, so high-stakes questions can't quietly languish in someone's head while curiosities get researched instead.
If a question informs no decision, it's curiosity. The decision field is the filter — use it.
An invisible backlog can't be prioritised. Make it explicit and shared.
Questions everyone assumes someone else owns go unanswered. Assign one.
Stakes shift; new questions arise. Keep the backlog current, like a delivery backlog.
The rhythm (Tool 23) pulls its weekly work from the prioritised backlog.
Risky assumptions (Tool 14) and open opportunities (Tool 03) become backlog questions.
Before adding a question, check the repository (Tool 22) for an existing answer.
It's the discovery-side counterpart to the engineering backlog covered in Module 4.
List three things a team you know is currently unsure about. For each, force the key field: what specific decision would the answer change?
Drop any question that doesn't inform a decision. For the survivors, add a method and rank them by stakes.
If one of your three questions had no decision attached, you've just used the filter that keeps a discovery backlog honest — and seen how much ‘research’ is really curiosity in disguise.