Vertical Missions over Functional Silos
Marv Gillibrand
Venture Builder (Startup & Scale) | xCPO (FTSE-250) | xMcKinsey | Product Leader
Principle
Structure is a product decision. It either accelerates value delivery—or it gets in the way.
Many organisations structure teams around what people do—frontend, backend, product management, design. This can be more efficient, easier to manage, and simpler to scale. But it rarely reflects why those people are there: to create value. Product is not a series of siloed stand-ups.
Organising around why they exist—the outcomes they own and the problems they solve, is often more effective, better for growth, and more aligned with how modern products actually succeed. Product is a team sport.
When teams are grouped by function but work is organised by feature or initiative, you get a tangle of handoffs, misalignment, and duplicated effort. Everyone’s busy — Jira boards full, stand-ups chatty — but stepping back, it doesn’t feel like you’re making progress. People get frustrated, context gets lost, and delivery becomes a game of assigned tasks and missed milestones.
Instead, we get better results when we structure teams around Vertical Missions—outcomes that matter, owned end-to-end by a cross-functional team. They don’t just ship things — they move the needle.
Your Team Is an Engine
Structure is like your product engine. It’s how you convert effort into forward motion.
And like real engines, you sometimes just need a gear shift (e.g. better autonomy), sometimes a tune-up (e.g. clearer goals), and sometimes a complete rebuild.
Change has a cost — coordination, uncertainty, people’s energy. It’s probably not worth doing an engine change if you’re just driving to the shops. But if you’re heading into a high-stakes race — or dragging a trailer up a mountain — it probably is. Your team structure should reflect and adapt to what kind of race you're running.
What org models could we use?
If you’re leading product or engineering, these are your levers. There’s no perfect model—but each suits a different challenge. Here’s a summary of the most common product delivery structures:
🔧 Functional Silos organised by discipline: product, engineering, design, data. Great for early-stage teams, deep craft development, hiring - however challenge of handoffs, lack of end-to-end ownership, fragmented goals
🧬 Domain-Oriented Design (DDD) aligned to technical/product domains (bounded contexts). Great for complex systems, clear service boundaries however challenge of over-optimisation around tech rather than users
🏗️ Platform / Enablement Teams that build internal products or infrastructure for others. Great for shared services, scaling delivery, internal reuse however challenge of unclear demand signals, risk of drift from user value
🧠 Communities of Practice (CoP) formed around common disciplines (PM, UX, Data). Great for quality, consistency, shared learning however challenge of acting like shadow management layers
🌍 Hub & Spoke where “hub” owns tools/strategy; “spokes” deliver in business units or geographies. Great for global/local product balance, regional variation however challenge of slow decision-making, strategy disconnects
📈 Value Stream Mapping where teams formed around end-to-end flow from idea → delivery → value. Great for Lean/Agile transformation, process optimisation however challenge of difficult to sustain without cultural change
🎯 OKR-Led Pods where teams form around specific quarterly OKRs rather than fixed product areas. Great for innovation, fast-moving priorities however challenge of lack of continuity, onboarding burden, knowledge loss
🚀 Dual Operating Model with split between “run the business” and “change the business” teams. Great for mature orgs with legacy systems, transformation agendas however challenge of siloed mentalities, conflicting incentives
Ledgerly: Reshaping the Engine
Let’s take our fictional fintech scale-up, Ledgerly, and show how this works in practice. They offer AI-powered accounting and tax automation for small businesses, growing fast across UK, EU, and US.
Current Org Setup
Result?
Activity everywhere, but progress feels slow. Teams are busy, but outcomes aren’t clear. Frustration is growing. Priorities change too often, and no team truly owns the result.
So they changed the engine…
Ledgerly restructured into Vertical Mission Teams aligned to real customer and business goals.
New Mission Teams
Each team is cross-functional—PM, engineers, design, data—and owns discovery, delivery, and improvement. Communities of Practice and Platform teams support from the side. They didn’t just change reporting lines. They changed ownership, accountability, and direction.
However...
No structure is perfect. Each model comes with trade-offs. You might combine several, or evolve over time.
Here’s where other models shine:
So yes—we mostly value Vertical Missions over Functional Silos. But above all, we focus on Value Over Everything.
More reading?
Over to you...
What kind of engine are you running right now, and is it still built for the race you're in?