A branching decision diagram leading to a decision card beside a clock and pen.
Product Management,  Productivity & Collaboration

Stop reopening the same product decision: use a six-part decision log

The team has discussed the same question three times. Everyone has contributed. Nobody is sure who can decide, what is still missing or when the conversation ends.

A decision log is a short record of a choice and the reason behind it. Its value starts before the decision: it helps you name the question, identify who owns the choice and agree what evidence is needed.

Use it for decisions that affect several people or are likely to be reopened. You do not need a new process for every small task. The aim is to make the next conversation more useful.

Separate the question from the proposed solution

“Can we add a dashboard?” starts with a feature. “How should support staff find unresolved requests before handover?” starts with the problem. The second question leaves room for a smaller change, a manual step or an improved view in an existing tool.

Write the question in one sentence. Add the outcome you want and the constraint that matters most. For example: “Choose a way for support staff to find unresolved requests before handover, using the current system this month.”

The six parts of a useful decision record

  • Question: the choice we need to make.
  • Owner: the person authorised to make it, within an agreed boundary.
  • Options: credible alternatives, including keeping the current approach.
  • Evidence and gaps: what is known, where it came from and what remains uncertain.
  • Decision and trade-off: the selected option and the downside accepted.
  • Review trigger: new evidence or a date that would justify reconsidering it.

Contributors provide expertise and challenge assumptions. The owner considers that input and makes the choice within their authority. Record who needs to be informed so the decision reaches the people implementing it.

Work through a small example

In this fictional example, a team is choosing how to improve support handovers. Option A is a new dashboard. Option B is a saved filter in the existing system. Option C is keeping the current spreadsheet for now.

Two observed handovers suggest that finding unresolved work is difficult. They do not establish that a dashboard is the answer. The saved filter might be quicker to try, but it may omit information the spreadsheet currently contains.

A useful record might say: “The support lead chooses a one-week trial of the saved filter. The team accepts that extra context remains in the existing notes. Review after three handovers, sooner if an unresolved request is missed.” These are illustrative criteria, not measured results.

Choose the next move

The team cannot agree between the dashboard and the saved filter. Open the situation that best describes the disagreement.

The decision owner is unclear

Clarify authority before asking for another vote. Find the person who can approve the choice within the relevant constraints. If nobody present has that authority, assign a named person to obtain it and set a follow-up date.

The team disagrees about whether the filter shows all open requests

This is an evidence gap. Inspect representative records and compare the results. A short check may resolve more than another meeting about preferences.

The filter works, but people value different trade-offs

State the trade-off explicitly: quicker trial versus a richer interface. Ask the owner to decide against the agreed outcome and constraints, recording why the downside is acceptable for now.

Use a meeting to finish a specific piece of work

Send the question and options in advance. Ask attendees to bring missing facts, constraints or a credible alternative. During the meeting, distinguish a question about evidence from a preference and a constraint from a habit.

If you cannot decide, record the exact missing item, who will obtain it and when the choice will return. “Needs more discussion” does not tell anyone what to do next.

For irreversible, costly or safety-sensitive decisions, involve the appropriate specialists and governance. A short log supports that process; it does not replace approval or technical review.

Reopen a decision for a reason

A log should make change possible. If the trial misses requests or a constraint changes, reopen the choice with that new information. If nothing material has changed, point back to the reason and review trigger before repeating the whole debate.

AI can help tidy a record or list questions to investigate. Check it against the meeting notes. Do not let it invent agreement, assign authority or turn a suggested option into a recorded decision.

For your next recurring discussion, fill in the question, owner and review trigger first. Those three lines often expose why a decision is waiting. Then share the complete record with the people affected.

Further reading: Atlassian Team Playbook: DACI roles.

This six-part record is a practical Coded Female exercise. It is not a replacement for your organisation’s decision policy.

Leave a Reply

Your email address will not be published.