The Product OS: How To Build Product Organisations That Actually Work
A practical take on how I design and run product organisations — and why most companies don’t have a true Product OS at all.
Fair warning: this one runs longer than my usual posts. It’s the backbone of a new series on my Product Operating System, and I think it earns the extra word count. I’ll be drilling into each layer one by one with more actionable insights and activities in the articles that follow.
Most companies will confidently say they have a product strategy.
In reality, what they often have is a set of ambitions, a list of features, or a deck of nice-sounding statements. Not a strategy. And even when a strategy does exist, it rarely guides decisions, trade-offs or what to say no to. That’s a whole series on its own.
But even assuming a company does have a strategy, very few have something far more important — a Product Operating System. The thing that turns intent into actual behaviour, actual decisions, and actual outcomes.
And that’s where things break.
Without a Product OS, teams drift into what I think of as chaos wrapped in ceremony. Lots of meetings, frameworks and artefacts… but very little alignment, progress or truth. With a Product OS, everything that actually matters starts to compound: clarity, speed, learning, accountability and real defensibility.
This piece isn’t a blueprint or a “copy this and you’re done” model.
Every organisation is different. Every system inherits its constraints, incentives and quirks. Instead, this is my take — the way I design and run a Product OS after seeing the same patterns repeat across scale-ups, PE-backed companies, incumbents, post-acquisition tangles and early-stage teams still figuring out who they are.
Think of it as a flexible framework rather than a prescription.
A scaffolding you can adapt, expand or ignore depending on your context.
Whether you’re a product team of one, or a globally distributed team of a 100 - these principles still apply.
Next week, I’m continuing what is now becoming a full series, taking each layer of the Product OS and going deeper. I’m starting with the first — product vision. It’s a topic I’m personally passionate about, because when it’s done well, a vision isn’t just a rallying cry. It’s a practical instrument. It guides day-to-day decisions, anchors strategy and genuinely gets people excited about the journey.
Next week we’ll explore what actually makes a compelling product vision — but first, here’s the foundation the “Product OS” depends on.
1. Why Product Needs an Operating System (not just a strategy)
Last week I wrote about the Motte-and-Bailey problem in product — the widening gap between the story companies tell and the reality they actually defend. If you missed it, the short version is this: most organisations sell an ambitious narrative but operate from a very different legacy truth, and Product ends up carrying the friction.
That gap doesn’t close with better storytelling. Or excuses.
It closes with concious designing and planning. It closes with the help of a Product Operating System.
Strategy tells you where you want to go.
Your Product OS determines whether you can actually get there.
A Product OS is the connective tissue between:
ambition and capability
narrative and operating truth
strategy and incentives
learning and delivery
what the company says and what the product proves
Without that connective tissue, everything drifts. Teams make sensible local decisions that add up to global misalignment. Incentives pull people back to what they know. The “product strategy” then becomes optional background noise that doesn’t actually influence any decisions or direction.
And this matters more than ever. AI has accelerated expectations, compressed timelines and made execution brutally comparable. You can’t “sell the Bailey and drag the Motte along behind you” any more — everyone can now see the gap instantly.
A “Product OS” is a designed mechanism for product leaders to ensure the organisation can reduce that gap, cycle by cycle, until the story and the operating truth finally match.
2. The Product OS: The Full Stack (How I Build It)
What follows isn’t a grand manifesto, a rigid template or a “copy these boxes and you’re now world-class” framework. And it’s definitely not a “Spotify Model for product”.
Every organisation has its own constraints, incentives, scars and history — and its own mix of people, strengths and gaps. Any Product OS worth building has to flex to those realities. It’s the same idea at the heart of Play to Win: strategy only works when the underlying capabilities and management systems exist to support it. You can’t copy someone else’s structure or talent model and expect it to behave the same way. Your Product OS has to be built for the organisation you actually have, not the one you wish you had. And as the organisation evolves, the OS should evolve with it.
This is simply how I build one.
It’s the structure I’ve used repeatedly across scale-ups, start-ups, VC- and PE-backed businesses, incumbent platforms and post-acquisition tangles — a top-to-bottom system that connects vision, strategy, operating model, incentives and cadence. My hope is that you take something from it that helps you shape product excellence in your own environment.
Think of this article as an x-ray of how I run product: a set of layers that need to exist, connect and reinforce one another, even if the labels or artefacts change.
From here, we’ll walk through the stack layer by layer at a high level.
From next week onwards, we’ll start adding real depth to each one in turn — beginning with product vision — but for now, here’s the Product OS it sits within.
Layer A: Product Vision
The anchor everything else depends on.
Before any strategy or roadmap conversations, you need a product vision. Not a slogan, not a poster — a clear view of the future you’re building towards and the change you intend to create for customers.
Most visions don’t do that. They’re too vague to guide decisions or too inflated to be credible. The ones that work share a few essential traits. Here are the three that matter most:
A definitive, future-focused statement people can actually picture — not a generic promise about excellence.
Useful for day-to-day decisions — teams can choose between two good options without asking you.
Aspirational but believable — bold enough to energise, grounded enough that people don’t roll their eyes.
I use a fuller set of ten traits — including emotional resonance, differentiation, narrative clarity and simplicity — and I’ll break those down next week, along with how to workshop and test a vision so it becomes a practical tool rather than a slogan.
For now, the only thing you need to remember is this:
If your vision can’t guide decisions, the rest of your Product OS won’t do its job. Everything downstream relies on this layer being strong.
Next week, we’ll go deeper into how you craft a vision that’s both inspiring and genuinely useful.
Layer B: Company Objectives
The commitments that define what “winning” actually means.
Let’s start with the uncomfortable truth most product teams avoid but really there should be no shock or awe in reading:
Product is a commercial discipline.
It exists to create economic advantage.
If it isn’t accountable in some way for commercial outcomes, it isn’t really product management — it’s project management with nicer language.
Any model that treats commercial alignment in Product Management as a preference or optional, rather than a mandate, is already broken.
And this is why company objectives matter so much in a Product OS.
If the vision sets the destination, company objectives define what winning actually means — in revenue, in retention, in market position, in cost structure, in risk. They sit above product strategy because they anchor the entire organisation, product included, in the reality of the business.
Most companies skip this step or disguise vague hopes as “objectives.” But real objectives do some critical things:
They force hard choices. You can’t optimise for everything. The business has to state what it’s genuinely betting on.
They set the commercial guardrails. Product strategy means nothing if it isn’t built inside the financial and operational realities of the company.
They focus effort. Clear objectives stop teams spraying energy across ten competing priorities.
They create consequences. If missing an objective has no impact, it wasn’t an objective — it was a wish.
Good objectives aren’t targets or KPIs. They’re commitments the organisation is willing to organise around.
As a product leader, I use company objectives to answer three blunt questions:
What must be true for the business to win this year?
What will we actively ignore because it doesn’t help us win?
What breaks if we fail? (If the answer is “nothing,” it’s not an objective.)
This isn’t optional.
If product isn’t anchored to the company’s real priorities — not the pitch-deck ones, the actual ones — then every layer of the Product OS falters. Vision floats, strategy fragments, incentives drift, roadmaps become political artefacts, and product slowly becomes ornamental.
A Product OS only works when product is tied directly to how the business wins. Otherwise everything downstream fails quietly — and then very very loudly! IYKYK
Layer C: Unique Strategic Approaches to Product
How we plan to win — and the rules we’ll follow to get there.
If Layers A and B define direction and commercial reality, this layer defines how product will win within those constraints. Not a list of initiatives. Not a roadmap. Not a thematic rebrand of the same backlogs.
This is the set of deliberate strategic approaches that shape every decision the product organisation makes. They’re like the “rules of engagement” for how you operate, prioritise, sequence, build and defend.
And here’s the important bit:
Product strategy isn’t just the roadmap.
Product strategy is also the approach behind it.
Most product orgs skip this layer entirely. They jump straight from a vision and a few business goals into an overflowing backlog they call a strategy. But a real product strategy is made up of the unique approaches you commit to — the ones that differentiate how you win.
Real examples of strategic approaches (from my own past):
Customer-obsessed, but commercially anchored — solve the right problems for the right segments, not whoever shouts loudest.
Outcome-driven sequencing — ship the smallest meaningful step that proves or disproves progress, not the largest imaginable solution.
Learning as a competitive weapon — decisions made on truth, not optimism; accelerate insight loops across discovery, delivery and operations.
Platform before product sprawl — invest in shared capabilities that compound over time rather than scatter innovation across siloed modules.
Standards that create speed — consistent patterns, APIs, data models and workflows that let teams move fast without breaking the system.
Operational leverage — design for the part of the workflow where value, cost and risk converge, not the glamorous surface areas.
These aren’t initiatives.
They’re the stances that shape initiatives.
Each one narrows the field of possible work into something coherent and compounding.
A good strategic approach does three things:
It clarifies what “winning” looks like for product within the company’s objectives.
It constrains the wrong work — politely but firmly.
It creates consistency, regardless of who is making the decision.
More importantly, strategic approaches travel. They empower teams to make independent decisions that still align with the system — which is exactly what an Operating System is designed to do.
For today, the key point is simple:
Product strategy isn’t a plan — it’s a set of commitments about how you intend to win. Your roadmap only makes sense once these commitments are explicit.
Layer D: Product Messaging
The story that aligns what we build, what we sell and what customers believe.
Once you’ve defined how you plan to win (your strategic approaches), the next layer in the Product OS is your product messaging. The narrative that explains your value, your differentiation and the problem you solve.
This isn’t a marketing flourish.
It’s a strategic artefact.
Good messaging sits at the intersection of product, marketing, sales and customer reality. When it’s weak or unclear, every part of the organisation drifts in different directions. When it’s strong, it becomes the backbone that aligns:
What product chooses to build
What marketing says you do
What sales believe they’re selling
What customers think they’re buying
And — critically — what they should expect from you next.
If you have a Product Marketing function, this is where the partnership becomes essential. If you don’t, product inherits the work by default (and frankly, still should have a strong hand either way).
Strong product messaging does three things:
Defines the problem space clearly
If customers can’t recognise their world in your narrative, they won’t trust your solution.Articulates your unique value
Not everything you can say — the one thing that genuinely shifts the category or solves the pain in a way competitors don’t.Creates coherence across the OS
Messaging should be the external expression of your strategic approaches, not a parallel story crafted for convenience.
Without coherent messaging, your strategy becomes internally consistent but externally invisible. With it, you create a narrative that reinforces your differentiation and helps the rest of the organisation pull in the same direction.
I’ve been fortunate enough to work in the past with some world-class product marketers so I hope when I get to future articles I can pull them in to add their insights on the mechanics — positioning statements, proof points, narrative testing, and how to use customer language to validate messaging before it ever hits a website.
For today, remember this:
If your messaging doesn’t match what your product can defend, you’ve just created a new Motte-and-Bailey gap. (See this article)
Layer E: Who We’re Building For
The customers and segments that define the boundaries of your product.
If you’re not aligned on who you’re building for, you can’t possibly align on what or why. It’s one of the fastest ways a product organisation drifts.
For me, this layer is about three things:
Clear ICP boundaries — not a broad market definition, but a filter. Who we serve, who we don’t, and who we will prioritise even at the expense of others.
Behavioural truth, not just technographics and demographics — what people are trying to get done, where the pain really lives, what triggers action, and what constraints define their world.
Evidence, not fiction — usage patterns, interviews, retention signals, sales data. Not personas built in a vacuum.
When this layer is strong, everything else sharpens: messaging, strategy, prioritisation, sequencing. When it’s weak, you get polite disagreement, endless edge cases and a roadmap trying to serve “everyone” — which is just another way of serving no one.
I’ll go deeper later in the series on how I construct practical ICPs and test them.
For now, the point is simple:
Your Product OS only works when you know exactly who you’re building for. This can evolve over time but start narrow. Narrower than you feel comfortable doing so.
Layer F: Roadmap Architecture
The directional map that links vision, strategy, ICP and reality.
If there’s one artefact guaranteed to expose misalignment, it’s a roadmap. Not because roadmaps are hard, but because every single person imagines a different thing when they hear the word.
A roadmap is not the following, and that’s ok:
a delivery schedule
a commitment ledger
a Gantt chart in disguise
a shopping list for stakeholders
In a Product OS, the roadmap is a strategic artefact, and a good one does these things:
Shows direction, not dates — it’s a narrative of where the product is heading and why.
Connects the layers above it — vision, company objectives, strategy, ICP, competitive context, technical reality.
Expresses trade-offs — what we’re doing and what we’re consciously not doing.
Reveals sequencing logic — not “Q1/Q2 plans”, but the order in which value, risk and capability build on each other to compound value.
Most organisations try to force a single roadmap to serve every audience for every question. Admit it, you’ve also tried...It just doesn’t work.
You need multiple artefacts for different purposes (and again that is ok):
Directional roadmap — vision, themes, big moves (e.g. for exec alignment & external narrative).
Strategic roadmap — sequencing of bets, capabilities and constraints (e.g. for product, engineering & planning).
Operational roadmap — nearer-term work, shaping and horizons (e.g. for day-to-day coordination).
Each one hopefully tells a different version of the same truth, not a different truth!
My definition of product strategy has at least four parts, and the roadmap is one of them:
Product Vision (anchored in business strategy)
Strategic Framework (context, challenges, competition, architecture)
Roadmap(s) (directional, not time-bound)
ICP & Personas (who we win with)
If your roadmap doesn’t reflect those inputs, it isn’t a roadmap — it’s just a backlog with better formatting.
Later we’ll go deeper into how to construct roadmap architectures, how to create separate narratives for different audiences, and how to use sequencing as a competitive advantage.
For today, the key point is simple:
Your roadmap is your strategy in the eyes of the organisation. If it’s unclear, you’re setting yourself up for unending time-consuming debates with every single stakeholder who has an opinion on the product (which lets be honest, is typically everyone).
Layer G: Operating Model & Ways of Working
Where strategy becomes real — or quietly falls apart.
Most companies inherit their operating model by accident. A Product OS needs it to be deliberate. For me, this layer rests on four essentials:
1. Team shape and flow
Use the logic of organisational design principles and knowledge such as Team Topologies, to intentionally create the org you need.
Decide how work moves, who owns what, and where you reduce cognitive load.
If team design is unclear and there is a lack of accountability things will not get done. I’m a fan of Team working agreements and Team charters for such purposes.
2. Decision rights
If you don’t explicitly define who decides, influence and politics fill the gap.
Clear decision-making is one of the fastest ways to remove organisational friction. Every product/technology team should have a clear mandate,
3. Cadence that creates truth, not performance
This is where my Winning Team Formula™ I shared before lives:
Work (transparently + small + meaningfully + swiftly) + Inspect/Adapt=higher cadnence of learning
Good cadence drives learning, actual outcomes for customers and the business and forward motion.
Bad cadence looks like just reading Jira tickets aloud and saying you’re working on it
4. Clean interfaces with the rest of the business
Most product pain isn’t inside product.
It’s in the seams — with Sales, CS, Ops, Engineering.
Define how these relationships work, or they’ll define themselves. Understand what you need from each other to be successful.
The key takeaway is:
If this layer isn’t intentionally designed, the OS is weak.
Strategy becomes optional. Roadmaps become fiction. Teams optimise for the wrong things.
Layer H: Incentives & Behavioural System
The invisible layer that decides whether the OS works or collapses.
You can have a great vision, a clear strategy and a beautiful roadmap —
but people don’t follow strategy; they follow incentives.
If this layer is misaligned, everything else in the OS becomes theatre.
Three principles guide how I design and diagnose this layer:
1. Incentives reveal the real strategy
If people are rewarded (formally or informally) for protecting legacy revenue, they will.
If they’re rewarded for speed, they’ll move faster.
If they’re rewarded for avoiding risk, innovation dies quietly.
What the organisation rewards always beats what the organisation says.
2. Most incentives aren’t just monetary — they’re also behavioural
Title, visibility, approval, avoidance of conflict, stakeholder satisfaction, not being blamed — these drive more behaviour than bonuses ever will.
So you have to surface them explicitly.
If you don’t, they will run your entire OS in the background.
3. Incentives must match values and strategy
If company values say “learn fast” but teams are punished for being wrong, you don’t have a values problem — you have a behavioural system working exactly as designed, but driving against product success.
A Product OS needs incentives including:
reward truth over performance
reward progress over perfection
reward alignment over individual optimisation
reward learning loops over political safety
When those incentives exist, momentum builds. When they don’t, product becomes nothing more than a facade of delivery theatre.
If you don’t intentionally call out mismatches here or design this layer, you will spend your entire product career fighting an opposing system.
Layer I: Measures & Company Health
How you keep the organisation honest — and aligned with reality.
Most companies track metrics. Lots of metrics. Very few build a measurement system that actually informs decisions, protects focus and exposes drift early. In a Product OS, this layer is about creating “shared truth”.
For me, it has three jobs:
1. Make the real state of the product visible
Not vanity dashboards. Not KPI bingo. But a clear view of the following:
product health
platform/technical health
customer health and behaviour
commercial signals
operational constraints
I typically then share these on an appropriate cadence in a series of “Where We Are Now” artefacts for the entire business. Narratives the organisation can trust because it comes from actual data and evidence, not optimism.
2. Show progress in context, not isolation
A good measurement system doesn’t just say “what happened”; it clarifies:
are we moving closer to the vision?
are we delivering on company objectives?
are we reducing known gaps?
are we building momentum or accumulating narrative debt?
Numbers without context mislead. Narrative without numbers deceives. You need both.
3. Create learning loops, not reporting loops
If your “measures that matter” don’t change decisions, they’re decoration.
If they don’t shape what you stop doing, they’re noise.
If they don’t show you where the OS is failing, they’re fiction.
The point isn’t dashboards, it’s actual steering of direction.
A strong Measures layer gives a product organisation one of th rarest advantages in tech:
Everyone knows what’s real, what’s working, what isn’t and what must change next. This is how you stop drift, reduce politics and build alignment
Why Most Companies Don’t Have a Product OS — and What to Do About It
Most companies don’t lack intent; they lack an operating system that turns intent into reality. In my experience, the failures come down to three things:
Storytelling is easier than operating truth.
Anyone can craft a compelling narrative. Building an organisation that can actually deliver it — consistently, across teams — is far harder.Incentives distort everything.
Teams do what they’re rewarded for, not what strategy requires. If the system constantly pulls people back to today only and immediate results , the future state doesn’t stand a chance.Leaders confuse documentation with design.
A Product OS isn’t a Notion page. It’s the behaviours, routines, cadence and constraints that drive actual decisions. If nothing changes in how the organisation works, the “OS” is just theatre.
The good news is that you don’t fix this with a transformation programme.
You fix it by designing the OS deliberately and improving it cycle by cycle.
Here’s a simplest starting playbook to get something done today:
Map the full stack — from vision to measures — so you can see the whole system as it stands, start at the top if time constrained.
Identify the drift — your Motte/Bailey gaps — and make them discussable.
Align incentives with the behaviours you want now, not habits you’ve tolerated.
Introduce a cadence that forces truth — transparency, learning, alignment.
Iterate the OS, because the organisation you have today won’t be the one you have in three months.
None of this is glamorous. All of it is part of the job.
Closing Thought
Every company claims to have a product strategy. Very few actually do. Even less have a Product Operating System — the thing that makes the strategy real.
In an AI-first world, strategy without an OS is just narrative.
The organisations that win won’t be the ones with the loudest story but the ones whose operating model makes that story inevitable.
Next week: Product OS - What makes a compelling product vision?