A product decision memo states the choice, accountable owner, decision date, context, evidence, alternatives considered, tradeoffs, risks, dissent, execution implications, and review trigger. It should be concise enough to read and complete enough for a future teammate to understand why the decision was reasonable at the time.
Who this is for: Product leaders and cross-functional teams making choices that need clear reasoning beyond the meeting where they occurred.
- Lead with the decision and owner so readers do not have to infer the conclusion from background.
- Represent evidence quality, alternatives, tradeoffs, uncertainty, and dissent rather than writing advocacy after the fact.
- Define implementation consequences and conditions for review without turning every choice into a reversible nondecision.
State the decision precisely
Open with one sentence naming what was decided, by whom, when, and for which scope. 'We will pilot automatic invoice matching for eligible US accounts with human approval through October' is clearer than 'we are moving forward with automation.' Add status such as proposed, approved, superseded, or reversed.
Describe the decision question and why it is needed now. Include strategic outcome, customer problem, constraints, and deadline. Keep chronology brief. The memo is not a transcript of every meeting; it preserves the facts and reasoning necessary to evaluate the choice. Link source documents for readers who need deeper detail.
Present evidence and uncertainty
Summarize relevant customer research, product data, technical findings, financial analysis, specialist review, and external conditions. Distinguish observation from forecast and note evidence dates. Explain missing information and confidence. A transparent uncertainty statement strengthens the record because later readers can see which assumptions deserve monitoring.
Use numbers with definitions and comparison points. Include contradictory evidence rather than selecting only support. If one segment benefits while another faces risk, state both. Avoid attaching a large research deck without explaining which findings materially influenced the decision and how.
Compare credible alternatives
List the serious choices considered, including delay, maintain current behavior, or run a smaller test. For each, summarize expected benefit, customer effect, cost, timing, technical or operational consequence, and major risk. Alternatives should be plausible enough that rejecting them teaches the reader something about the chosen tradeoff.
Explain the selection criteria and why the recommendation wins under them. Do not manufacture a score that hides hard constraints. Record dissent and the concern behind it, especially when the final owner overrides a specialist or team recommendation. Dissent can become a monitoring signal rather than an obstacle erased from history.
Make the decision executable
State scope, owners, dependencies, resources, communication, and immediate next actions. Name risks that require mitigation and measures that indicate whether assumptions hold. A decision without operational consequences may be only an opinion. Link the roadmap, requirements, or experiment where execution details will live.
Set review conditions such as a date, threshold, external change, failed assumption, or new evidence. Review triggers do not mean the decision remains perpetually open. Teams should proceed until a trigger occurs. When a choice changes, mark the old memo superseded and link the new one so institutional learning remains intact.
Document a mobile-platform decision
A product team must choose native applications, a responsive web experience, or a limited field-worker pilot.
- State the approved choice to pilot a responsive offline-capable workflow for one field role before native investment.
- Summarize observed field conditions, device data, workflow evidence, technical feasibility, and unanswered offline risks.
- Compare native, responsive, and status-quo options using time, capability, maintenance, accessibility, and learning value.
- Record engineering dissent about browser storage reliability and make it a pilot stop condition.
- Assign the pilot, measures, support, decision date, and evidence required before broader platform commitment.
Product decision memo outline
Keep the main memo short and link detailed analysis where readers can inspect it.
- Decision header: choice, scope, owner, approver, date, status, and one-sentence rationale.
- Context and evidence: problem, outcome, urgency, constraints, sources, contradictions, gaps, and confidence.
- Alternatives: credible options, criteria, customer effect, cost, timing, risk, and reason rejected.
- Tradeoffs and dissent: benefits gained, costs accepted, specialist concerns, assumptions, and mitigations.
- Execution and review: actions, owners, dependencies, measures, communication, triggers, and superseding link.
Common mistakes
- Burying the actual choice at the end of a long narrative that different readers interpret differently.
- Listing only the preferred option and a weak straw alternative that never received serious consideration.
- Omitting dissent, uncertainty, and review conditions to make the historical decision appear inevitable.
Try one
A team chose to delay a requested integration after a contentious meeting. What belongs in the memo besides the delay itself?
A complete answer records the decision owner, scope and duration, customer and commercial evidence, technical dependency, alternatives such as pilot or partner workflow, tradeoffs, stakeholder dissent, affected commitments, and next actions. It defines evidence or a date for review. The memo should not portray disagreement as resolved merely because one leader made the final call.
Sources
- Atlassian product strategy guideOfficial guidance on connecting product vision, market context, goals, and initiatives.
- Atlassian product roadmaps guideOfficial guidance on communicating product direction, priorities, and progress.