What a Product Audit Looks At, and What You Should Get Back
What is a product audit?
A product audit is a structured review of your product, your backlog, your metrics and the way your team decides what to build. It ends in a written diagnosis: what is wrong, how serious each problem is, and what to do about it, in order. It is not a code review or a design critique, although it may touch both. Its focus is whether product work is aimed at the right things, and whether the team can tell.
An audit makes sense when something feels wrong but nobody agrees on what. Typical moments are when engineering is busy but results are hard to point to, or when a new leader wants an outside view before committing to a plan.
What does an audit look at?
| Area | Questions it answers |
|---|---|
| Product and users | Who the product is for, which job it does for them, and where users get stuck |
| Backlog | Whether the backlog reflects a strategy or a history of requests |
| Decision-making | Who decides what gets built, on what evidence, and how disagreements are settled |
| Metrics | Whether the team measures outcomes or only activity, and whether the numbers are trusted |
| Delivery | How work moves from idea to release, and where it waits |
| Roadmap | Whether the plan is sequenced for a reason the team can explain |
How is the evidence gathered?
An audit should rest on evidence, not impressions. Typical sources are interviews with founders, engineering, design, sales and support; a sample of customer conversations or support tickets; the backlog and its history; the roadmap and the decisions behind it; the analytics set-up and the definition of each metric; and a walk through the product as a new user.
Interviews are most useful when they ask the same questions across roles. When the founder, the engineering lead and the head of sales give different answers to "what is the most important thing we are working on?", that difference is often the most important finding.
What should you get back?
- A findings report with severity ranking. Each problem stated plainly, with the evidence behind it and how much it matters.
- A prioritised list of fixes. Not every finding needs action now. The list should say which ones do, and why.
- A 90-day plan. Concrete steps your team can take, with or without outside help.
- A readout session. A working session with the founders and engineering to go through the findings and agree what happens next.
The report should be yours from the day it is delivered, and written so that someone who was not interviewed can act on it.
What are the common findings?
Every product is different, but some patterns come up often.
- Too many priorities. When everything is important, engineering ends up choosing by default.
- Metrics that measure activity. Features shipped and tickets closed are easy to count and say little about whether customers are better off.
- A backlog nobody owns. Requests from sales, support and leadership land directly in the tracker without anyone deciding between them.
- Decisions made in private messages. Months later, nobody can say why something was built.
- Discovery that stops at launch. Features ship, and nobody checks whether they did what they were meant to do.
Audit, discovery sprint or fractional product manager?
These answer different questions. An audit asks what is wrong with how product decisions get made. A discovery sprint asks what to build first when the budget is approved but the team disagrees. A fractional product manager provides ongoing ownership of the backlog and roadmap, week to week. Starting with an audit is often the cheapest way to find out whether you need the others.
Our services page sets out each option, and our guide to the first month with a fractional product manager shows what the ongoing option looks like in practice. Our guide to what a discovery sprint produces covers the second option in detail.
How do you prepare for an audit?
Give the reviewer access to the tracker, analytics and roadmap on day one, book the interviews for the first week, and be ready to hear findings about leadership as well as about the team. An audit that avoids uncomfortable findings is not worth the time it takes.
Suspect the problem is how decisions get made rather than how fast the team ships? Our fixed-scope product audit ends in a written report and a 90-day plan. Questions about cost, timing and confidentiality are answered in our FAQ.