Structural Diagnosis and Redesign for Product Organizations
You already fixed this once. It came back.
Together we find what in your product organization's structure produces the problem you keep fixing, build the evidence that justifies changing it, and redesign it so the fix holds after I leave.
The reorg. The framework that made things slower. The coaches who left, and everything went back to how it was. None of it stuck, because none of it touched the structure that produced it.
The problems that keep coming back aren't execution failures. They're structural outputs: a structure you can diagnose, then redesign.
I work with the people responsible for how a product organization delivers value: anyone able and willing to change how teams are organized, what they own, and how their work is measured. The title matters less than the mandate. We study the live system together: where coordination breaks, which structural conditions keep producing the same problems, and what your organization is actually optimized to do. Then we design what success looks like and reach it in milestones, never as one big bang. Where you need it, that includes the work itself: product management and engineering rebuilt as one stream, hands-on with your teams. Your people get better at seeing and changing the structure: that is why the fix holds.
Four symptoms of the same structure.
Four symptoms, one structure. Change what produces them, and all four lose their source.
The Decision Brief
Two to three days inside your product organization. We study how work actually flows and find what in your structure produces the problem that keeps coming back: the one your last fix was supposed to solve.
You get a written brief: what produces the problem, what it causes, what decision addresses it, and the risks of that decision. Not a deck you present and shelve: a decision you can defend. You decide with evidence in hand instead of repeating the last attempt on faith. The brief is yours regardless of what you decide.
One person, not a firm. The person in the interviews is the person who writes the brief and stands behind it.
Everything I see inside your organization stays between us. The two to three days cost your people a handful of interviews, not a reporting exercise.
For practitioners: in 1:1 mentoring you bring a live problem from your own organization, and we sharpen how you read the structure behind it. Team workshops, too. Ask about mentoring →
Most AI initiatives die in the gap between possibility and practice.
AI adoption is not a tooling problem. It is a structure problem, and it fails in three patterns. You probably recognize at least one. Most organizations live in all three at once.
H³ is one redesign for all three patterns: three days on site, then three to six months of real work with named owners, then the cycle repeats. Each cycle compounds the last.
I am one of the Trusted Coaches who deliver H³.
Where this has held
BeforeR&D organized by specialty. Every feature crossed five team boundaries. Product managers spent more time negotiating between teams than understanding customers.
AfterCoordination layers dissolved because the conditions that required them no longer existed. Teams now own their own hiring, promotions, and escalation.
Case study on less.works ↗BeforeFive million lines of the system, owned component by component, in places by single individuals, each responsible for a fragment of the code. Integration was tested by hand; every release meant coordinating dozens of separate owners.
AfterA team of teams now develops it as one product, whole and end to end, with continuous integration as a way of working, not just a pipeline. The bank later adopted the approach company-wide as its Product Design Engineering model, which I co-designed.
Named reference available on request →
For fifteen years I watched product organizations hit the same structural walls from the inside. My diagnostic practice came from refusing to treat those walls as execution problems. I speak and mentor regularly at conferences, among them LeadCraft, the LeSS Conference, Agile Prague, and the Engineering Leaders Community (ELC).
For your conference or an event inside your company: Invite me to speak →
Each article names a specific mechanism most organizations can feel but haven't named.
A free 30-minute call is the fastest way to find out whether this fits.
No funnel. We take the problem that keeps coming back and decide together whether the decision brief would help.