Core offer
Product & Engineering Diagnostic
When you can no longer tell whether the problem comes from the team, management, product, technology, or the way people work, you first need to understand the system.
The mandate
A short investigation. A factual assessment. A plan for the next 90 days.
I set out to understand why the organization produces the results it produces today, where the real blockers are, and whether the way it works still fits what the company asks of it.
The diagnostic may confirm the CEO’s intuition. It may also contradict it. The problem may lie in the team, but also in the organization, the product, the decisions, or the interfaces between them.
The scope is Product & Engineering. If the analysis reveals a problem elsewhere — sales, strategy, governance — I flag it, along with what it implies.
- What is really going on?The organization as it actually works, not as it is described.
- Why?The few causes that produce most of the symptoms.
- What needs to change?The decisions that can no longer be put off, including the hardest ones.
- In what order?A realistic sequence, with owners and milestones.
How I work
Open in the analysis. Firm in the decision.
I listen without adopting. I separate facts, perceptions, hypotheses, and interpretations, and I compare what the CEO thinks, what managers and teams say, what they actually do, and what the technical artifacts show.
Getting into the teams
I meet the key people, let them talk, and observe how they interact.
Seeing the real work
Stand-ups, product and engineering meetings, coordination, planning, releases, client relationship.
Going down to the product
When needed: code, architecture, deployments, quality, and development cycle.
Making the system visible
People, responsibilities, flows, dependencies, and breaking points.
From symptoms to causes
Form hypotheses, test them with people, look for contradictions, prioritize.
Deciding and sequencing
The trade-offs the CEO has to make, and a realistic order of execution.
What you receive
A document built for deciding.
Not a maturity report. Not a list of recommendations. Four concrete elements to move from assessment to action, presented in a readout with the CEO.
System map
Teams, responsibilities, flows, dependencies, and breaking points as they actually work.
Symptoms ↔ causes
What is visible, what explains it, and what does not deserve to be addressed first.
Critical decisions
A few structural trade-offs, usually a handful: organization, responsibilities, product, or technology.
Action plan · 90 days
Sequenced actions, owners, and first checkpoints.
Engagement conditions
An investigation requires real access to the system.
To understand an organization, you need to be able to talk to the people who make it work and look at the artifacts that describe it.
Depending on the situation: access to the teams involved, meetings, product documentation, work management tools, code repositories, and the necessary technical environments. Financial information is requested only when it is useful to the diagnostic.
What I don’t do
No framework to roll out. No contractors to place. No dependency to create.
I don’t install SAFe because there supposedly has to be a method, I don’t supply developers through staff augmentation, and I don’t rent out technical leadership by the month. The diagnostic is for deciding; the transformation, if there is one, is for making the organization autonomous.
After the diagnostic
The engagement can end there. Or begin.
When the plan calls for hands-on support, I can stay on to lead the transformation with the teams until the new way of working runs on its own.