The OAC Fellowship’s Product Development track makes this connection explicit. It teaches the full toolkit of lean product development — Architectural Linkage Diagrams, Set-Based Concurrent Engineering, Design Structure Matrices, trade-off curves, obeya governance, and DRBFM — as methods for developing products. But it simultaneously teaches executives to recognise that these same methods apply to designing how their organisation works. An Architectural Linkage Diagram maps how strategic positions connect and where architectural shifts are moving an industry. A Design Structure Matrix reveals where coupling between functions creates coordination burden or sequencing traps. An obeya makes the decision narrative visible in one place so that convergence happens through logic rather than hierarchy. These are not product-specific tools. They are design tools. And an organisation is a designed thing, whether its leaders treat it as one or not.
This reframes what lean means at the executive level. Lean has been understood primarily as an operational discipline — eliminating waste, improving flow, standardising work, solving problems at the gemba. That understanding is correct but incomplete. At its origin, lean is a design discipline.
The most sophisticated product development systems in the world — Toyota’s among them — operate on a principle that most executives never apply to their own organisations: don’t converge on a single solution until evidence tells you which solution works. Set-Based Concurrent Engineering holds multiple design concepts alive, tests them against constraints and trade-off curves, and narrows progressively as knowledge accumulates. The discipline is not indecision. It is the refusal to let preference outrun evidence. This is precisely the discipline that organisational design lacks. Most executives inherit a management architecture and modify it incrementally — adding a reporting line here, restructuring a division there — without ever treating the organisation itself as a design problem that deserves the same rigour applied to designing a product.
The Toyota Production System was designed.The management architecture that connects them — hoshin kanri, daily management, the chief engineer system, knowledge capture through engineering checklists — was designed. The executives who built these systems were not doing operational improvement. They were doing organisational architecture, using design thinking to create the conditions within which operational excellence becomes possible.
The OAC Fellowship recovers this executive-level interpretation. When a participant learns to run a Compositional Hoshin — holding multiple strategic observations across seven categories before allowing objectives to emerge through combination rather than declaration — they are practising the same anti-premature-convergence logic that SBCE applies to product concepts. When they build an Architectural Linkage Diagram that maps their organisation’s position on the modular-integral scale against their industry’s architectural trajectory, they are doing the same work a chief engineer does when mapping product architecture against customer value and manufacturing capability. The intellectual muscle is identical. The domain of application shifts from product to organisation.
This is not an analogy. It is the same discipline operating at a different level of the system. Executives who develop this capability stop asking how to improve their organisation and start asking how to design it — which is the question that lean was always answering, long before it was reduced to tools on a factory floor.
Architectural Principles
Fields of Practice
theme
1
Optimising Product Deployment using Compositional Hoshin
— building strategy from distributed evidence through Compositional Hoshin rather than declaring intent and cascading it downward. Operational Video-based Observational Analysis for Product Development.
theme
2
Compositional ALD for long-term Product Prospecting
— using the architectural categories to prospect where the industry’s product architecture is moving on the modular-integral scale, contextual categorisation, and positioning product platform decisions against that trajectory.
theme
3
Set-Based Concurrent Engineering Architecture
— holding multiple design concepts alive and converging by evidence rather than preference, and recognising this as the same discipline that Compositional Hoshin applies to strategy.
theme
4
Design Structure Matrix and Interface Management
— revealing coupling between functions, identifying sequencing traps, and designing coordination architecture that manages integration complexity.
theme
5
Greenfield versus Change-Risk Tool Selection
— distinguishing when to use exploration tools and when to use protection tools, and understanding the transition point where a baseline becomes good and DRBFM enters. Operations Pair Design Reviews & Architectural Design Councils.
theme
6
Obeya as Decision Architecture
— designing the visual governance space where the decision narrative becomes visible, convergence happens through logic, and all levels of the development system connect through the use for strutted A3 thinking and Integration.