Research debt rarely announces itself as a missing study. It appears in ordinary conversations. A team says customers need a dashboard, but nobody can identify which customers. A roadmap item refers to a persona last reviewed before the product changed its pricing. A familiar workaround is described as proof of demand because it has been repeated often enough to sound established.

The product still ships. Decisions still have explanations. What is missing is the connection between those explanations and evidence that remains relevant to the people, situation and decision at hand.

I use research debt to describe consequential uncertainty that a team has deferred, lost or allowed to become stale while continuing to make dependent decisions. This is a practical definition, not a standardized accounting model. It helps distinguish a normal unanswered question from an unanswered question that is already shaping investment.

Not every assumption requires a research project. Some choices are inexpensive, reversible and adequately informed by existing knowledge. The problem begins when the organization cannot tell those choices apart from commitments that rest on weak evidence. This article outlines how to identify that debt, decide what deserves repayment and keep evidence useful without creating a research bureaucracy.

Recording evidence is a separate activity from interpreting it. The equipment illustrates capture, not proof of a research finding. Credit: Tyler Casey / Unsplash.

Debt is about dependency, not document volume

An organization can have a large research repository and substantial research debt. The existence of findings does not establish that they answer the current question. Evidence can be inaccessible, misunderstood, outdated or collected from a population different from the one affected by the next release.

Imagine a hypothetical procurement platform expanding from central purchasing teams to occasional departmental requesters. The product team reuses research about experienced buyers to design onboarding. The original research may still be excellent. The debt comes from treating its conclusions as transferable without checking the new context.

The key question is not “How many studies have we done?” It is “Which current decisions depend on knowledge we do not adequately have?” This shifts the conversation away from defending the research function and toward improving a specific investment decision.

It also creates a useful boundary. An unanswered question about a feature nobody is planning may be interesting, but it is not necessarily urgent debt. An untested assumption about whether requesters understand approval responsibility may deserve attention now because the organization is building an onboarding flow around it.

Four forms of research debt

I would distinguish deferred, stale, fragmented and misapplied evidence. The categories are diagnostic aids. A single decision can contain more than one.

Deferred evidence is the familiar case: a team knowingly proceeds without checking an important assumption. Stale evidence was relevant when collected but may no longer fit changed users, policies or workflows. Fragmented evidence exists across interviews, support records and local documents but has not been connected to the decision.

Misapplied evidence is more subtle. A finding about one role becomes a statement about all users. A preference becomes a requirement. An internal stakeholder’s account becomes a substitute for direct observation. A successful prototype test becomes evidence that customers will adopt and pay for the feature.

These forms need different responses. Deferred evidence may require new research. Stale evidence may need a focused check rather than a complete repeat. Fragmented evidence may need synthesis and retrieval. Misapplied evidence may first require correcting the claim. Commissioning another broad study is not automatically the best way to repay every kind of debt.

Dovetail’s published search example organizes material across sources; retrieval alone does not establish that a claim is still valid. Credit: Dovetail.

Trace one roadmap item back to its evidence

The fastest way to make debt visible is to follow a real decision backward. Choose a consequential roadmap item and ask why it exists. Then ask what observation supports that reason, where it came from and which people it represents.

Suppose the procurement roadmap includes a personalized homepage. The stated reason is that requesters cannot find their pending work. The supporting material consists of several support conversations, a stakeholder interview and analytics showing frequent returns to the request list. These sources suggest a problem, but they may not establish its cause.

People could be returning because approval status is unclear, because they need a routine overview, or because the list is the correct place to work. A personalized homepage might help, but the evidence does not yet select that solution. The debt is the unresolved causal assumption hidden beneath a delivery commitment.

Document the chain: proposed investment, intended outcome, underlying problem, supporting evidence and unresolved question. You do not need to map the entire roadmap immediately. A few important chains often reveal whether the organization preserves evidence or progressively replaces it with confident summaries.

Build a debt register that people can actually use

A register should be short enough to participate in planning. I would include the decision, the assumption, existing evidence, gap, consequence if wrong, owner and next review point. Add the intended action: investigate, proceed with a limit, monitor or retire.

Avoid writing entries as vague topics. “Understand requesters” is difficult to prioritize. “We assume occasional requesters know who must approve a new supplier; the onboarding plan depends on this” connects uncertainty to work the team intends to do.

State the evidence boundary precisely. If the team interviewed only frequent buyers, say so. If support cases came from one enterprise customer with a custom configuration, retain that detail. Evidence does not become useless because it is narrow; it becomes dangerous when its narrowness disappears.

The register is not a backlog of every possible study. It is a record of consequential uncertainty the team has chosen to carry. A product manager should be able to read an entry and understand what decision might change if the team learns something different.

A useful evidence record preserves applicability and review triggers. The entries illustrate structure, not research results. Credit: Original editorial visual prepared for Andrea Mabellini.

Prioritize repayment by decision exposure

The most urgent debt is not always the oldest. I would look at how soon the decision will be made, how difficult it will be to reverse, and what happens if the assumption is wrong. Add the number of dependent decisions and affected groups where that information is available.

A naming assumption in a reversible, low-exposure feature may be acceptable to carry while monitoring use. An assumption about who is authorized to approve a supplier change can affect access policy, interface behavior, training and implementation. Its downstream consequences make it more expensive to leave unresolved.

Do not collapse evidence quality and business impact into a precise score unless the organization can explain the inputs. A matrix can facilitate discussion, but it does not manufacture reliable estimates. Unknown exposure is an uncertainty to manage, not a reason to enter a convenient middle value.

Record the decision to defer as carefully as the decision to research. “Proceed with a pilot limited to frequent buyers, review before expanding to occasional requesters” is an intentional boundary. “We will research later” is a promise with no trigger, owner or effect on the release plan.

Repayment can begin with existing evidence

Before recruiting, examine what the organization already knows. Support teams may have categorized the issue. Customer success may have contextual accounts. Prior studies may contain relevant observations that were not highlighted in the original presentation. This work can refine the question and prevent redundant research.

But synthesis is not permission to flatten every source into the same level of confidence. Support records represent people who contacted support. Sales conversations are shaped by commercial context. Analytics describe recorded events, which may not reflect the mental model behind them. Each source answers some questions better than others.

For the procurement example, support cases can help identify confusing status terms. They do not establish how widespread the misunderstanding is among people who never contacted support. Event data might identify repeated navigation. It cannot show whether that navigation was wasteful without contextual evidence.

Use existing material to make the next question narrower. Instead of “Do users need a better homepage?” ask “Can occasional requesters identify who must act next from the current request status?” That question is more useful for selecting a focused research activity and evaluating a proposed intervention.

Stored evidence needs context, findability and review. A library is a physical analogy for an organized evidence repository. Credit: Zetong Li / Unsplash.

Choose a method that can change the decision

Method selection should follow the uncertainty. If the question concerns how work currently happens, contextual observation or interviews may be appropriate. If it concerns whether a proposed interface communicates responsibility, a task-based usability study can help. If it concerns exposure across a population, qualitative accounts alone will not provide a prevalence estimate.

The GOV.UK research-planning guidance recommends turning assumptions into research questions and selecting activities around what the team needs to learn. That is a useful foundation; the debt register proposed here is my way of connecting those questions to dependent product decisions.

Be careful with internal proxies. A domain expert can explain policy and identify unrealistic scenarios. That does not make them interchangeable with an occasional requester performing the task. If access constraints require proxy research, record what it can inform and what still needs direct investigation.

Similarly, synthetic responses may help generate questions or inspect a script. They are not observations of the affected people. Using an AI-generated persona to confirm an AI-generated concept can produce apparent agreement without introducing independent evidence at any point in the process.

I discuss that evidence boundary further in my article on synthetic users. Research debt is the broader planning issue: what the organization does when a consequential decision still lacks suitable evidence.

Define the repayment outcome before the study

A study does not automatically repay debt. Repayment happens when the team updates the relevant decision and preserves the evidence boundary. Before beginning, state which assumption is being investigated and what action could change.

For the onboarding example, the team may discover that requesters understand the approver but cannot distinguish “submitted” from “approved.” That learning should alter the intervention. A role tutorial might become a status and responsibility improvement. The research is useful because it changes the plan, not because it adds another report.

Some research will reveal that the question was too broad or the population more varied than expected. That can justify another round. Record the remaining uncertainty rather than marking an entry resolved because the scheduled activity happened. Activity completion and evidence sufficiency are different milestones.

Keep the decision record short: what was learned, which claim changed, what the team will do and what remains unknown. Link to the supporting material for anyone who needs detail. This allows knowledge to travel into planning without forcing every participant to read a long research deck.

Evidence needs an expiry trigger, not an arbitrary expiry date

Research does not become invalid simply because it is old. Some user needs remain stable for years. Other findings lose relevance quickly when permissions, pricing, task ownership or the user population changes. Review triggers are more useful than a universal freshness rule.

For each important claim, name the changes that would require reconsideration. A finding about onboarding may need review when the product enters a new market or adds a role. A finding about approval behavior may need review when policy changes. A finding about navigation may need review after the information architecture changes substantially.

This approach also avoids unnecessary repetition. If the task and population remain comparable and the evidence is still applicable, the team can reuse it with a clear explanation. The goal is informed continuity, not a permanent requirement to collect new data before every design choice.

Maze’s published path report preserves method-specific observations. Its demonstration figures are not findings about the article’s hypothetical product. Credit: Maze.

Put research debt into normal planning

An isolated research-debt meeting can create awareness and still leave the roadmap unchanged. Put the register into the places where investment decisions happen: discovery intake, quarterly planning, design reviews and readiness discussions.

When a proposal enters planning, ask which assumptions its value depends on. When a prototype is reviewed, ask whether its evidence applies to the intended users. When scope changes, ask whether an earlier finding still supports the expanded release. These questions are small enough to become routine.

Give someone ownership of each consequential gap, but avoid assigning all responsibility to the researcher. Product owns the investment decision. Engineering contributes feasibility evidence. Support contributes operational context. Design helps translate findings into interaction choices. Research facilitates the evidence, but cannot force an organization to use it alone.

Protect some capacity for questions that can invalidate planned work. If research is scheduled only after commitments are fixed, the organization implicitly asks it to improve execution rather than challenge direction. That may be useful, but it leaves strategic debt untouched.

Measure whether decisions are becoming better informed

The number of debt entries closed is a poor measure by itself. Teams can close entries by weakening the question or accepting unsupported assumptions. I would inspect a sample of decisions for traceability: can someone identify the supporting evidence, its scope and the reason for proceeding?

Also look for decisions changed by learning. A feature stopped, a release narrowed or a problem reframed can be valuable outcomes. A culture that counts only confirmed proposals may discourage the findings that prevent unnecessary investment.

Operational signals can help identify where debt is costly: repeated rediscovery, contradictory requirements or delivery rework after basic task assumptions fail. These signals do not prove research debt caused every problem. They point to decision chains worth examining with the relevant team.

A practical starting point for next week

Choose one near-term initiative with meaningful consequences. Ask product, design and engineering to list its three most important assumptions. Find the evidence for each. Label the gaps and determine whether to research, limit the release or monitor a reversible decision.

Spend more time writing a useful question than polishing the register. A precise entry can change a planning conversation immediately. An attractive repository with unclear claims may simply make old uncertainty easier to distribute.

After the next learning activity, update the plan and the register together. The GOV.UK guidance on sharing findings is a relevant reference for making research accessible to the people who need it. The essential additional step is to show what changed because they used it.

The repayment action should target the assumption that planned work depends on. The links are conceptual dependencies. Credit: Original editorial visual prepared for Andrea Mabellini.

A product can move quickly without pretending to know everything

Research debt is not an accusation that a team has neglected users. Constraints are real, and decisions often have to be made with incomplete information. The useful distinction is whether the organization knows which uncertainty it is carrying and what that uncertainty might cost.

AI-assisted production increases the importance of that distinction because assumptions can become functional interfaces quickly. Structured design-system context can help preserve established rules, as discussed in my design-to-code article. It cannot supply missing knowledge about the user’s actual work.

The mature response is neither endless discovery nor confident guessing. It is to connect evidence to decisions, investigate the uncertainty that matters most and preserve the limits of what has been learned. That is how a product keeps moving without allowing its unanswered questions to become its strategy.