Leadership teams often sense that something in the product isn’t working as well as it should. Conversion is softer than it used to be. Releases take longer. Customers complain about things the team says are fixed. Different brands or markets behave in ways nobody can quite explain.
A product audit turns that feeling into a list of specific problems, ranked by what they cost the business. Done well, it’s one of the highest-return pieces of work a product organisation can commission. Done badly, it’s an expensive document nobody opens twice.
Signs it’s time for one
A new CEO, CPO or investor needs an honest picture of the product before setting direction.
Growth has stalled and nobody can point to why.
The platform serves several brands or markets, and they’ve drifted apart in features, quality or performance.
Delivery has slowed down and the team blames technical debt, without being able to say which debt, or what it costs.
You’re about to make a big bet, like a rebuild, a new market or a major integration, and want to know what you’re building on first.
What we look at
An audit should cover the product from the customer’s side and from the inside. On the customer side, that means the key flows end to end: signing up, onboarding, paying, getting support, coming back. Where people drop off, how long things take, what breaks on mobile, what the support tickets say.
On the inside, it means the data and the delivery. Is the tracking trustworthy enough to make decisions with? Do the numbers in the dashboard match the numbers in finance? How does work get from idea to production, how long does it take, and where does it wait? How much of the team’s time goes to planned work, and how much to firefighting?
For multi-brand and multi-market platforms, there’s a third layer: parity. Which features exist where, which brands are on older versions of shared components, and where local customisations have turned into maintenance costs.
What the output should be
The test of an audit is whether the leadership team can act on it the following Monday.
That means a short summary of the findings that matter, each with the evidence behind it and an estimate of what it costs: lost revenue, wasted engineering time, risk exposure. Then a ranked list of what to fix first, with rough effort for each, so the trade-offs are visible. Quick wins should be separated from structural work, because they need different decisions.
It shouldn’t be a long list of everything that could be better. Every product has hundreds of those. The value is in the ranking.
How long it should take
For most product organisations, two to four weeks is enough for a useful audit. Longer than that and the findings start going stale, or the work turns into a consulting project that’s more about the report than the decisions.
The team shouldn’t be disrupted much. An audit needs access to the product, the data, the backlog and a few hours with the right people. It doesn’t need weeks of workshops.
What to do with it
The most common failure we see is a good audit that nobody acts on. The findings get presented, everyone agrees, and three months later the backlog looks exactly as it did before.
Before commissioning an audit, decide who will own the follow-up and when the leadership team will review progress against it. Ideally, the first few fixes are already in delivery by the time the final findings are presented.
An audit is worth exactly as much as the changes it causes.
