Structural Redesign for Product Organizations
You already fixed this once. It came back.
I find what in your product organization's structure produces the problem you keep fixing, give you the evidence that justifies changing it, and redesign it with you — so the fix holds after I leave.
The reorg that didn't stick. The framework that made things slower. The coaches who left, and everything went back to how it was. These aren't execution failures. They're structural outputs.
The problems that keep coming back aren't execution failures. They're structural outputs — a structure you can diagnose, then redesign.
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 — including, where you need it, the work itself: product management and engineering rebuilt as one stream, hands-on with your teams. The test: when I leave, your team reads the structure better than when I arrived.
Four symptoms of the same structure.
None of it is an execution failure. Each is a structural output the system was built to produce — and a structure you can diagnose, you can redesign.
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. You decide with evidence in hand instead of repeating the last attempt on faith — and the brief is yours regardless of what you decide.
For practitioners building structural thinking skills: 1:1 mentoring and team workshops. Ask about mentoring →
Why me
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 — the most business-critical system in the bank — 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 them.
AfterA team of teams now develops the platform 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.
I spent more than 10 years inside product organizations that kept hitting the same structural walls. My diagnostic practice came from refusing to treat those walls as execution problems. I speak and mentor regularly at conferences, among them LeadCraft, LeSS Conference, Agile Prague, and the Engineering Leadership Conference.
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.
Two questions worth thinking about before we talk.
No funnel. The answers tell me whether the decision brief would actually help you.