CompoundWorks helps deep-tech companies through critical product and scaling transitions. The more systemic and consequential the challenge becomes — across technology, architecture, organisation, ecosystem and trust — the more relevant the CompoundWorks approach becomes.
The work is configured on two navigable dimensions: what decision has to be made, and how deeply CompoundWorks needs to become involved. These are coordinates, not a mandatory sequence.
FORM, ASSESS and SCALE are different lenses on the same company or system. A situation can touch more than one. Choose the lens that best describes the decision in front of you.
From opportunity to product, business and system design. Clarify the wedge, product boundary, strategic moat, architecture and validation path.
Wedge · product boundary · system role · architecture · validation path
Create an executive, investment or system-level read before committing capital, scope or organisational change.
Scale readiness · maturity · diligence · integration risk · technology-system fit
Move from pilots to programmes, projects to platforms and founder-dependent execution to a system that can absorb more complexity.
Productisation · pilot-to-program · architectural runway · delivery system · trust runway
These are decision lenses, not stages. Many situations touch more than one.
The same apparent problem can require a very different intervention depending on the wider system the company is building or entering, and on whether the company can absorb the resulting complexity.
What kind of systems are emerging?
Looks outward at where technologies, actors and architectures are beginning to compound — and at how that convergence changes the system itself, its boundaries, value pools and conditions for differentiation.
The strategic thesis behind this lens is that AI, autonomy, simulation, spatial computing and digital twins are moving toward a new operational layer. Operational realities provide the shared context in which humans, organisations and machines can act; Operational Twins help compose that context; and spatial computing and digital twins increasingly become spatial infrastructure rather than isolated applications or representations.
The opportunity is not simply to combine technologies. It is to architect the system that becomes possible when they compound — and turn that emerging category into differentiated products, platforms and market positions.
What must the company become to operate there?
Looks inward at what happens when technological ambition, customer demand and system complexity begin to outpace the architecture, organisation and decision systems built to support them.
The Scaling System Maturity Framework (SSMF) reads that transition across three coupled dimensions — Technology, Organisation and Trust. It exposes the Scaling Trap: where something can work technically and win early customers, yet still fail to become a repeatable, trusted and scalable operational system. The critical crossing is often from managed execution to a company designed for scale.
The challenge is not simply to grow faster. It is to build the architecture, organisation and trust conditions that let the company absorb complexity without losing coherence.
Neither lens is sufficient alone. A more ambitious technology and market thesis changes the demands placed on the company, while the company's actual maturity constrains which parts of that future can credibly be pursued now.
Compound Innovation and Scaling Systems are not consulting abstractions. They emerged from repeatedly encountering the same problem from different sides: first building complex systems, then productising what repeated, then creating products at the convergence of technologies, and finally scaling their adoption inside demanding organisations.
Mission-critical defence and simulation programmes showed that the difficult part was rarely an individual technology. It was making established and emerging technologies operate coherently inside a larger system.
Repeated problem-solving patterns need to become reusable architectures, interfaces and delivery models.Turning repeated project patterns into a product platform created repeatability, but also made interoperability, architecture, governance and trust increasingly important.
Platform value appears when solutions connect; so does compound complexity.Combining AI, simulation, XR, digital twins and IIoT into new product and platform propositions showed how quickly value can compound when technologies converge.
Category creation fails when product, architecture, organisation and market narrative mature at different speeds.Working from the enterprise-adoption side showed that architecture alone does not make deployment repeatable. Customer success, delivery discipline, organisational readiness and trust have to mature with the platform.
Scalable technology requires a scalable operating system around it.Those accumulated lessons became the two faces of CompoundWorks. On the Architect side: the Compound Innovation Lens and the strategic thesis around Operational Realities, the Operational Twin and Spatial Infrastructure. On the Operator side: the Scaling System Maturity Framework, reading Technology, Organisation and Trust as one coupled scaling system.
CompoundWorks exists to connect both — to architect what should become possible and build the conditions that make it repeatable.
See Jose's track record →A technology category or company stage does not determine CompoundWorks fit by itself. What matters is the system around the decision: how many dependencies interact, how consequential the transition is, and whether product, architecture, organisation, ecosystem and trust can still be treated independently.
A provider serving industrial SMEs mainly in one country may primarily face a product-positioning, repeatability and GTM problem. Interfaces, procurement and deployment conditions remain relatively bounded.
The same underlying technology operating internationally across primes, ministries and regulated environments introduces interoperability, sovereignty, assurance, partner, governance and institutional-trust dependencies. What looked like a product problem becomes a coupled system transition.
Same core technology. Very different system. Very different intervention. CompoundWorks becomes more relevant as those dependencies become harder to separate and the consequences of getting the system design wrong increase.
See the general CompoundWorks fit →READ, RESOLVE, ADVISE and EMBED describe involvement, not stages. Enter where the decision and the required depth are already clear.
Create a bounded read of the situation.
Diagnostic · Review · DiligenceWork directly on a known, bounded problem.
Focused SprintStay alongside leadership as decisions evolve.
Strategic AdvisoryExplore Strategic Advisory →Step inside and take temporary operating responsibility.
Embedded Scaling Leadership · Fractional / InterimExplore Embedded Scaling Leadership →The smallest engagement that can answer the decision is the right starting point.Increasing depth of involvement — not a sequence.
A named service exists because a recurring buying decision has earned a dedicated expression — not because every coordinate in the model needs to be filled.
Shape the product, system role and path to a credible market position.
Define the wedge, product boundary and path to credible validation.
Explore Wedge & Product Runway →Decide where an external technology creates strategic value inside an existing system and what has to change for it to fit.
This engagement can also carry an ASSESS lens when the immediate decision is whether the technology should proceed.
Explore Technology-to-System Fit →Create decision-grade evidence before committing capital, scope or organisational change.
A 90-minute executive working session for a bounded decision.
€950 · 90 minutesExplore the Executive Diagnostic Session →When the real scaling constraint is unclear, go inside the system and identify the binding constraint, dependencies and what breaks next.
4 weeks · €6,000Explore the Diagnostic Sprint →Investment-grade assessment of whether traction is backed by a company that can actually scale.
Explore Investors & M&A →A comparative maturity view across a deep-tech cohort or venture programme.
See Cohort Maturity Benchmark ↓Resolve a known scaling constraint and make growth more repeatable.
Make the product, platform and delivery model repeatable as customer and integration complexity increases.
Explore Productisation & Platform →Turn a successful pilot into a repeatable deployment model, operating system and path to recurring value.
Explore Pilot-to-Program →When the problem is already known, work directly on one bounded capability without requiring a prior Diagnostic Sprint.
See the Focused Domain Sprints ↓Some decisions cannot be resolved responsibly in a bounded sprint. CompoundWorks can stay alongside the leadership team through Strategic Advisory, or step inside temporarily through Embedded Scaling Leadership when the transition needs senior operating ownership before the permanent organisation is ready.
Ongoing senior counsel across complex, coupled decisions.
Fractional or interim operating leadership for a critical scaling transition.
A Focused Domain Sprint is bounded, fixed-scope work on a known product, architecture, organisation, trust or market constraint. It does not attempt to diagnose the whole scaling system again. The sprint is configured around the decision to be made and the concrete system change or deliverable required.
Use a Focused Domain Sprint when the next problem is already visible — for example portfolio architecture, GTM/partner design, trust for a first institutional customer, or delivery structure. A Wedge & Product Runway Sprint is not a prerequisite.
Use a Focused Domain Sprint when traction is real and a specific product, architecture, organisation, trust or market constraint is already limiting repeatability. Use the Diagnostic Sprint instead when the real constraint remains unclear or coupled.
Use a Focused Domain Sprint when the required intervention is already clear — including after a Technology-to-System Fit Review identifies a concrete need such as composability redesign, deployment readiness or partner-model change.
Bespoke delivery or product structure is preventing the business from becoming repeatable.
Reusable core; product versus customer-specific boundaries; platform logic; architectural runway; roadmap sequence; delivery implications of the new product model.
The current architecture works, but the next product, integration or deployment context is likely to expose coupling or force disproportionate redesign.
Target architecture; explicit system boundaries; coupling and dependency decisions; integration model; sequence of architectural moves that preserves runway for what comes next.
Growth is creating coordination overhead because decisions, ownership or commitments still route through founders or a small number of senior people.
Decision rights; explicit ownership; team and system interfaces; escalation rules; delivery commitments; operating cadence that can hold under pressure.
Technical value is credible, but procurement, assurance, evidence or operational conditions are preventing confident rollout.
Trust and assurance gaps; evidence model; deployment conditions; governance and ownership; readiness sequence for moving from confidence in people to confidence in the system.
Each new customer, partner, region or deployment path still requires a materially different route to value.
Repeatable partner and deployment model; partner roles and interfaces; qualification criteria; market-entry sequence; scalable GTM path.
No mandatory diagnosis. If the problem is already sufficiently bounded, a Focused Domain Sprint can be the starting point. If the real constraint is unclear or coupled across several dimensions, use the Diagnostic Sprint instead.
Discuss a Focused Domain Sprint →"We need to compare technically strong ventures systematically and decide where intervention will create the most leverage."
Organisation, Decision & Delivery Architecture, Trust, Assurance & Deployment Readiness, and Market, Partner & Deployment Scaling are added according to stage and domain. Defence and dual-use programmes place greater weight on assurance, procurement, institutional trust and deployment readiness.
PROGRAMME LEVELThe same underlying scaling situation can surface through different mandate origins. This is descriptive metadata, not another navigable level.
They feel the constraint directly and want help to cross it.
They see a risk, leadership gap or value-creation opportunity in a portfolio company and sponsor or mandate the intervention.
They need an external technology or pilot to become operational inside an existing system.
Mandate origin can change the economics, governance and urgency of the work. It does not create a different service architecture.
If the decision is clear, let's talk. If it isn't, take the quick self-assessment to understand where you are now and what may be constraining the system.