When a team discusses a change to a release date, the date has not changed. When they agree it should change, it still has not changed. It changes when the right person — the one who owns the consequences — says yes, in writing, with a date attached.
Product Owners sit at the intersection of these three states. That is the problem.
Discussed is not agreed. Agreed is not committed. Treating them as the same thing is how release dates drift before anyone with authority has said yes.
What happened in the retro
The episode was small, which is why it is useful. A retro produced a suggestion: move the payment release from Thursday to Wednesday. The team discussed it. It sounded sensible — fewer deployments colliding, slightly more buffer before the weekend. The logic was sound.
But it was a suggestion raised in a retro. It had not been validated by the person who owns the release window. It had not been communicated to the stakeholders who had built plans around Thursday.
Here is what happens in those moments: the PO hears it, synthesises it, and starts relaying it. The instinct is efficiency. The idea sounds good, the room seems aligned, so why wait? Because the room seeming aligned is not a decision.
Why POs are especially vulnerable to this
The PO role puts you at the centre of information flow. You hear from engineering, from the business, from senior stakeholders — and you are expected to synthesise and relay quickly. That is the job.
But it creates a specific failure mode: you relay before the decision has been made. You start communicating a conclusion that has not been reached yet. And by the time the correction goes out, the wrong date has already landed in three calendars, one email thread, and a Slack message someone screenshotted.
The correction is never just a correction. It is a signal that someone does not have control of the release.
What do the three states actually mean?
Discussed means the idea was raised. People spoke about it. No one said no. This is not agreement — it is proximity to agreement, which is a different thing entirely. A discussed idea can disappear without trace. A committed date cannot.
Agreed means the relevant people have said yes in principle. There is alignment. But alignment is not authorisation. The decision-maker may still need to formally sign off, dependencies may need checking, and other teams may not yet know. Dates do not move at agreement — they move at commitment.
Committed means the decision has been made by someone with the authority to make it. It is in writing. Stakeholders have been informed. The calendar can be updated. Now you relay.
The gap between discussed and committed can be hours or days. In that gap, information leaks — often through the PO, often in the name of efficiency.
The discipline: label the state before you relay
I now label the state of every significant decision explicitly, and I do it in writing before anything gets forwarded.
“This was discussed in the retro. No decision has been made.”
“This is agreed in principle. Awaiting sign-off from [name] before any dates change.”
“This is committed. Release date is Wednesday. Stakeholders have been notified.”
Three sentences. Three very different implications for everyone reading them.
It sounds like overhead. In practice, it eliminates the class of error where a tentative retro discussion becomes a circulated date before the decision-maker has opened their laptop. It also protects you. When someone asks why the date changed — and someone will ask — the record shows exactly when the discussion happened, when agreement was reached, and when the commitment was made. Three separate events, documented separately.
One test before you forward anything
Before relaying a decision, ask: has the person with sign-off authority explicitly confirmed this specific change? Not nodded in a meeting. Not said “sounds good” in Slack. Explicitly confirmed.
If you are not certain, you are in discussed territory, not committed. Hold the message.
The release date does not move until the right person says it does. Your job as PO is to know which state you are in — and to make sure everyone else does too, at the right moment, not before it.
TL;DR: Discussed, agreed, and committed are three distinct states in any release decision. POs who conflate them end up circulating dates that have not been confirmed by the people who own them. Label the state of every decision explicitly before you relay it — it takes one sentence and prevents the kind of correction that erodes stakeholder trust.
