A one-page decision memo gives a busy team a shared record of what must be decided, who has authority, and why one option is preferable. This guide provides a compact template, a worked example, and a review process that turns the document into action rather than another report.
What Belongs in a Decision Memo?
A decision memo is a brief recommendation that names the decision, accountable decision-maker, deadline, alternatives, evidence, and next action. It should distinguish facts from assumptions and specify when the team will review the outcome. Keep the main document short enough to read before a discussion, with supporting analysis linked separately.
Decide when a memo is worth writing
Use a memo when a choice affects several people, commits meaningful resources, creates a precedent, or is likely to be questioned later. Routine actions within an agreed policy usually do not need a new document every time.
The memo's job is not to prove that its author considered every possibility. It is to make the important trade-offs visible so an authorized person can make an informed choice. It also preserves the reasoning available at the time, which helps a later review distinguish a weak decision process from an unlucky outcome.
Match the effort to the risk. A short pilot with limited exposure may need only a few paragraphs. A major acquisition or sensitive personnel decision needs more analysis and appropriate specialist advice; fitting it onto one page does not make it adequately assessed.
Amazon's 2016 shareholder letter distinguishes reversible decisions from choices that are harder to undo and argues against treating every decision as equally heavyweight. Use reversibility as a prompt, not a universal instruction to move quickly. Even a temporary experiment can create lasting privacy, customer, or contractual consequences.
Establish ownership before gathering opinions
-
Write the question as a decision.
Why: “Discuss customer onboarding” invites a broad conversation without a clear finish.
How: Write “Should we run a four-week onboarding pilot for new customers?” Include the scope and the date by which an answer is needed.
-
Name one accountable decision-maker.
Why: A room full of contributors is not the same as an authorized owner.
How: Identify who can approve the commitment, who prepares the recommendation, and whose input is required. Confirm any budget or policy limits before presenting an option as available.
-
Set an input deadline and communication plan.
Why: Unlimited consultation can delay a decision without materially improving it.
How: Tell reviewers what feedback you need and when it is due. Name the people who must hear the final decision, even if they do not help make it.
Atlassian's DACI decision-making framework separates the Driver, Approver, Contributors, and Informed roles. You can use those labels or simpler equivalents; the useful distinction is between moving the process forward, making the decision, advising, and receiving the result.
If authority is genuinely shared, state the approval rule explicitly. Do not hide a required joint approval behind a fictional single owner.
Use a one-page structure with clear evidence labels
The following is a practical template rather than a mandatory standard. A page is a useful constraint, not a reason to shrink the text until nobody can read it.
| Memo field | What to write | What to avoid |
|---|---|---|
| Decision and deadline | The exact choice and required date | A general topic with no question |
| Owner and preparer | Who decides and who coordinates | “The team” with no authority defined |
| Recommendation | Preferred option and main reason | A recommendation buried at the end |
| Options | Credible alternatives, including no change | A deliberately weak alternative |
| Evidence and uncertainty | Known facts, estimates, assumptions | Estimates presented as measurements |
| Trade-offs and limits | Costs, risks, exclusions, dependencies | Benefits without consequences |
| Action and review | Next owner, timing, success and stop signals | “Monitor progress” with no definition |
Add a status line such as “Draft for input,” “Awaiting approval,” or “Decided.” Put the decision date beside the final result so readers do not mistake a proposal for an instruction.
Label evidence in ordinary language. “Observed” can introduce a support-log count; “estimated” can introduce an expected effort range; “assumed” can introduce an untested explanation. Link the underlying source and note the period it covers.
Keep essential uncertainty on the page. Appendices are suitable for detailed calculations, not for hiding the condition that would reverse the recommendation. If a critical fact is missing, explain whether it must be obtained before deciding or can be checked safely during a limited trial.
Compare options without manufacturing certainty
Start with the outcome you want and the constraints you cannot ignore. These might include a fixed delivery deadline, a spending limit, accessibility requirements, or a contractual obligation. Apply the same constraints to every option.
Include the current approach where it is a real choice. “Do nothing” is rarely literally nothing: it may mean continuing support costs, accepting delays, or postponing another project. Describe those consequences without exaggerating them to favor the proposal.
Use criteria that matter to this decision. For a small process change, expected staff time, customer impact, reversibility, and learning value may be more useful than a complicated numerical score.
A scoring matrix can organize discussion, but its weights are judgments, not objective facts. If a slight change in weighting changes the winner, say the recommendation is sensitive to that assumption. Do not turn uncertain inputs into precise-looking totals merely to make the conclusion appear rigorous.
Separate the business case from the permission to proceed. An attractive expected benefit does not override a missing security review or a budget owner's authority. List unresolved dependencies and assign someone to close them.
Worked example: a limited onboarding pilot
Imagine a small software business deciding whether to add a guided onboarding session. Every number below is hypothetical and illustrates memo writing, not a benchmark or a forecast.
Decision: Approve or decline a four-week pilot of optional guided onboarding for ten new customer accounts. Decision needed before the next intake opens.
Accountability: The customer-success lead decides within the approved staffing allowance. An operations coordinator prepares the memo, and support and product representatives provide input.
Recommendation: Run the limited pilot rather than changing onboarding for everyone. The main reason is to learn whether a short session addresses setup problems without committing to a permanent service.
Options: Keep the current self-service process; offer the limited pilot; or provide sessions to all new accounts immediately. The last option requires more staff capacity before the team understands demand.
Evidence and assumptions: In a hypothetical review of twenty recent support conversations, eight included a setup question. That does not establish that eight distinct customers were blocked or that a live session would solve their problems. The memo therefore treats demand for sessions and their effectiveness as assumptions.
Resource estimate: Ten sessions at thirty minutes each require five hours of delivery. Allowing fifteen minutes of preparation and follow-up per session adds two and a half hours, for seven and a half hours in total. This estimate excludes scheduling overhead and no-shows, which the pilot owner will record separately.
Limits and review: Participation is optional, no new software purchase is authorized, and the pilot ends after four weeks unless renewed. Review completed setup tasks, customer feedback, staff time, and unresolved problems. Pause new bookings if the agreed staffing allowance is exhausted or a serious issue requires escalation.
Next action: If approved, the coordinator prepares the invitation and tracking sheet, then confirms capacity with support before invitations are sent.
The example makes a bounded choice without claiming that a small pilot will prove a causal effect. Its strongest outcome may be discovering which questions need better documentation rather than establishing that sessions should become permanent.
Run the review and record the actual decision
Send the memo before the discussion and ask readers to challenge facts, assumptions, missing options, and trade-offs. Ask for specific corrections rather than a general vote on whether the document feels persuasive.
During the discussion, resolve decision-relevant disagreements first. A dispute over a minor wording choice should not consume the time needed to examine a major dependency. If an unresolved fact could materially change the choice, the decision-maker can delay, narrow the scope, or approve a conditional next step.
Afterward, record the selected option, conditions, owner, and date. Preserve a short explanation if the final choice differs from the original recommendation. Inform affected people through the agreed channel and make clear which actions are now authorized.
Do not silently rewrite the old reasoning after results arrive. Add a dated update instead. A readable record should show what was believed, what was decided, and what changed.
Review outcomes without turning every decision into a debate
Choose a review date and observable signals before implementation. Use both a desired outcome and a boundary: what improvement are you looking for, and what cost or risk would make you stop?
Not every unfavorable signal requires reversal. A short-term fluctuation may be expected, while a breached safety or compliance boundary may require immediate escalation. Specify that distinction where it matters.
At review, compare actual results with the assumptions in the memo. Was the action completed? Did the intended benefit appear? Was the resource estimate reasonable? What did the team learn that would affect the next choice?
Close the loop by continuing, adjusting, expanding, or stopping the action. Give the follow-up its own owner. Otherwise, a review meeting can become another discussion with no operational consequence.
Questions About Decision Memos
Does a decision memo replace a meeting?
Sometimes. A clear, low-contention decision may be approved asynchronously. Hold a discussion when material disagreements, dependencies, or sensitive issues need direct attention; the memo makes that conversation more focused.
What if the evidence is incomplete but the deadline is fixed?
State what is unknown and how it could affect the choice. Consider narrowing the commitment, adding conditions, or choosing a reversible step. If proceeding would breach a required safeguard, a deadline is not a substitute for approval.
Should everyone sign off on the memo?
Only where the actual governance requires it. Otherwise, distinguish requested input from approval authority. Silence should not be treated as formal consent unless an explicit, appropriate process establishes that rule.
How should confidential details be handled?
Use approved access controls and share only what each audience needs. A broadly circulated memo can link to a restricted supporting record rather than copying sensitive personal, commercial, or security information into the main page.
Record the Choice and Its Evidence
A good decision memo makes the choice, reasoning, accountability, and review conditions easy to find. Its value comes from enabling a clear commitment and an honest follow-up, not from achieving a perfect page layout.
Next steps: Put larger choices into your strategic planning process, clarify the relevant competitive advantage, or explore more guides in Strategy.
Sources
- Atlassian — DACI: Decision-making framework
- Amazon — 2016 Letter to Shareholders
This guide is general education, not professional business, legal, or financial advice.