The Product Systems Audit: what I look for in the first five days with a client

The Product Systems Audit starts before the fix, at the point where I need to find out what the product problem actually is.

That distinction matters. A team usually arrives with symptoms: slow shipping, weak adoption, repeated QA issues, missed business outcomes, roadmap drift, or a product that no longer behaves like the founding team intended. Those symptoms are real, but they are rarely the whole problem.

The audit is the work of finding the structure underneath them.

What the first day is actually for

Day one is not a kickoff in the ceremonial sense; it is intake.

I am trying to understand how the team really operates: who makes calls under pressure, where decisions go to stall, how far strategy travels before it becomes a ticket, and what the distance is between the person setting direction and the person building the thing.

The useful questions are operational. Walk me through the last feature that shipped late. Show me what a ticket looks like when it enters the sprint and what it looks like when it leaves. Tell me about the last disagreement over product direction and how it was resolved. Describe the week before the last major delivery issue.

Those questions produce a clearer picture than a polished roadmap review because they move the conversation from intention to behavior.

I am also establishing access: to the product, analytics where available, delivery artifacts, decision records, and communication context if the team is comfortable with that. The goal is observation, not surveillance. The way a team communicates often reveals as much as the content of the communication itself.

Days two through four: the deep dive

The diagnostic phase maps the places where intent moves from one state to another.

The first layer is flow structure. What are the core user flows, where do they break down in practice, and what states does the product move through before the customer feels the outcome?

The second layer is handoff architecture. Where does work transfer between people, and what does that transfer contain? A good handoff moves reasoning, constraints, ownership, and ambiguity. A weak handoff moves a task and leaves the next person to reconstruct the rest.

The third layer is ownership. For the decisions that matter, who owns them in practice? Not in the org chart, but on a Tuesday evening when a trade-off has to be made and the team cannot wait for a perfect answer.

The fourth layer is delivery pattern. I want to see what the team’s shipping history actually shows across several months: where work stalls, what comes back from QA, how much work is new versus rework, and which classes of problem repeat even after the team has already tried to fix them.

I am looking for the point where the system fails and individuals compensate with effort, which works until the organization gets too complex for effort to cover the gap.

Days five through ten: synthesis

The synthesis phase turns the diagnosis into material the team can use.

The first output is an execution-system audit: a mapped account of workflow, state model, handoffs, ownership, and delivery cadence, with findings annotated where the structure is failing.

The second output is a constraints and ownership map. This shows who owns what, where dependencies sit, and which gaps create risk because nobody clearly holds the decision.

The third output is a prioritized action plan. It should not list everything that could be fixed or become the longest possible set of improvements. The useful plan names what needs to change first, in what order, and why that sequence creates the most movement.

The fourth output is an implementation brief. When appropriate, this includes acceptance criteria and next-step tickets written tightly enough that the team can act without another round of interpretation.

The final day: readout

The readout is a working session, not a performance.

I walk through the diagnosis and the team pushes back where they disagree. They should push back. I have been looking at the system for days, while they have been living inside it for months or years.

That pushback is useful in two ways. Sometimes it shows that I have misread something and the finding needs revision. Sometimes it shows that the team has normalized the problem for long enough that it no longer looks strange from inside. Both outcomes improve the diagnosis.

The plan that comes out of the readout should feel jointly owned. It is not my document dropped onto the team, nor is it the team’s existing story rewritten in nicer language; it should be an honest account of what is broken and what fixing it requires.

What determines the price

The price is determined by scope: how many surfaces need to be mapped, how many roles need to be interviewed, how many integrations and dependencies shape the product’s behavior, and whether the problem is bounded or systemic.

The current Product Systems Audit bands are:

• Focused Audit: one team or operating slice, one week, AED 15K-17K.
• Cross-Functional Audit: multiple stakeholders or handoffs, two weeks, AED 18K-22K.
• Comprehensive Audit: broader operating system, three weeks, AED 23K-25K+.

The engagement is fixed-price once scoped. No hourly billing, no pretending the problem can be priced honestly before the operating context is understood.

Book a scoping call