Most organizations that call for an audit already know something is wrong — they just cannot say what, where, or how badly. The product team ships, the roadmap moves, everyone is busy, and yet the thing the business expected from the product does not show up in the numbers. An audit exists to convert that unease into a list of findings with evidence, a plan of action, and a realistic view of what turning things around will cost in time and people.
This service covers the three things that usually go together in that process: finding out what is actually wrong (audit), making the organization better at the relevant capability (improvement), and building up the people who have to carry it going forward (upskilling).
When it makes sense
- The product organization is not pulling its weight, and you need to know why. Not “are we Agile enough”, but: what is the team actually doing day to day, what are the real sticking points, and which of them are process problems, capability problems, or mandate problems? Those three require completely different fixes, and they are routinely confused.
- You are about to scale the product side, and the current setup cannot take the load. A pipeline that worked for five products will not work for fifteen, and the gap shows up as heroics, attrition, or both.
- A capability has to be built, not bought in. Sometimes the answer to “we need product management” is not a hire — it is upskilling the product experts you already have into product managers, which is cheaper, slower, and usually more durable.
- You need a neutral second opinion before a big decision. A technology migration, a reorganization, a new PMO: before the money goes in, someone who is not inside the political system should look at what the evidence actually says.
What I bring to the table
I ran a three-month product-management audit and consulting engagement for a Zurich-headquartered multinational manufacturer of software-enabled sensor and diagnostics equipment, as consultant at Noito: observing the daily operations of a team of product experts, compiling findings with plans of action, and working the team towards a setup fit for an ambitious pipeline and a push into more digital offerings. See the project entry for more.
I also coauthored the IMD article “Agile vs. death-by-committee” with Prof. Carlos Cordon — which is to say: I have been paid to be skeptical of change-management fashions on both sides of the aisle, and I bring that skepticism to your audit instead of importing it.
In practice, an engagement covers some or all of the following:
- The audit itself. Structured observation and interviews — with the team, not just about it — producing findings tied to evidence: what the team actually does, where work stalls, what the mandate really is, and where the capability gaps are.
- The plan of action. Sequenced, owned, and costed. Not a slide deck of twenty recommendations that nobody implements, but a short list of what matters, in what order, with the trade-offs made explicit.
- Upskilling. Working with the existing people — product experts, delivery leads, technical managers — to close the specific gaps the audit found, rather than importing a training catalog.
- Improvement that outlasts me. The measurable target is that the organization runs better after I am gone. Engagements are scoped so that the last deliverable is your team not needing the next one.
What an engagement looks like
Audits are typically the sharpest instrument in this service: four to twelve weeks, ending with the findings, the plan, and a working session where the organization commits to the first steps — because a plan of action that was never agreed to is just a report. Upskilling and improvement work then follow at the organization’s pace, in bounded phases with their own success criteria.
If you are not sure whether you need an audit or something else, that is exactly what the first conversation decides.
Start with a conversation about what is not working.
