Leaders are allowed to override Product recommendations. I want to start there because a PM can make a thoughtful recommendation and still not have the full picture. Someone with broader decision authority may understand a customer relationship, legal exposure, cash constraint, market signal, strategic obligation, or business commitment the team does not own. Sometimes the right decision is:
“I understand the recommendation. We are doing something else.”
That is not automatically dysfunctional. The dysfunction begins when the organization behaves as if the override was free.
“Leadership” depends on the decision
I also want to take some mystery out of that word. In this essay, leadership means whoever has legitimate authority to override the recommendation in that situation. Sometimes that is an executive or VP. Sometimes it is a director, a business owner, or a Product leader. And if you manage PMs or lead a Product area, sometimes the person making the override is you.
That matters because this is not an essay about protecting Product from some anonymous group called “them.” It is about keeping consequential choices visible no matter who makes them.
Overrides disappear surprisingly fast
Imagine Product recommends not building a custom customer request this quarter. Engineering is committed. The request will move a retention initiative. The solution is highly specific, and the underlying customer problem is still unclear. The decision owner hears the argument and chooses to do it anyway.
Fine. Three months later the retention initiative is late, and the conversation becomes:
“Why did Product miss the roadmap?”
The original tradeoff has vanished.
The sponsor remembers approving an important customer need. Engineering remembers being told to fit it in. Product remembers raising the risk. The organization now has several versions of history.
This is why overrides need a receipt.
A receipt is not “per my last email”
The word receipt can sound like cover-your-ass documentation. That is not what I mean. Everybody has seen the tactical version:
“Per our last conversation…”
or the meeting notes that quietly preserve one sentence proving somebody raised a concern. That kind of documentation is often written for a future argument. A decision receipt should be written for the current operating system. What decision changed? Who owns the decision?
What recommendation changed? Why? What work moves, stops, or gets delayed? What risk is being accepted? What customer or business commitment changed?
When should the choice be revisited? That is enough. For example:
“We are adding the custom reporting capability for Account X this quarter. The executive sponsor owns the override. The retention experiment moves from May to June. Two senior engineers shift for four weeks. We are accepting the maintenance risk as a customer-specific exception. Revisit generalization after renewal.”
Now the organization has memory.
The tone matters
There is a bad version of this practice. The PM writes a decision log that basically says:
“I told you so.”
Every line is designed to create future evidence that Product was right and leadership was reckless. Do not do that. A receipt is not a blame artifact. It is shared decision memory.
The tone should be neutral. The decision happened. The consequences changed. Record them.
And the same standard should apply when Product gets its recommendation approved. If we are serious about accountability, we do not document only the decisions we expect to fail.
The receipt protects everyone downstream
Most overrides affect people who were not in the room.
Engineering gets a new priority. Sales inherits a new promise. Support inherits a new expectation. Another Product team discovers its dependency moved.
If the change arrives only as:
“Leadership wants this,”
those teams experience the decision as random power. A short receipt gives them enough context to execute against the same reality.
This was the choice. This is why it changed. This is what moved. This is what remains protected.
The artifact does not make everybody happy. It makes the system legible enough that people do not have to invent their own explanation for what happened.
The person making the override should want the receipt too
A good decision owner should not be threatened by this. The receipt protects the decision from organizational telephone. It makes the tradeoff explicit to teams downstream. It prevents somebody from quietly restoring displaced work to the roadmap as though capacity never changed. It creates a cleaner basis for learning later.
If the override works, the organization can understand why. If it fails, the organization can inspect the assumptions without arguing about who said what. And if you are the manager or director overriding your own team, the same rule applies. You do not get to say:
“I made the call, but you still own all the original commitments.”
If your decision changed the bet, your receipt should make the changed bet visible.
This matters most under pressure
High-pressure decisions are the ones most likely to create memory problems.
A customer threatens to walk. A regulatory deadline appears. A board commitment changes. A security incident forces scope movement. Everybody is moving quickly, and people leave the meeting with slightly different interpretations.
That is exactly when one paragraph of explicit decision memory is worth the effort. Not a thirty-page governance process. A receipt.
Accountability should follow the choice
PMs are often accountable for outcomes without formal authority over every contributing decision. That is normal. But outcome accountability should not become a reason to erase upstream choices. If the person with legitimate authority knowingly changes the recommendation, the outcome model changed too.
That does not mean Product throws up its hands. You still execute. You still try to make the decision work. You still learn.
The organization simply preserves who made the tradeoff and what everyone believed at the time. That is healthier than retroactively assigning accountability to whoever happens to own the roadmap document.
The receipt can improve the system later
Over time, these decisions become useful evidence.
Which exceptions keep recurring? Which overrides were correct? Where were Product teams too conservative? Which risks repeatedly materialized? Which “one-time” commitments keep returning?
Maybe the recurring override reveals a missing strategic policy. Maybe Sales needs a clearer exception path. Maybe Product is underweighting a segment. Maybe the roadmap needs explicit capacity for customer commitments.
The receipt turns a conflict into something the organization can learn from. Leadership can override the recommendation. What leadership cannot do is change the recommendation and pretend the rest of the system stayed the same.
Something moved. A risk changed. A commitment changed. A person made the call.
Write that down. Then go make the best of the decision.