Why your product audit changes nothing
(and how to fix that)

An audit report landed in my inbox last week. Forty-two pages. Polished cover, numbered contents page, colour diagrams. The client sent it over and asked me what I made of it. The report was nine months old.

Not a single recommendation had been acted on.

This is not the exception. It is the norm. From the feedback I gather on my own engagements, more than 70% of commissioned audits produce no measurable change in the six months that follow. The money is spent, the report is delivered, and the organisation settles back into its natural motion — as if nothing had happened.

Here is what goes wrong, and how to put it right before you even start.

Mistake No. 1: auditing without a real sponsor

The first question to ask before accepting an audit engagement is not “what is the scope?” but “who is going to own the decisions that come out of it?”

Half the time, the audit is commissioned by someone with no authority to change anything. A product director looking to legitimise a decision that has already been made. A CTO trying to win over the board. A middle manager hoping that “the external report” will move the people above them.

Those audits are doomed from the outset. Not because the recommendations are bad, but because no one owns them who has both the power and the will to act.

Before you start, get in writing the name of the person who will make the decisions, the list of decisions they are authorised to make, and the date by which they commit to responding to the recommendations.

If you cannot get those three things, the audit is not worth doing. Not because the diagnosis would be useless — but because it will change nothing.

Mistake No. 2: trying to cover everything

The exhaustive-report syndrome. The auditor wants to show that they have seen everything, analysed everything, documented everything. The result: a 60-page document with 47 recommendations, not one of them prioritised.

The recipient opens the file, scrolls through the pages, closes it again. They have no idea where to start. And since everything has to start at the start, they never start.

A useful audit covers less, not more. It identifies the central systemic problem — the one whose resolution unblocks everything else — and builds a realistic 90-day action plan around it.

The rule I apply: three priority recommendations, maximum. Not three areas. Three concrete actions, each with a named owner and a date.

Mistake No. 3: delivering a report instead of a decision

An audit report is a passive object. It documents. It does not act. The trouble is that organisations treat deliverables as ends in themselves.

“You've delivered the report? Great, the engagement is finished.” No. The engagement is finished when the first decision has been taken and its execution has begun.

The debrief is not a thesis defence. It is a decision meeting in disguise. It has to end with:

• A formal decision taken on every priority recommendation (yes / no / later, with a date)
• A named owner for every action that has been accepted
• A follow-up date 30 days out, blocked in the calendars before anyone leaves the room

If the meeting ends with “thanks very much, we'll give it all some thought”, the audit is dead.

The structure that works: ORCA

Here is the framework I use to structure my audit reports. Four layers, in order.

O — Observation

What you can see, objectively. No interpretation yet. Facts: the backlog holds 340 tickets that have gone unprioritised for more than 6 months. Sprint reviews pull 14 people into a 2-hour meeting of which 20 minutes are useful. New-user activation sits at 23% when the sector average is 41%.

R — Root cause

Why it happens. Not the first, obvious “why”, but the third or the fourth — the one that points at a systemic problem. A backlog of 340 unprioritised tickets is not a backlog problem; it is a decision-criteria problem: nobody knows what “prioritised” means in that organisation.

C — Consequences

What it costs, in measurable terms. Time lost per sprint, missed opportunities, revenue affected, technical debt piling up. Recommendations with no cost attached carry no weight in a leadership meeting.

A — Actions

The three things to do within 90 days. No wishful thinking. Actions with an action verb, an owner, a date and a measurable success criterion.

The debrief meeting: do not rush it

The debrief is the most important moment of the whole engagement. It is where the audit either becomes real or dies.

A few non-negotiable rules:

• Length: 90 minutes maximum. Beyond that, attention drops and decisions get postponed.
• The decision-makers have to be there in person, not on a video call from a train. Important decisions do not get made on a phone.
• The report is read before the meeting. Send it 5 days ahead with an explicit instruction: come with your questions, not your gut reactions.
• The first 30 minutes are for the facts (observations + causes). The next 60 minutes are for the decisions.
• Finish with a signed record of decisions, not a list of “actions to be discussed”.

The day-30 follow-up: the step everyone forgets

Even when the debrief goes well, even when the decisions are taken and the owners named, the momentum erodes. Day-to-day priorities take over again. Actions slip.

The day-30 follow-up is the only thing that prevents that. A 45-minute meeting, going through every accepted action one by one: done, in progress, blocked. For every blocked item, you name the obstacle and take a decision on the spot.

It is that meeting — not the report — that makes the difference between an audit that changes something and an audit that ends up in a Drive.

Next time you commission an audit, or run one yourself, ask yourself these four questions before you start:

1. Who is the sponsor with real decision-making power?
2. What are the three priority actions we want to trigger?
3. Will the debrief end with decisions in writing?
4. Is the day-30 follow-up already in the calendars?

If you cannot answer those four questions, the report will change nothing. And it will end up buried at the bottom of a Drive.

Also worth reading — The art of saying no to a feature request: the same triage discipline, applied this time to the requests that land every single day.