GTM meeting decision log that people will actually read

GTM meeting decision log

Meeting notes record what people said. A decision log records what the team chose and what changes because of it. Keep the log separate from the transcript so a seller, marketer, or product owner can find the current answer without replaying the whole discussion.

Each entry needs the decision question, driver, approver, date, chosen option, brief reason, assumptions, affected work, and next review trigger. Write the question before the meeting when possible. A vague topic such as launch messaging does not tell the approver what must be settled.

The entry has one job

Assign one person to write the outcome while participants are present. Read it back in plain language. This catches differences between agreement on a direction and agreement on a specific action. If no decision was made, record the missing input and owner instead of manufacturing consensus.

Link the evidence considered, but keep the entry readable without opening six files. State the reason at the level needed for future work. We chose option B because the segment evidence is stronger is useful only when the linked evidence and relevant segment are named.

Link the consequence, not a second task list

List the tasks, assets, metrics, and teams affected by the decision. Give each follow up an owner in the normal project system, then link back to the log. Do not create a second hidden task list inside meeting notes. The log explains why the visible work changed.

Notify people who need the result, not everyone who once attended the meeting. A short message should state the choice, consequence, and link. If a sales play, campaign, or product promise changes, name the controlled source that will be updated so old guidance does not remain equally findable.

Append reversals instead of editing history

Some decisions should carry a review date or trigger, such as new evidence, a failed experiment, or a product release. When the team changes direction, add a new entry and link the earlier one. Do not edit the old record until it looks as though the team always knew the answer.

Periodically archive entries that no longer guide active work, but keep their links stable. Look for repeated reversals caused by missing evidence or unclear authority. That pattern belongs in the operating review. The log itself should remain a quiet, dependable account of choices already made.

Audit the log for recurring indecision

A cluster of reversals may point to missing evidence, a vague approver role, or a review trigger that arrives too late. Inspect that pattern during the operating review. Keep the log itself factual. It records choices; it does not need to defend the team from every earlier uncertainty.

Sources

1. DACI Decision-Making Framework, Atlassian Team Playbook. Provides a role model for drivers, approvers, contributors, and informed stakeholders in team decisions.

Related GTM guides

• Product launch stakeholder tracker
• Small team pipeline hygiene

Frequently asked questions