Record the tradeoff

1773. Lesson identity

Module

4.10 — Product management

Lesson

Record the tradeoff

Academic type

Workflow

Schema type

Mixed

Order

2 in the module

Estimated time

40–55 minutes

This lesson follows Product work is a sequence of cuts. The previous lesson established how to order work and identify a cut line. This lesson turns one of those choices into a record another team member can inspect.

1774. Learning objective

After this lesson, you can write a product decision record for a release cut that states the objective, available evidence, selected option, rejected alternatives, assumptions, and deferred risk.

1775. Why this matters

A release cut is not complete when someone merely says, “We decided not to do that.” Without a record, the team may reopen the same debate, forget why the cut was made, or mistake deferred work for rejected work. A concise decision record preserves the reasoning without pretending that the choice is permanent.

The record must also distinguish evidence from assumptions. Evidence is information currently available to the team, such as an observed constraint, test result, issue history, or confirmed dependency. An assumption is a condition believed to be true but not yet established by that evidence. If no relevant evidence is available, the record should say so rather than disguising preference as fact.

The person making the prioritization remains accountable for the objective, cut line, and tradeoff; the record makes that ownership inspectable. It also gives AI a bounded artifact to summarize or challenge instead of asking it to guess the team's priorities.

1776. Prior knowledge

You should be able to:

• distinguish a product objective from a feature request;
• order candidate work against a stated constraint;
• identify the release cut line and the work below it;
• distinguish observed evidence from an unverified assumption;
• describe the previous lesson's tradeoff: what the team gains by selecting one option and gives up by deferring another.

1777. Core concept

A product decision record makes a choice inspectable by separating six things that are often blended together:

1. Objective: what the release is trying to accomplish.
2. Decision: what is included, excluded, or changed.
3. Evidence/Basis: what available observations, confirmed constraints, or other sources support the choice—or an explicit statement that no supporting evidence is available.
4. Alternatives: plausible options that were considered but rejected or deferred.
5. Assumptions: uncertain conditions believed to be true when the decision was made.
6. Deferred risk: what could go wrong because of the decision, and what observable signal would require a review.

The record is not a diary and not a vote count. It is a compact explanation of the decision's boundary, its basis, the uncertainty that remains, the capacity deliberately protected for validation, and its conditions for revision. A complete record shows not only what was chosen, but what the choice makes harder or riskier.

Evidence and assumptions must not be merged. “The milestone has five working days remaining” may be a confirmed constraint. “Clearer prompts will resolve the onboarding problem” remains an assumption until suitable observation supports it. A preference such as “the challenge room feels less important” is neither evidence nor a useful assumption unless the team connects it to the objective and states what remains uncertain.

A rejected alternative is different from deferred work. Rejected work is outside the current direction unless new evidence changes the objective or constraints. Deferred work remains plausible but is intentionally postponed. Labeling the difference prevents the backlog from becoming a list of unexamined promises.

1778. Mental model

Use the Decision Record: O-D-E-A-A-R model. The mnemonic is only a memory aid; every field still requires a concrete entry.

A usable record can be short:

Context/date: [date or release context]
Objective: [outcome]
Decision: [selected release cut]
Evidence/Basis: [available observation, confirmed constraint, source, or “No supporting evidence is currently available”]
Rejected: [option not aligned with the objective or constraint]
Deferred: [plausible option postponed]
Assumptions: [uncertain conditions supporting the choice]
Deferred risk: [accepted downside]
Review if: [observable signal]
Review owner: [optional role or person, if required by the workflow]

The model creates traceability from objective and evidence to the cut. It does not guarantee that the decision is correct.

1779. Concrete example

Suppose a small release has one objective: make the first ten minutes of play legible for a new player. The candidate work includes a new inventory screen, additional item variety, clearer interaction prompts, and an optional challenge room.

A decision record might state:

Context/date:
Current release cut, reviewed before milestone planning.

Objective:
Make the first ten minutes legible without adding a new explanation sequence.

Decision:
Include clearer interaction prompts and a smaller, more explicit inventory view.

Cut:
Remove the optional challenge room from this release.

Evidence/Basis:
The release constraint permits only one of the prompt revision or the new challenge space.
Available review notes identify interaction legibility as the objective for this cut.
No evidence is currently available that additional item variety would improve interaction legibility.

Rejected alternative:
Adding more item variety was rejected because it increases choice without addressing
whether players can identify the current interaction.

Deferred:
The challenge room remains a possible later addition if the core interaction is clear.

Assumptions:
The existing interaction rules are sufficient once their presentation is clearer.
The revised prompts and inventory view can be validated within the remaining release window.

Deferred risk:
The release may feel too narrow for players who already understand the core loop.

Review if:
Playtest notes show that clarity improves but repeat-play motivation remains weak.

Notice what the record does not claim. It does not say the challenge room is bad, that item variety will never matter, or that the prompts will solve every onboarding problem. It records the available basis for the choice, marks what is still assumed, and states what evidence would justify revisiting the decision.

1780. Common mistakes

The most common mistake is recording only the outcome: “We cut the challenge room.” That sentence hides the objective, basis, alternatives, assumptions, and conditions under which the cut should be reconsidered.

A second mistake is placing an unsupported prediction in the evidence field. “Players will understand the prompts” is not evidence merely because it sounds plausible. Record it as an assumption until observation supports it. If the decision is based only on a confirmed capacity constraint, cite that constraint and explicitly state that no player evidence is currently available.

Another mistake is describing every postponed item as rejected. If the team still considers an option viable, call it deferred and record the evidence needed before returning to it.

Do not use a numerical score as a substitute for reasoning. A score can support prioritization, but the decision record must still expose the evidence, assumptions, and tradeoff behind the score.

1781. Independent practice

Choose one release cut from the backlog ordering you created in the previous lesson. You own the prioritization: do not ask AI or a numerical score to choose the cut. Write a decision record using the O-D-E-A-A-R model.

Your record must:

1. state one release objective in outcome terms;
2. identify the selected work and the cut boundary;
3. include an Evidence/Basis field that cites the available evidence or confirmed constraint, or explicitly says that no supporting evidence is available;
4. name one plausible alternative that was rejected and explain why;
5. name one plausible alternative that was deferred, if one exists;
6. state at least two assumptions without presenting them as evidence;
7. describe one accepted downside and an observable signal that would trigger review.

Then perform a contradiction pass. Ask:

• Does the selected work actually serve the stated objective?
• What evidence supports this choice, and what remains only an assumption?
• Does every statement in the Evidence/Basis field point to information that is actually available?
• Does the rejected alternative address a different objective, or was it simply harder?
• Is the deferred item genuinely still plausible?
• Could another team member tell what new evidence would change the decision?

You may ask an AI tool to challenge the record after you draft it, but keep authorship of the decision. Give it the objective, decision, evidence, alternatives, assumptions, and risk. Ask it to identify unsupported claims, missing conditions, or internal contradictions—not to choose the release cut or invent evidence. Accept a suggestion only after verifying it against the release constraint and available sources.

1782. Validation / evidence

Your evidence of completion is a decision record and a short revision note. The revision note must identify one unresolved assumption, one validation activity protected by the cut, and whether any AI suggestion was accepted, rejected, or left unverified.

The record passes when a reader can answer all of these without asking for oral context:

• What outcome is the release optimizing for?
• What was selected and what was cut?
• What evidence or confirmed constraint supports the choice?
• If no supporting evidence is available, does the record state that explicitly?
• Which alternatives were rejected versus deferred?
• What remains an assumption rather than evidence?
• What downside is being accepted?
• What observable signal would cause a review?

Use this final validation question: What evidence supports this choice, and what remains only an assumption?

If the reader can identify the decision but cannot identify its basis or review condition, the record is incomplete. If the record lists risks without connecting them to a signal, revise the deferred-risk field. If an assumption appears as evidence, relabel it and state how it could be tested.

1783. Key takeaways

• A decision record preserves reasoning, not just the final outcome.
• Cite available evidence or state explicitly that no supporting evidence is available.
• Keep assumptions separate from observations and confirmed constraints.
• Separate rejected alternatives from work that is intentionally deferred.
• Every deferred risk should name the accepted downside and an observable review signal.
• AI can challenge a record's completeness, but it must not choose the cut or invent evidence.

1784. Next lesson

Continue to 4.11 — Production. Bring the decision record forward as the product boundary that production must implement, validate, and revisit when its stated trigger occurs.

1785. Knowledge check