Technical Debt Triage Board

Give the Backlog a Clock

A note such as “clean up imports” preserves a feeling, not a decision. It does not say who is paying for the weakness, whether the next experiment depends on it, or why this week should belong to it instead of discovery, support, sales, or recovery work.

Use this board when several code concerns are competing for a solo founder’s attention. It is a triage surface, not a complete inventory of imperfect code. An item belongs here only when you can trace it to at least one of these:

• a customer promise already being made;
• evidence the product is about to seek;
• recurring support or operating work;
• a trust boundary where waiting for an incident would be reckless;
• surface area the product no longer needs.

Do not begin by estimating every fix. First establish whether there is a consequence worth fixing.

Write the Consequence Before the Solution

Create one card for each candidate item. Describe the weakness in plain implementation terms, then follow it until it reaches a customer or founder workflow.

DEBT CARD

Implementation weakness:
Affected customer or founder workflow:
Observed consequence or plausible severe harm:
Evidence—support case, incident, trace, metric, account, or experiment:
Current product commitment that gives this item a clock:
What remains uncertain:

“Importer is brittle” is not ready for the board. “When an import fails before a customer’s Monday report, the customer cannot reach the product’s core result and the founder must retry the job from a console” is ready. It names a promise, a failure, and an operating cost without presuming that the answer is a new ingestion platform.

If an item has no affected workflow, evidence, or credible severe harm, keep it in an engineering notebook. Embarrassment is not urgency.

Place Each Card by Its Decision Clock

Use five lanes. They are decisions, not severity labels.

Protect now. A customer promise or active trust boundary is exposed. The smallest useful work prevents the harm, makes failure visible, or makes recovery safe. Authentication, permissions, billing, important data, destructive administration, and the reliability of the paid result deserve a shorter clock because the first unambiguous evidence may be an incident.

Unblock evidence. The item would make the next experiment unsafe or its result unreadable. Fix only what the named experiment requires. Missing segment attribution may deserve attention before a funnel test; it does not justify a general analytics rebuild.

Reduce recurring load. Users or the founder repeatedly pay for the same known weakness. Record the frequency and cost. Manual work that is still teaching the workflow may stay; repeated intervention that produces no new understanding is an operating tax.

Keep with a trigger. The shortcut still buys learning or avoids premature generality. Write the event that ends its permission: a retained customer needs another source, support exceeds a limit, a collaborator cannot operate the path, or a measured constraint crosses a threshold. Time passing by itself is not a trigger.

Narrow or remove. The debt belongs to a weak segment, abandoned experiment, or optional branch that has not earned continued support. Deletion may remove more code, tests, permissions, documentation, and support work than a clean abstraction would.

Compare the Active Board

Keep entries short enough to compare in one view. Link to the full debt card or evidence when the board would otherwise become a wall of prose.

This worked board continues the agency-reporting product used in the book’s technical-debt chapter:

The comparison is the point of the board. A small attribution repair can outrank an ugly renderer because this week’s evidence depends on it. A billing-state disagreement can outrank both because customers already rely on the promise. The board should make those different clocks visible without pretending they share one numerical score.

Admit Work, Not a Debt Sprint

Review the board beside the product roadmap and current operating load.

1. Pull forward any plausible severe trust or data harm. Quiet operation is not proof that a dangerous boundary is sound.
2. Name the next customer commitment or learning event. Promote only the debt that protects that move or makes its result trustworthy.
3. Compare recurring founder intervention by frequency and consequence, not by irritation alone.
4. Look for a product decision before an architectural one. Narrowing a promise or deleting an unused branch may resolve the item.
5. Admit one bounded change at a time unless two items must move together for a safe release.

For each admitted item, replace the broad solution with an observable outcome:

ADMITTED CHANGE

Debt item and lane:
Customer promise, experiment, or operating burden protected:
Smallest change that alters the consequence:
Evidence that the change worked:
Recovery or rollback path:
Work explicitly excluded:
Stop condition:
Owner and review date:

“Refactor imports” has no natural end. “Expose final import state, permit an idempotent retry, and remove the console-only recovery step” can be verified and stopped. If the bounded change begins producing a new platform, return it to the board and ask which additional customer commitment authorized the scope.

Re-triage When the Product Moves

Review a card when its trigger fires, before a new experiment depends on it, after an incident, or when a customer promise changes. Do not rehearse the entire backlog on a ceremonial schedule. Archive cards whose consequences disappeared, and delete cards attached to removed product surface.

The board is doing its job when it produces a small set of defensible outcomes: protect this promise now, repair this measurement before the experiment, keep this shortcut until its trigger, remove this unsupported branch. It should not produce a cleanup phase. The codebase will remain imperfect; the next product move should no longer depend on the wrong imperfection.