My focus has shifted dramatically from execution to strategy, specifically around how we organise for both endurance and explosive growth. The current landscape; defined by hyper-accelerated AI development and persistent economic uncertainty; mandates a new operating model. Simply put: our product organisation cannot afford to be a single, slow-moving monolith.
My career has taught me the power of strategic constraint. Whether it was a self-imposed constraint on my creative inputs for efficiency or a hard-coded budgetary constraint on a high-stakes broadcast platform, limits force clear, ruthless prioritisation. We must apply this principle to our structure. The solution is the ‘Two-Speed’ Product Organisation, designed to manage the paradox of needing extreme stability in core systems while needing to disrupt the market.
The challenge of monolithic strategy
The traditional product team is often pulled in a thousand directions. They must maintain a revenue stream, fix a critical bug impacting a Tier 1 client, and simultaneously investigate a new Generative AI partnership. This is a cognitive load a single team cannot manage effectively. The result is ‘innovation theatre’ where small, safe bets are favoured; the core product stabilises, but true, zero-to-one growth stalls.
We need to formally separate these mandates to enable maximum efficiency in both domains. The strategic judgement is in deciding where to draw the line; this is what I call the Integration Layer, but first, we need to detail the two engines that drive our market position.
The stability engine
The Stability Engine is our core business function. It is staffed by teams focused on measurable efficiency, reliability, and regulatory compliance. Their mandate is to secure and optimise the 90% of the business that generates the majority of our P&L. For a live broadcast enterprise, this involves meticulous oversight of low-latency systems, design system maintenance, and a rigorous, predictable release schedule.
The pace here is deliberate. Success is analysed on system uptime, cost-per-user metrics, and a reduction in technical debt. Critically, these teams are shielded from the high-risk, speculative nature of new AI model exploration. They are there to maintain the franchise; ensuring that when a successful innovation is ready to scale, it has a rock-solid platform to launch into. We organise this team for predictable, high-quality output; their work is the bedrock of our trust with enterprise clients.
The innovation lab: Constrained freedom
The Innovation Lab is a small, multidisciplinary unit dedicated to high-risk, high-reward product exploration. These teams are liberated from the maintenance and compliance burden of the Stability Engine. Their focus is solely on what a zero-to-one product could look like using new technology; for example, leveraging the latest foundation models for content classification or user personalisation.
The freedom is not, however, absolute; it is a *constrained* freedom. Their budget and time are intentionally tight. I mandate a strict three to six-month discovery and validation cycle. This constraint is essential for efficiency; it prevents endless analysis paralysis and forces the team to fail fast or find a scalable path to success quickly. We focus on minimum viable prototypes; not on production-ready code. Their success is judged not on profit, but on the potential market opportunity they unlock.
Managing the integration layer
The Head of Product’s most critical strategic task is not overseeing the day-to-day of these two speeds; it is managing the Integration Layer. This is the strategic process for safely graduating a successful, validated project from the high-risk Lab into the reliable pipeline of the Engine. The Engine teams cannot afford to be constantly disrupted by Lab experiments; and the Lab cannot spend its limited resources on making its prototype enterprise-ready.
The Integration Layer is a codified process; a clear set of criteria for technical debt, security posture, and market validation that a Lab project must meet before a formal, strategic handoff to the Engine occurs. This protects the Engine’s P&L focus; allowing them to scale a proven concept, not a theoretical one. It is a moment of clear, decisive leadership to ensure that our disruptive innovation is strategically scaled, minimising internal disruption while maximising market opportunity.
The ‘Two-Speed’ structure is not just an organisational chart change; it is a strategic commitment to managing risk through intelligent segmentation. By strategically constraining our core teams to stability, we liberate our innovation teams to chase market disruption; ensuring we are organised to win in the volatile years ahead.
Splitting the org into ‘Engine’ and ‘Lab’ is classic corporate overthinking, man. It’s just two silos instead of one. The Stability Engine team will always end up hating the Innovation Lab team because the Lab keeps breaking things and shipping them over the wall with zero documentation. Why not just staff the single team to run two concurrent, time-boxed processes? You just created a dependency hell that needs a middle manager to mediate. Good luck with that budget meeting.
Two-Speed model is genius. Stops the core team from chasing shiny objects. Protect the revenue stream first, always.
I work in very old company with complex legacy systems. This ‘Innovation Lab’ idea is not new, but naming the ‘Stability Engine’ is powerful. It gives dignity to the difficult work of maintenance. We must measure the Engine by its uptime and efficiency improvement, not by new feature count. This is how we keep the lights on and still experiment without risk. Thank you for this clear framing.
I agree with the core theory, but in practice, how do you handle the talent migration? Everyone wants to be in the “Innovation Lab” because it sounds sexier. The “Stability Engine” team becomes a graveyard of ambition. You need a dedicated, public career path for engineers who excel in stability and optimisation, otherwise the whole thing falls over when your best systems architects jump ship. Have you written about how you incentivise the Engine team yet? That’s the real challenge, surely.