Business
Decision memos: how to turn evidence into a clear recommendation
Stefan Weiss
A decision memo explains a choice that needs to be made, the options worth considering and the recommendation supported by the available evidence. Its purpose is to help a named reader decide. A useful memo makes the trade-offs and remaining uncertainty visible before approval, then leaves a clear record of what was actually agreed.
That makes it different from meeting notes. Notes can preserve a discussion in the order it happened. A memo reorganises relevant evidence around the choice in front of the decision-maker. MIT's guidance for decision memos starts with audience and purpose, then recommends putting the main message first and reviewing the draft for clarity and accuracy. MIT Guidelines for Decision Memos
This guide focuses on ordinary product, project and operational decisions: what belongs in a memo, how to compare options fairly and how to use meeting evidence without turning a suggestion into an approved plan.
When a decision memo is worth writing
Use a memo when the reasoning needs to travel beyond the conversation in which it emerged. A stakeholder who missed the meeting should be able to understand the choice without replaying the entire discussion or guessing which remarks mattered.
Good candidates include a proposed change in project scope, a choice between two delivery approaches, a limited pilot or a decision to pause work. The common feature is a meaningful trade-off that someone has authority to accept.
Writing a full memo may add little value to a small, routine choice already covered by an agreed policy. At the other extreme, a memo does not replace specialist review, formal procurement or any approval process your organisation requires. Treat it as a concise explanation within that process.
Before starting, answer three questions:
What exactly can the reader approve, reject or send back for more information?
What makes this choice necessary now?
What information would change the recommendation?
If the first answer is unclear, narrow the question. If the third answer is “nothing”, check whether you are documenting an open decision or just announcing a conclusion already reached.
Decision memo, decision log, project brief or meeting summary?
These documents can work together, but they serve different moments in the work.
A decision memo supports a choice. It presents the recommendation, alternatives, evidence and conditions that should shape approval.
A decision log records the outcome. Once the authorised person decides, capture the accepted choice, owner, date and rationale. Keep proposed decisions separate from approved ones. Our decision log guide and template covers that ongoing record.
A project brief defines the work. It explains the intended outcome, scope, responsibilities and constraints. A memo might recommend a scope change; an updated project brief can then describe the approved work.
A meeting summary preserves the discussion's useful outcomes. It may identify an unresolved choice without doing the additional comparison needed to recommend an answer. See how to write a meeting summary when the immediate task is to capture what happened.
A practical sequence is discussion, evidence review, recommendation, approval and outcome recording. It is not necessary to create five documents every time. It is necessary to keep those states distinguishable wherever you record them.
What a useful decision memo contains
A specific decision and a responsible reader
Write the choice in terms the reader can act on. “Improve customer onboarding” is an ambition. “Approve a limited onboarding pilot before committing to a wider rollout” is a decision request.
Name the approver or decision-making group and the date by which a response is needed. Explain what happens if the decision is deferred. A deadline without a reason invites arbitrary urgency; a reason without a decision owner invites another discussion with no clear ending.
The first paragraph should give enough context for the reader to understand the recommendation. Supporting detail belongs later. This follows MIT's recommendation to organise the memo around its main message rather than the order in which the writer discovered the information. MIT guidance
The problem and the relevant constraints
Describe the situation that creates the choice. Include the constraints that could rule out an otherwise attractive option: available people, a genuine deadline, dependencies or a capability that is not yet available.
Separate those constraints from preferences. “The team would prefer to avoid a migration” is different from “the current contract prevents a migration this quarter”. The second statement needs an appropriate source; repeating it in a meeting does not verify it.
Keep background proportional. A reader needs the context that changes the decision, not a complete history of the project.
Viable alternatives, including the current course
Explain the alternatives that deserve serious consideration. Describe what each option would mean in practice, what it would require and what it would leave unresolved.
Include maintaining the current approach when that is a real choice. Doing nothing may preserve capacity, retain an existing cost or accept an unresolved problem. Make that consequence explicit so the recommendation is compared with an honest baseline.
Do not invent a weak alternative simply to make the preferred option look inevitable. If only one proposal is currently feasible, say why the other routes have been ruled out and which facts support that conclusion.
Comparable criteria and visible uncertainty
Compare each option against the same questions. For a pilot, useful criteria might be whether it answers the central uncertainty, fits available capacity and can be stopped without disrupting existing work.
A numerical score can help organise discussion, but a score is not automatically a measurement. Explain its basis. If capacity is only an estimate, label it as an estimate; if the cost is unknown, leave it unknown and name the next check. Do not replace a missing answer with a precise-looking number.
A recommendation with an honest trade-off
Explain why one option is preferable given the criteria. State what it sacrifices as well as what it gains. A reader should be able to disagree with the weighting of the trade-offs without having to reconstruct the entire argument.
For example, a pilot may answer a narrow question while delaying a broader rollout. That can be a reasonable recommendation, but the delay belongs in the memo. Hiding it until after approval creates a different decision from the one the reader thought they were making.
Conditions, the next action and a review point
Distinguish approval from implementation. If the approver agrees, who confirms the dependencies, who starts the work and what remains conditional?
Name the observation that would trigger a review. “Review progress later” is vague. “Review after the pilot interviews have been analysed, before inviting a second group” defines an event and a boundary. A calendar date may also help, but it should match the work rather than substitute for a useful review question.
A worked example: pilot first or launch more widely?
The following is a fictional scenario to show the reasoning. It is not a Weeve customer story, a benchmark or a recommendation for a particular company.
A small product team is considering a new onboarding session. A planning meeting identifies two facts to verify: whether the support team can run the sessions and whether the session addresses the confusion raised in recent interviews. One person proposes a broad launch; another suggests a limited pilot.
An unhelpful memo might say: “Everyone agreed the new onboarding approach will improve activation, so we should launch next month.” That sentence invents agreement, assumes an outcome and obscures the capacity question.
A more useful opening is: “Approve a limited pilot of the proposed onboarding session, conditional on a confirmed support owner. The pilot should test whether participants can complete the first task without additional explanation. A wider launch remains a separate decision.”
The memo would then compare three viable routes:
Continue the current approach. This avoids introducing new session work, but leaves the reported confusion unresolved. The team can still improve written guidance while collecting better evidence.
Run a limited pilot. This creates a bounded way to examine the proposed session, while requiring someone to organise and review it. Results from a small pilot should not be presented as proof of every future customer's experience.
Launch the session more widely. This reaches more participants sooner, but commits more operational effort before the team has answered its practical questions.
The recommendation can favour the pilot because it addresses the uncertainty with a smaller initial commitment. That conclusion depends on the team's stated priorities; it is not a universal rule that pilots are always best.
Before sending, the writer checks whether the support owner has actually accepted the work. If not, the memo keeps that condition visible. The approver can accept the recommendation subject to confirmation, reject it or request the missing capacity information. Each response is more useful than an ambiguous “sounds good”.
Turn meeting evidence into a memo carefully
Meeting records can reveal options, concerns and constraints, but they are not automatically a finished analysis. Use them as a source set with boundaries.
Start with the relevant project and date range. Identify the discussion that introduced the proposal, any later conversation that changed it and the source of each material constraint. Prefer a narrow set you can review over a large collection whose coverage is unclear.
For each important statement, distinguish:
What the record says: the proposal, observation or commitment that can be traced to a source.
What the writer concludes: an interpretation of that evidence.
What remains to check: a missing figure, unresolved objection or unconfirmed owner.
If two meetings conflict, keep the conflict visible until you establish whether a later decision replaced the earlier one. A newer transcript is not automatically an approved change. Check who spoke, what authority they had and whether they were deciding or merely exploring an option.
A missing search result also needs careful wording. “No matching passage was found in the recordings reviewed” describes a bounded check. “Nobody raised a concern” claims complete knowledge of a much larger conversation.
Use Weeve to prepare the evidence, then review the recommendation
Weeve's library chat can work with saved recording material and return linked sources. You can use it to gather relevant passages and draft a document, then inspect the sources behind important statements. The workflow depends on the recordings and content actually available in the library.
A focused request might ask for the alternatives discussed in a named project's recent meetings, the reasons given for each and any unresolved questions. Ask for a source beside each material point. First review that evidence; then ask for a recommendation draft that clearly labels proposals and missing information.
This native Weeve capture uses synthetic demonstration content. It shows a transcript link and a summary link as distinct sources. A summary is useful for orientation, but check the underlying passage when the memo relies on exact wording, attribution or a commitment.
Our guide to Weeve chat explains the product context. Treat a generated recommendation as a draft for human judgement. Source links make checking possible; they do not certify that an interpretation is correct or that every relevant meeting was included.
Copy the reviewed document into your normal approval process. Drafting a memo does not send it, approve the choice or update a task system. If you choose an optional external AI provider, that provider's processing is separate from a local workflow; consider the selected provider before using sensitive meeting material.
Review the memo from the approver's perspective
Read the opening without the rest of the document. Can the reader identify the requested choice and the recommendation? Then inspect the evidence without the recommendation. Would the alternatives still look fairly represented?
Check these points before sharing:
The decision owner and response deadline are explicit.
The recommendation answers the decision that was actually posed.
Alternatives use comparable criteria and include a credible baseline.
Facts, estimates, assumptions and proposals are distinguishable.
Important claims have inspectable sources and unresolved conflicts remain visible.
The main trade-off and conditions for approval are clear.
The first action has an owner, or is explicitly awaiting one.
There is a useful review point and a way to record the final outcome.
If the memo still needs a long spoken explanation, identify what is missing from the page. It may be context, a hidden assumption or a recommendation that is broader than the evidence supports. Add that missing reasoning rather than filling the memo with more background.
What happens after the decision?
Record whether the recommendation was accepted, rejected, deferred or accepted with conditions. Preserve the version the approver reviewed and connect the outcome to the next work. If a condition changes the scope, reflect that change in the project brief and action record.
Do not silently rewrite the old recommendation to make it match what happened later. A useful record preserves both the reasoning available at the time and the outcome that followed. When new evidence changes the decision, add the new rationale and link it to the earlier record.
Start with one unresolved choice from your current work. Write the decision request, identify the approver and separate what you know from what you still need to check. Those three steps give the memo a useful purpose before you begin polishing its prose.
