Planning & product · Working paper
Make trade-offs visible.
A concise record for making a live choice visible before urgency, meetings, or assumptions make the decision for you.
When a team says it needs a decision, it often means several different things: the outcome is still fuzzy, the trade-off has not been made explicit, the evidence is contested, or nobody has agreed to own the call. A ledger separates those problems before they get disguised as another meeting.
The last concern voiced should not decide the work
A consequential product or technical choice is vulnerable to recency and hierarchy. Someone raises a customer concern; someone else raises an architecture concern; a deadline appears; then the group leaves with a vague “we should probably…” rather than an actual decision. The work either drifts or starts under assumptions nobody can name later.
- The group has not named the customer or business outcome it is trying to protect.
- Options are being debated as identities—build versus buy, platform versus product—not as trade-offs.
- Evidence and assumptions are mixed together, so disagreement feels personal.
- No one knows who may decide, what work the choice displaces, or when it should be reconsidered.
The Decision Ledger is not a status report or an approval ritual. It is a small, shared record of the choice, the evidence behind it, the trade-offs it carries, and who owns the next move.
Write the decision before you schedule the meeting
The first line should be an answerable question, not a solution-shaped request. “Should we use Vendor X?” is usually too narrow. “How should we let this customer class complete the workflow by the commercial window without creating an unsupported parallel path?” makes the outcome, constraint, and room for alternatives visible.
Do not add every fact available. Include the evidence that materially favors or weakens an option, the assumptions that are not yet proven, and the constraint the owner is being asked to accept. The ledger should fit on a page someone can read before a discussion—not become an 80-page brief no one can use.
A worked decision: three plausible paths, no visible trade-off
Imagine a sponsor needs to respond to a customer-specific workflow request. The group is debating a vendor integration, a narrow internal adapter, or an assisted path while it learns whether the need is repeatable. Every option can be reasonable. The useful question is which one fits the outcome and current evidence with the least regret.
Illustrative fictional scenario — not a client case study.
Three plausible options. No visible trade-off.
A ledger makes the choice legible enough for the accountable owner to decide what to do now—and what evidence would justify reopening it.
Swipe or scroll to see the full figure
Read the figure as a table
| Option | Trade-off accepted now | Reopen when |
|---|---|---|
| Vendor integration | Faster route with vendor and contract risk. | Terms or API materially change. |
| Narrow adapter | More control with a focused build cost. | Demand becomes repeatable. |
| Assisted path | Slower scale but lower regret while learning. | The need and workflow are proven. |
A complete record would also name the result of the choice: perhaps the sponsor selects an assisted path for one customer cohort, assigns a product partner to collect the missing demand evidence, and sets a review after two observed cycles. That is a decision. “Let’s keep evaluating” is only a decision if it names what will be learned, by whom, and when it changes the route.
Use the ledger in three moments
The record supports the conversation; it does not replace judgment. Use it differently before, during, and after the decision.
- Before: draft the question, outcome, obvious options, and the one or two assumptions most likely to change the answer. Invite the people who own relevant evidence, not every interested observer.
- During: separate fact from assumption, make the reversible and irreversible parts clear, and ask the owner to choose or commission a bounded piece of decision-changing work.
- After: record what was chosen, what was consciously deferred, what changes in the roadmap, who communicates it, and the condition for reopening the choice.
If the group cannot name an accountable owner, it has found an ownership problem rather than an evidence problem. If it cannot state an outcome, it has found a strategy problem. Neither becomes clearer by collecting more implementation detail.
Make reversibility part of the choice
Some decisions are easy to revise; others are expensive to undo because they change customer commitments, data, contracts, operating burden, or team capacity. A good ledger does not pretend all choices carry the same risk. It names where a small experiment, a limited cohort, a feature flag, an assisted path, or a short spike can buy useful evidence before an irreversible commitment.
Retire the record when it has done its job
Not every ticket, pull request, or routine priority needs a ledger. Use it when a choice crosses product, technical, commercial, or organizational boundaries and a vague decision would create expensive rework. Once the choice, next move, and review trigger are clear, link the record from the team’s normal system and stop revisiting it until the stated trigger fires. The mechanism should reduce repeated debate, not become a new archive of paperwork.
Use the resource
Decision Ledger
A client-neutral record for naming the decision, options, evidence, trade-offs, accountable owner, next action, and revisit trigger. Use it for consequential choices, not routine day-to-day decisions.
PDF for printing or sharing. DOCX for adapting in your own tools.
Choose the next move that matches the situation
Keep working on it yourself
Use the roadmap guide when this decision depends on a longer route through unknowns, risks, dependencies, and learning.
Read the roadmap guideOne live decision
Bring a consequential trade-off to a focused Working Session when the group needs a credible next move and accountable owner.
Bring it to a Working SessionThe decision keeps returning