I also promised that Layer A (Product Vision) was coming first, because it’s the anchor everything else depends on.

Originally I said, it would be ‘next week’ and honestly I wanted it to be, but in all transparency, I’ve actually been applying this in real life to customers that really need this support now and couldn’t wait. So I had to prioritise. That said, here it is, albeit a bit later than proposed.

And I want to start with another honest confession before we get into the craft of it:

Not because the people who wrote them were incompetent. But because nobody told them what a product vision should actually be for, in my view.

A vision isn’t just a slogan. It isn’t a mission statement. It isn’t just the first slide in your board deck or the line under your logo.

I believe a product vision is a practical instrument. Done right, it guides day-to-day decisions, anchors strategy under pressure, and gives teams the clarity to act without needing to check in with you first.

Done wrong, it’s just fancy wallpaper.

My hope for this article is to hopefully show you the difference and give you the tools to make your own product vision, not just more exciting but more practical.

The Test Most Visions Fail

Here’s the fastest way to know whether your product vision is actually working with 2 questions:

1. Ask someone in your team, anyone, just not a senior leader, not someone who helped write it, to tell you two options they’re weighing up for a piece of work. Then ask them: “Which one does the vision support?”

   If they can answer without hesitating, you have a vision that works. If they look confused, or say they’d need to ask someone, or worse '“what vision?” you don’t.

   A vision that can’t guide decisions in the field isn’t a vision. It’s a slogan with good layout and kerning.

2. The second test is equally brutal: “Can you say what your vision is not?”

   The best visions carry implicit boundaries. They rule things out as clearly as they invite things in. If yours includes everything, it governs nothing.

Why Most Visions Go Wrong

Before we get to what good looks like, it’s worth naming the failure modes because they’re predictable, and I’ve seen every single one of them. You probably have too.

• Too generic. “Empower users to achieve more.” More what? More of which users? Achieving what, exactly? Is empower the most overused word in product marketing? Generic visions feel safe because nobody can disagree with them. But they don’t guide anything precisely because nobody can disagree with them.

• Too technical. “Build the world’s most advanced AI-native platform.” Nobody who isn’t already living in the product could tell you what they’d actually experience differently. AI-native, LLM-powered, ML architecture etc. Great - but they have no place in a vision. I’m of the firm belief that visions shouldn’t describe architecture — they should describe change.

• Too modest. “Helping teams track market data more easily.” Fine. But it won’t energise anyone, it won’t attract the right talent, and it won’t survive the first time the roadmap comes under budget pressure.

• Too inflated. “Revolutionise the global supply chain.” Sounds great. Means nothing. Creates cynicism faster than almost anything else in my view. It can initially feel really grandiose and exciting, but then what? This could be part of your overall mission but it should not be the defining product vision.

• Not connected to the business. This is perhaps the most common one. I sit in rooms regularly where the product vision and the commercial strategy are two completely different stories. Both exist in slides. Neither talks to the other. This is a slow-motion catastrophe, and it always shows up in decisions being made, particularly around the roadmap.

A good vision avoids all of these. Not by splitting the difference between them, but by aiming at something specific: the future state of the world you’re building toward, expressed in a way that makes action obvious.

What One Actually Looks Like

To make this concrete, I want to share a real vision statement — one I’ve been involved in developing — for a real company that was going through a key inflection point after receiving significant funding.

(The company is anonymous, but the example is real, and the process behind it is exactly what I’ll describe as we continue)

The core vision we landed on:

The decision layer that enables industrial companies to turn external world dynamics into confident action.

Let me show you why this works against the criteria.

“Decision layer” stakes out a future category that doesn’t cleanly exist today — it’s not incremental improvement on forecasting, it’s the claim of a new structural role in how industrial decisions get made. Definitive. Future-focused.

“Industrial Companies” is the current understanding and most refined articulation of the current Ideal Customer Profile (ICP) to provide clarity on who we are building for.

“External world dynamics” — commodity markets, energy prices, weather, geopolitics, logistics, macro signals — are first-class inputs, not background noise. This anchors the commercial direction immediately and makes the ICP obvious without naming it.

“Confident action” is the ultimate benefit. Not better models. Not more data. Not higher accuracy. Confidence at the point where a decision must be made. That’s where the value is felt.

And “decision layer” implies infrastructure within a broader system. Not a standalone tool competing for everything, but something that strengthens what already exists. It goes beyond the product into how organisations will work differently.

Most critically: it reframes the company’s core question. Not “how good is our forecasting?” but “who owns the moment where volatility turns into action?”

That’s a category question. And a compelling vision always points at a category, not just a feature set.

⭐ PAYWALL BREAK ⭐ — Not really…this isn’t just thought leadership for the sake of it, I want to offer this information for real product operators by real product operators for free as long as I can and hope you get some actual value out of using it.

Mike’s Personal Criteria for a World-Class Product Vision™

Over the years, I’ve developed a set of criteria I use to stress-test product visions. Both the ones I write and the ones I inherit. I’ll share the full set with you here, because I think it’s genuinely more useful than a formula. You’ll no doubt adapt and evolve these as you start applying them, as I have myself. Great, it means you’re being intentional about what matters to you and the products you are part of.

There are (currently) eleven traits. A strong vision should satisfy all of them. Most visions satisfy three or four.

1. Definitive and future-focused. It names a future state that doesn’t cleanly exist today. Not where you are…where you’re going, and what will be different when you get there.

2. Tied to the business vision. Not a parallel story. The product vision should be an expression of the commercial direction, not a creative exercise that lives in product and gets confused with the business strategy.

3. Guides strategy and prioritisation. Any meaningful product decision should be testable against it. If a team can’t use the vision to choose between two good options, it isn’t working hard enough.

4. Speaks to the ultimate benefit. Not the feature, not the mechanism, not the architecture — the outcome someone feels. The value should be experienced at the point of decision, not the point of analysis.

5. Goes beyond the product itself. A great vision implies a structural change in how something works, not just a new capability in a piece of software. It describes what the world looks like through a different lens.

6. Aspirational but believable. Bold enough to energise people. Grounded enough that it doesn’t generate eye-rolls. The sweet spot is ambitious without being detached from reality.

7. Helps articulate change and impact. It should make clear what shifts — in behaviour, in process, in how decisions get made — when the vision is realised. The impact should be evident without needing a three-slide explanation.

8. Creates excitement for the right people. Not for everyone. The best visions deliberately target a specific audience and resonate deeply with them. Trying to excite everyone is a fast route to exciting no one.

9. Helps people act without asking. Teams should be able to assess their own work against it independently. If a feature doesn’t move towards this vision, it’s incomplete or misdirected. This is the autonomy multiplier a good vision provides.

10. Less is more. Concise, dense with meaning, free from technical clutter. If you need three paragraphs to explain the vision, it isn’t the vision yet — it’s a draft.

11. Supports multi-level extension. A strong core vision should naturally expand into ecosystem strategy, ICP definition, messaging, moat narrative and strategic guideposts — without needing to be rewritten at each level.

Three Real Visions

To make the criteria tangible, it’s worth applying them to visions you already know. Not to score companies, but to see the patterns clearly. Three well-known examples tell three very different stories. Note: I found these online, so some potential that they have been updated or slightly different now.

LinkedIn

“To create economic opportunity for every member of the global workforce”

This passes the inspiration test immediately. It’s future-focused, tied to genuine structural change, and describes a benefit that matters at a human level. The “so what?” is obvious. But run it through criterion 3 — does it guide decisions in the field? — and the cracks show. A team could use this to justify almost anything. “Every member” is inclusive enough to be energising, but too broad to function as a decision filter. A product manager couldn’t use this to choose between two competing roadmap directions without significant interpretation layered on top. Strong on aspiration. Weaker on the operational clarity that criterion 9 demands.

Instagram

“To capture and share the world’s moments”

Probably the most practically useful of the three for its time. Dense with meaning, immediately testable. You can hold almost any feature decision against it: “does this make capturing or sharing a moment better?” If yes, proceed. If not, reconsider. That’s criterion 3 working. It also implies structural change the way memory, connection and presence work; without overreaching into grandiosity. The limitation is one worth noting: this vision described a camera app. It no longer describes what Instagram is. A vision that doesn’t evolve with the product eventually becomes a constraint rather than a compass. That’s not a failure of the original vision. It’s a reminder that the vision should be a live instrument.

Netflix

“To become the world’s leading streaming entertainment service”

This one feels like it should work. It’s clear, confident, memorable. But look carefully. It describes a competitive position, not a future state of the world. It says nothing about who specifically you’re building for. It gives a team no material guidance when two good options are on the table e.g. “be the market leader” resolves nothing at the point of a real decision. And there’s no implied structural change in how entertainment is experienced, just a claim about market rank. It’s a business ambition written in the language of a product vision. That’s a common failure mode, and it shows up in criterion 2 (tied to the business strategy, not an expression of it), criterion 5 (goes beyond the product), and critically criterion 9 (autonomy: teams can’t act from it independently). Worth noting: Netflix’s actual product thinking around the machine learning infrastructure, the content bet, the anti-appointment-viewing model was almost certainly guided by a sharper internal view than this statement suggests. Which is itself a useful observation. The vision online and the vision the team operates from aren’t always the same thing.

The pattern across all three: aspiration is the easy part. The harder job and the one most visions don’t do, is building enough specificity that a company can act from the product vision without asking someone more senior to interpret it for them. That’s the bar I think is worth aiming for.

How to Actually Build One

Knowing the criteria is step one. The harder part is the process of how you get from wherever you are now to something that actually satisfies them. This is where most teams get stuck, because vision-writing looks deceptively simple and turns out to be anything but.

What follows is the process I use. It’s not a single workshop. It’s a sequence and the sequence can help.

Step 1: Start with the problem you’re solving at scale, not the product you’re building.

Most vision-writing processes start with the product team in a room with a whiteboard. This is backwards. Before anyone writes a word, you need to be deeply fluent in the problem at the level of the person experiencing it, not the person building the solution. This is obviously just a core product management principle but extremely important for what follows.

The question to anchor on is: “What is the most consequential decision our customer makes and why does it go wrong?” Not “what do they need?” Not “what’s missing from the market?” The most consequential decision, and the reason it consistently goes wrong.

In the example above, the answer was that procurement and operations leaders make irreversible commitments on supply, on cost, on contracts in the face of an increasingly volatile world they can’t reliably interpret in time liek they maybe could years past. The consequence of getting that wrong is measured in signifcant hits to margin, not inconvenience. Material impacts to the business. That’s the foundation everything sits on.

If you don’t have that kind of clarity before you write, you’ll end up describing your product rather than the change it creates.

Step 2: Stress-test against the “so what?” and “why us?” questions before you write anything.

Two questions that kill weak visions early and save a lot of wasted effort.

“So what?” Read the draft vision as if you’re the sceptic in the room. If the honest answer is “well, someone probably needs that,” you don’t have a vision yet. The so-what has to be obvious, immediate and significant.

“Why us?” Not as a defensibility exercise, but as a reality check. Does the vision imply a set of capabilities that you can credibly build toward? Or does it describe a future state so generic that thirty other companies could claim the same vision with equal legitimacy?

Both questions hurt when you first ask them. That’s the point.

Step 3: Write the core statement first. Everything else is extension.

The core vision statement should be one sentence. Maybe two if the second genuinely adds something the first can’t carry. Everything else like expanded vision, aspiration, strategic guideposts will be an extension of the core, not part of it.

A useful structure: [who is the actor] + [what structural change are you creating] + [what is the outcome for them]. That doesn’t mean it has to follow that template mechanically — but when a vision is missing one of those three things, you can usually feel the absence even if you can’t name it. Visions that drop “the outcome” become technical. Visions that drop “the structural change” become generic. Visions that drop “who” become rootless and unclear in their category.

Step 4: Run it through the eleven criteria. Honestly.

Print the criteria. Score the vision against each one. Not “does this pass?” but “how well does it pass, and where does it fall short?”

The most common gaps I see: criterion 9 (autonomy — can teams act on it independently?) and criterion 11 (extension — does it naturally expand into strategy and messaging?). These two tend to reveal whether you have a working vision or a well-worded sentence.

If you’re scoring fewer than eight out of eleven confidently, keep going. It’s not done yet.

Step 5: Test it in the field before you commit to it.

Share the draft with three groups: someone on the product team who wasn’t in the room, a sales or commercial leader, and a current customer. Not for validation, for calibration.

Ask each of them:

• “If this is what we’re building toward, what would you stop doing that you’re doing now?”

• “What would you start doing that you’re not?”

The answers tell you whether the vision is landing as a practical instrument or just sounding good. If the product person says “not much would change,” the vision isn’t doing its job internally. If the commercial leader says “I’m not sure how I’d use this in a conversation,” the vision isn’t doing its job externally. If the customer says '“It sounds just like competitor x’s offering”, it’s too generic. All matter.

The Expanded Vision and Why It Matters

Here’s something I’ve noticed consistently: companies skip all three of the layers I’m about to describe. Not because they disagree with them. Because they don’t know they need to exist.

They write the core statement, or something approximating it, and treat that as the job done. Product Vision: complete. Move on.

The cost of that shows up later, and it looks like this:

• Cross-functional arguments about what to prioritise that go in circles and never fully resolve.

• Product managers are being asked by leadership to just go and ask the business what it wants, stack rank the answers, and build that.

• Sales teams are quietly crafting their own materials because what they’ve been given doesn’t land in the market.

• Staff at every level are waiting to be told what to do by someone more senior rather than deciding and getting on with the work.

• A general, persistent sense that pace is slow,but nobody can point to exactly why.

None of that is just a process problem. It’s a vision architecture problem. The core statement exists, but it hasn’t been extended into anything the organisation can actually operate from. The roof is built. There are no walls.

The extension happens in three layers in my view, and each one does a job the others can’t.

The expanded vision: Gives the core statement its context. Where is the world today, why does the gap the company is closing exist, and what changes when the vision is realised?

This isn’t an explanation of the core, if the core needs explaining, it isn’t good enough yet. It’s the narrative that surrounds it. Written well, it’s two or three paragraphs that an investor reads and immediately understands the market logic, or that a new hire reads on day one and understands what they’ve joined and why it matters. It carries the journey, not just the destination.

The aspirational outcome: Is different in kind, not just in length. It’s not just narrative. It’s a rich picture. Ambitious but concrete, almost journalistic description of what a day looks like for your customer when the vision is fully realised. What meeting are they no longer having? What decision do they now make in an hour that used to take a week? What do they take for granted that currently keeps them up at night? The test for a strong aspirational outcome is simple: could your best customer read it and say “yes, that’s exactly what I want”?

If it reads like a feature list or a strategy summary, it’s the wrong register entirely. It should feel like a description of a future that’s worth building toward which is precisely why it’s the north star that keeps product and strategy anchored when the quarterly pressure to compromise starts building.

Strategic guideposts: This is where the real operational leverage is, and where almost everyone falls short.

A guidepost is not a value. It’s not a principle. It’s a decision filter and the test for whether one is working is brutal: can it be violated? Can you imagine a reasonable person, in a real meeting, arguing the opposite? If not, it’s a platitude, not a guidepost. “Put the customer first” fails this test. Nobody argues against it, which means it resolves nothing when two good options are on the table.

The reason executives sense the problem but can’t name it is that the symptom looks like a people or process issue. Decisions are slow. Teams keep escalating. The roadmap debates the same territory every quarter. The reflex is to add process: better sprint rituals/ceremonies (note: I hate these terms that people use, it’s not a religion; they are ‘events’), a clearer RACI, a more rigorous roadmap review. But the root cause is almost always that nobody has translated the vision into a set of decision rules the team can apply independently. And the longer that goes unaddressed, the more the organisation learns to route around it. Which is how you end up with product teams taking orders from internal stakeholders and sales decks written by people who’ve given up waiting for the right materials.

The most common version of this I see is a leadership team that’s deeply experienced in the domain, where most people have done the actual job the product supports. The instinct is to trust that expertise. “We know what the customer wants” and they’re not wrong that they know the domain. But domain knowledge is not a substitute for current market signal. The customer they knew and the customer they have now are not the same person. Without a guidepost that makes this explicit, the organisation will default to internal conviction every time, and the product will gradually drift away from the market it’s supposed to serve.

Here’s what four well-formed guideposts could look like, anchored to the tensions I see most often to show some tangible examples:

• Internal expertise is a starting point, not a substitute for market signal. We build from what customers do and what the market is telling us now, not from what we know they used to need. Domain knowledge informs our questions it doesn’t answer them.

• We go deep on fewer things, not shallow on many. Every addition that doesn’t compound the core use case is a tax on the customers who need us most. When in doubt, we do less better.

• Our job is to change behaviour, not to inform it. Insight that doesn’t lead to a decision or an action isn’t product value, it’s overhead. We measure success by what customers do differently, not what they now know.

• We treat velocity as a lagging indicator, not a goal. Moving fast through the wrong problem is expensive. We optimise for the quality of decisions made, not the volume of work shipped.

Each one is testable. Each one tells a team what to say no to. And critically, each one cuts against something a reasonable person in the room would argue for, which is exactly the point. A guidepost that nobody would ever violate isn’t governing anything.

What makes the difference between guideposts that work and ones that don’t is almost always operationalisation, not content. The ones that change team behaviour are the ones that end up in working agreements, that appear in the language of retrospectives, that get referenced naturally when a difficult call is being made. They become part of how the team thinks, not a document nobody opens. Written once and filed, they’re wallpaper. Embedded deliberately into how decisions actually get made, they’re the closest thing to scalable product leadership that exists.

The Hardest Part Nobody Talks About

Here’s what I’ve learned after doing this many times across very different companies:

The vision isn’t the hard part. The conversation is.

Writing a strong vision statement requires skill and rigour, but it’s ultimately a creative and analytical challenge. The harder work is creating the conditions in which the vision becomes a shared operating truth. Not just a slide that gets nodded at in an all-hands and quietly ignored for the next six months.

That requires a founding team or leadership group that genuinely agrees on the problem worth solving - not just the solution. Enough psychological safety for people to say “I don’t think this vision would have stopped us building the wrong thing last quarter.” A collaborative enough process in its creation so at a minimum the key individuals are bought in as early as possible. And a willingness to revisit and sharpen the vision as the company learns, without treating every revision as a failure or a rebrand.

The companies that struggle with product vision usually have at least some of these cultural aspects missing. The ones that get it right treat the product vision as a live instrument, not a launched artefact.

In Summary: What You Can Do This Week

Run the eleven criteria against your current vision. Not to judge it, but to see it clearly for what it is. Then ask yourself which three criteria it fails most badly, and why. That’s a starting point. Share your views with your team, a manager. Even better, a trusted customer on their own take on the product vision if they know it.

If you don’t have a vision at all which is more common than most product leaders will admit, start with the consequential decision question: what’s the most important decision our customer makes, and why does it consistently go wrong? Build from that truth, not from what you’re building.

Next in the series:

Product OS: Part 3 - Company Objectives and why product without commercial accountability isn’t product management at all.

If this was useful, share it with someone who’s about to start a vision exercise or someone who’s wondering why their existing one isn’t working.

And if you want to talk through how the Product OS applies to your company specifically, you know where to find me.

www.productleaders.co.uk

I thought it would be nice to walk you through what’s changed.

The Setup

Back in 2019, I was Director of Product Management at WorkForce Software. Insight Partners convened an interview on developer productivity within the portfolio, and I laid out, along with Ken Surdan, what I believed mattered most:

• Clarity of vision

• Managing tech debt

• Removing ambiguity

• Making decisions quickly

All true. All still important. But within the constraints of the interview, a little incomplete.

What I (Think I) Got Right (And Still Believe)

1. Clarity is everything

“Providing clarity and removing ambiguity gives engineers confidence that you know what you’re talking about and why they should follow you.”

Still true. Engineers need to trust that you have a clear picture of where you’re going. Vague product strategy destroys team confidence faster than anything else. Although what is typically sought is a plan, a strategy if presented correctly is far more powerful.

2. Product owns the “why”, Engineering owns the “how”

This boundary still matters. Your job as a PM isn’t to tell engineers how to build - it’s to ensure they understand why they’re building it and what customer problem it solves. Countless articles on AI have massively blurred theses lines to the point you think all PMs need to Senior Developers, however that judgment on ‘why’ is more crucial than ever even if a majority of the value chain is now accelerated by AI.

3. Tech debt isn’t optional

“You have to acknowledge the team’s need to repay debt. Your focus is always going to be on the customer, but you have to balance that with respecting your team.”

The teams I see struggle most are the ones where product treats tech debt as “engineering’s problem.” It’s everyone’s problem. There are great examples of a ‘no bug’ culture out there and still to this day the best PMs in my team work closely with engineering so they feel heard and included on priorities.

4. Make decisions

“I’d rather make a wrong decision than indecision. We move quick enough and light enough that a bad decision isn’t a big deal and can be rectified as needed.”

Still my default mode. Indecision is expensive. Really that decision is typically a learning moment, which if you’ve read previous articles, my argument is that learning is the moat.

What’s Changed (The Nuance I Missed)

1. Vagueness isn’t always the enemy

Here’s what I’ve learned or now able to better articulate than before: There are two kinds of ambiguity.

• Deadly ambiguity: Vague vision. Unclear strategy. No north star. This kills teams.

• Productive ambiguity: Not knowing the answer yet because you’re still learning. This is discovery. Obvious you say but the amount of organisations that still don’t prioritise or do any actual discovery is worrying.

The PM’s job isn’t to eliminate all vagueness, and again, the great one’s thrive on ambiguity, but they need to be crystal clear about what phase you’re in:

• Are we exploring? (Embrace uncertainty, learn fast)

• Are we building? (Increased demand on clarity, shipping more confidently)

Mixing these up is where teams get lost.

2. Tech debt conversations need to tie to business outcomes

Not all tech debt is created equal. Some of it slows you down. Some of it doesn’t matter for years.

The best PMs don’t just “give the team time for tech debt”, they help the team identify which technical investments unlock the next phase of product growth.

Tech debt isn’t a backlog category. It’s a strategic conversation about where you’re going and what’s in the way. What really matters now, this week, next 4 weeks…

3. Meetings should be rare, not routine

I used to defend the practises, (but have and still detest when they are called ‘rituals’.) Standup! Planning! Grooming Refinement! Retro!

Now I question them by default.

Most of what happens in standups could be written down. Most planning sessions are low-quality thinking disguised as collaboration. Most retros surface issues that should have been addressed in the moment.

The best teams and PMs minimise synchronous time and maximise deep work time. If a meeting exists, it should be because you genuinely need to think together, not because the calendar says it’s Tuesday.

4. Scope changes aren’t inherently bad

I used to think changing the scope signalled weak leadership.

Now I refine this: Changing scope based on evidence is strong product leadership.

The difference is the “why.”

Teams lose confidence when scope changes feel random or stakeholder-driven. They should gain confidence when scope changes reflect customer learning and strategic clarity, and when positioned as such.

The job was never to lock scope. The job is to signal why we’re pivoting.

5. Speed isn’t the only thing that matters

This is my personal biggest shift. Deep to my core is the mantra of ‘learning’.

I used to optimise for shipping cadence, likely due to the system I was in. Now I optimise for decision quality.

Shipping every two weeks is valuable - but only if you’re building the right thing. If you’re moving fast in the wrong direction, velocity is a liability. This has always been a case and one I’ve expressed verbally.

The best PMs still need to create space (hold space now it’s 2026 :) ) for strategic thinking before tactical execution. They challenge false urgency. They know when to slow down and learn.

What I’d Add to My “12 Positive Things” List

In the 2019 article, I shared 12 things I do as a Product Manager to help development teams succeed.

Here’s what I’d add in 2026, 7 years later*:

13. Write things down

Decision logs, strategy docs, and clear written artifacts beat verbal clarity every time. If you can’t write it clearly, you don’t understand it clearly.

14. Protect discovery time

Before you ask for delivery velocity, make sure the team has had real space to learn. Discovery isn’t a luxury - it’s how you avoid building the wrong thing fast.

15. Make space for strategic thinking

PMs need uninterrupted time to think, not just coordinate. Block time to wrestle with hard problems. Your calendar shouldn’t just be stakeholder management.

16. Default to outcomes, not outputs

Don’t measure “features shipped” - measure “customer problems solved.” Output is easy to track. Outcomes are what actually matter.

17. Challenge false urgency

Most “urgent” requests aren’t. Help stakeholders distinguish real deadlines from manufactured ones. Your job is to protect the team’s focus, not accommodate every fire drill.

*I couldn’t tell you if this was 7 years of bad luck or 7 years of good luck. I’ve met and continuing learning from some incredible people, have had amazing opportunities, but also lived the realities of many product leaders (IYKYK). However, whether it was good or bad, I’d like to believe I’m all the better product leader for it.

The Through-Line

What hasn’t changed: Product leadership is about creating the conditions for teams to learn and make high-quality decisions.

What has changed: I’m less dogmatic about how that happens.

Clarity still matters. But so does knowing when to embrace uncertainty.

Speed still matters. But so does knowing when to slow down and learn.

Vision still matters. But so does being willing to change course when the evidence says you should.

Final Thought

If you’re early in your product career, the 2019 advice is probably what you need right now: Get clear. Focus. Make decisions. Ship fast.

If you’re more experienced, the 2026 nuance is probably where you’re headed: Know when clarity matters. Know when speed matters. Know when to challenge the defaults.

The fundamentals don’t change. But the wisdom is in knowing when to apply them.

Read the original 2019 discussion: Tips from the Top: How to Boost Developer Productivity (Insight Partners)

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:

1. What must be true for the business to win this year?

2. What will we actively ignore because it doesn’t help us win?

3. 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:

1. It clarifies what “winning” looks like for product within the company’s objectives.

2. It constrains the wrong work — politely but firmly.

3. 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:

1. Defines the problem space clearly
   If customers can’t recognise their world in your narrative, they won’t trust your solution.

2. 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.

3. 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:

1. Product Vision (anchored in business strategy)

2. Strategic Framework (context, challenges, competition, architecture)

3. Roadmap(s) (directional, not time-bound)

4. 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:

1. 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.

2. 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.

3. 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?

Too much product content still reflects the idealised version of the job. Most of the real craft sits with operators who are actually doing it — thinking deeply, listening hard and delivering — not shaping their work to fit an algorithm.

This series is for them. And you.

Each Micro-interview gives you a glimpse into how product leaders think when they’re dealing with complexity, constraint, politics, sub-optimal structures and consequence — the parts of the job most newsletters avoid.

Every Monday, I’ll share a new micro-interview. Short, honest, practical. No hype. Just thoughtful product operators talking about how the work actually gets done day in, day out.

For part 2 in the series we have Jonathan Hyde, Director of Product at Titanbay

I first connected with Jonathan quite a few years ago when I was helping run ProductTank in the Milton Keynes, bringing together a community of local product leaders. Today, he is a product leader at Titanbay. Europe’s fastest-growing private markets infrastructure provider, dedicated to making private markets simpler and more accessible. At Titanbay he operates in one of the most highly regulated and complex spaces in financial services. Exactly the kind of product leader this series exists for.

In 362 words, Jonathan shares:

• How to build product in a complex, regulated ecosystem

• Why dyslexia can be a genuine product superpower

• Why long-term scalability beats short-term comfort

• How Notion, Tableau and Cursor reshaped his product lens

• Why trust is the starting point for all leadership

Here’s Jonathan:

1. What’s your current role, and what makes it noteworthy?

I’m Director of Product at Titanbay. We’re building the infrastructure to connect the private market ecosystem—wealth managers, private banks, asset managers, fund administrators, and more. The space is complex, fragmented, and highly regulated. Our product has to do more than deliver great technology—it has to align incentives, simplify operations, and create a shared experience where everyone can move with confidence.

2. What superpower or lens do you bring to product work?

My dyslexia. I think in pictures and make connections between information in ways others might not. It lets me see problems from multiple angles quickly, and often spot patterns or solutions that aren’t obvious at first glance.

3. What’s a product decision you made that felt wrong to others at first, but proved right over time?

Prioritising long-term scalability over short-term convenience rarely feels “right” to everyone in the moment—but I’ve seen time and again that investing early in the right foundations saves vast amounts of time and pain later.

4. Which product (besides your own) changed how you think about building, and why?

Using Tableau 15 years ago taught me I could ask my own questions of data. Notion showed me how the barrier to creating a product could be lowered overnight by rethinking how we build. More recently, Cursor convinced me the age of static wireframes is over—code prototypes are now the fastest way for product teams to explore and align.

5. Describe a moment when strategy and reality collided. What gave, and what stayed?

When I joined a law-tech startup as Head of Product, the strategy was bold and expansive—value everywhere you looked. But we had a small team and limited capacity. We stepped back, assessed what we could ship quickly by recombining existing pieces, and focused there first. What gave was the idea of tackling everything at once. What stayed was the ambition—we just gave it a clear direction. [Editor’s note: an approach coincidentally aligned to this post from last week]

6. What’s a leadership lesson your team has taught you that you didn’t expect to learn?

You don’t need to be an expert in a discipline to lead it well. At Titanbay I lead Product Management, Product Design, and our Insights & Analytics team. I’m a product specialist—but my team taught me that curiosity, empathy, and great questions matter more than subject-matter expertise. If you listen, challenge thoughtfully, and show respect, you can lead across any function.

7. What moment, belief, or principle defines how you lead?

“Build trust. Every new role or relationship starts with a trust balance of zero.”

You earn it through high-quality commitments, follow-through, and consistent communication. Do that—and show up every day with integrity—and you can build a strong team, a collaborative culture, and a great business.

If you’re a product leader who’d like to share your views and experiences, message me:

If you enjoyed this, consider subscribing. Micro-Interviews every Monday, product articles every Thursday.

Subscribe now

Welcome to the first article that uses this analogy, and is not to be confused with the Motte and bailey fallacy.

If you’ve not bumped into the medieval version recently, or experienced the thrill of learning the UK national curriculum as an 11-year old, you’ve likely only been exposed to the adjacent concept of ‘moats’ via the late-90s introduction by Warren Buffet. And most definitely not the concept of a “motte” or “bailey”. The setup and principle is simple:

• The “motte” is the small, highly defensible stronghold.

• The “bailey” is the larger, more valuable territory you want to hold.

• When attacked > you retreat to the motte.

• When conditions are favourable > you claim the bailey.

In product, this maps almost too neatly onto a pattern every experienced product leader will recognise: the widening gap between the story organisations tell and the reality they operate from.

Here’s how it shows up:

1. The Bailey — the expansive strategic story (your positioning)

This is the version of the company that appears in pitch decks, investor narratives, category design exercises and all-hands meetings. It’s the story you want the market to believe — and often need the market to believe in order to justify valuation, win deals or hire talent. It’s what world-class product leaders excel at, being the evangalist and getting people excited and drawn into their vision.

The Bailey is where positioning lives.

Typical Bailey claims look like:

“We’re an AI-native platform built around intelligent automation.”
Reality: Your “AI” is three prompt templates and a Zapier flow nobody monitors.

“We’re category-defining — not another point solution.”
Reality: 80% of your revenue still comes from a single legacy module.

“We’re moving upmarket with enterprise-grade workflows.”
Reality: The permission model breaks whenever a customer has more than two roles.

“We’re the system of record for X.”
Reality: Customers still export data to Excel because they don’t trust your reporting.

“We’re a unified platform post-acquisition.”
Reality: You have three authentication flows, two data models and a migration backlog no one owns, nor wants to own.

These statements are rarely lies.
They’re directionally true aspirations.

But aspirations are not defences.

The Bailey is what you want to stand for.
It’s what the deck says you are.
And it’s where most teams, and executives, prefer to spend their time.

The challenge (and occasionally the upside) is that positioning creates gravity. Once you commit to a narrative, the whole organisation starts optimising for that story… even if the product isn’t ready to support it.

That’s where the gap begins.

2. The Motte — the entrenched operating truth (your defensibility)

The Motte is the part of your product and organisation that actually holds when pushed — by customers, revenue pressure, competitors or internal politics.

This is the reality you fall back on when the Bailey can’t carry the weight.

This is your true defence, whether you like it or not.

Examples of Motte truths:

• The one or two features that drive 75% of usage — even though it’s never mentioned in your “platform” positioning.

• The workflow everyone is scared to touch because it’s brittle — but losing it would wipe out half your renewals.

• The manual backend process everyone pretends is automated — but remains your hidden moat because no competitor wants to replicate it.

• The revenue dependency you can’t admit out loud — like an out-of-date module that no longer fits your narrative but pays the bills.

• The architectural debt that makes the AI strategy in the deck virtually impossible for at least 18 months.

This isn’t the product you talk about. It’s the product you depend on.

And when deals get tough, when users churn, when competitors move, when investors press you — you’re really defending from the Motte and rarely setup to be successful in the Bailey.

The market positioning says one thing.
The operating reality defends another.

That’s the whole problem.

Most companies are fluent in the Bailey story…
…but are defended almost entirely by the Motte reality.

And that mismatch is one of the biggest risks in any product company or product leadership role. It’s our job to make sure that gap reduces over time, in pace with internal and expectations.

Why the gap exists

1. Vision is cheap; operating alignment is not.

Anyone can publish a strategy deck.
Very few can align incentives, architecture, team structure, and workflow to actually deliver it.
The gap between “what we say” and “what we do” appears immediately in how work gets funded, shipped, measured and killed.

2. Legacy features carry political and commercial weight.

Some of your oldest, least-loved features are also the ones tied to targets, renewals or internal status.
No one wants to say it aloud, but these are the gravity wells that pull you back to the Motte and keep you there.

3. AI has widened the narrative gap.

Companies announce AI faster than they can adapt their data structures, workflows, governance or architecture.
The positioning leaps ahead; the operating model stays exactly where it was.

4. Inertia is invisible until you look closely.

From a distance, everything looks aligned.
Spend five minutes tracing a customer journey, a permissions flow, or an approval chain — and the cracks appear instantly.
Most teams don’t see the misalignment because they work inside it.

Examples you’ll recognise

Here’s a brief reminder of the lived reality — and why it matters:

A company says it’s a platform…
but 70% of revenue comes from one module built in 2018.
Why it matters: your positioning says breadth, your metrics say dependency. When sales leans on the story and delivery can’t support it, trust frays and Product becomes the “blocker.”

A deck says AI-first…
but the data model hasn’t been touched since 2017.
Why it matters: customers expect something you physically can’t ship that the story promises. Product carries the blame, engineering takes the strain, and the narrative erodes the moment a customer says, “Show me.”

A team says customer-led…
but hasn’t run a real discovery session in two months.
Why it matters: decisions get made on assumption, not insight. Vocal leadership say ‘we know what the customer wants, just build it’. Roadmap confidence drops, debates get louder, and Product ends up defending other people’s choices built on thin ice. The “learning loop” dies.

Leadership says pace matters…
but every change still passes through a steering or oversight group.
Why it matters: the operating model contradicts the message. Teams optimise for survival, not velocity, and Product gets squeezed between “go faster” rhetoric and slow, political reality.

The website shows a unified platform…
but customers still log in through three separate URLs.
Why it matters: trust breaks instantly when the product experience contradicts the pitch.

In every case, the Bailey (the story) and the Motte (the truth) aren’t just out of sync;
they create friction, erode trust, and place Product in the crossfire between aspiration and reality.

These gaps don’t stay abstract. They show up as tension in meetings, misalignment between teams, roadmap derailments, constant requests for more detail and the quiet organisational cynicism that forms when the story outpaces the substance.

But let’s not be too concerned with just the internal problems. Worse still, Customers will always feel the gap.

Why this matters more in 2025

In the past, story and substance could maintain divergence for quite a period, some even for years. You could sell the Bailey and gradually drag the Motte along behind you. Not anymore.

AI has compressed timelines, raised expectations and made execution brutally comparable. Customers can now test claims in seconds. Investors can spot architectural debt in one roadmap review. Competitors can close narrative gaps faster than incumbents can articulate them.

When your positioning outpaces your product, three things happen — fast:

1. Credibility erodes.
The gap shows up in demos, onboarding, support tickets and renewal conversations long before it shows up in the numbers.

2. Trust fractures internally.
Sales, Product and Engineering stop believing the same story. Alignment collapses quietly at first, then all at once.

3. Your defensibility shrinks.
Your moat isn’t the story you tell; it’s the reality you can sustain under pressure.

And in 2025, your moat is only as strong as the thing you actually defend — not the thing you present in the deck.

And customers can feel the difference instantly.

So what can real product leaders do? (No fluff, practical steps)

Simple, maybe uncomfortable, but effective:

1. Map your Motte and Bailey explicitly

Get a brutally honest list of:

• What you say you are

• What actually drives the metrics that matter (e.g. revenue, adoption, retention)

• What customers reliably trust you for

• What your org is structurally capable of delivering today

If you can’t draw the gap, you can’t close it.

Action:

1. Run a “Narrative vs Reality” workshop with Product, Engineering, Sales and Support.

2. 60 minutes. Whiteboard only.

3. End with two columns: What we claim vs What we defend.

4. If the lists don’t match, that’s your agenda to resolve and get alignment around asap.

2. Identify your “Motte dependencies”

These are the features, behaviours or processes you rely on for survival — even though they contradict the story you want to tell.

Examples:

• The onboarding wizard everyone hates but customers refuse to migrate off

• A single workflow that props up 30% of revenue

• A brittle back-end service blocking every other roadmap innovation or strategic bet

• The manual ops process everyone pretends is automated

These normally surface as annoyances, but they are structural risk hotspots.

Action:

1. Name them.

2. Rank them.

3. For each, decide: protect, modernise or retire.

4. If everything ends up in “modernise”, you don’t have a strategy, you have a wish list.

3. Shrink the Bailey into something actually defensible

Most product strategies fail because they try to change everything at once.

If you want credibility, shrink the vision until it fits your operating model.
Then grow from there.

Most product strategies fail because they’re too big, too vague, or too divorced from the operating model. They aspire to do everything at once for everyone.

Your Bailey should be the smallest strategic territory you can actually deliver with conviction — not the largest narrative you can present to the board or put in a deck.

If you want credibility, shrink the strategy until it fits your architecture, team shape and delivery muscle. It’s ok to have an aspirational vision and I’m personally a fan of them. But you need to have a strategy behind it that grows deliberately, not rhetorically.

Action:

1. Rewrite your strategy statement in one sentence: “Over the next 30-60 days, we will be defensibly excellent at X and intentionally ignore Y.”

2. If you feel you can’t complete that sentence, the Bailey is still too big.

3. Do this for 30-60 days, 3 months, 6 months and 12 months being intentional above impact expected

4. This creates a basic product strategy template that can evolve dynamically as you learn within each time period.

4. Build a learning loop around the gap

This connects directly to last week’s piece on compounding learning loops.

Real defensibility will come from:
Work (transparently + small + meaningfully + swiftly) + Inspect/Adapt = high-cadence learning, compounding value, real accountability.

Apply that loop to the Motte/Bailey gap.
Don’t just ship features — ship alignment.

Action: Every iteration should reduce the distance between what you say you are and what the product proves you are.

Action:

1. Add a standing agenda item to your product review: “Where did our last cycle narrow the Motte/Bailey gap? e.g. are we closer or our vision than we were before” If the answer is “no or nowhere”, you’re not building defensibility — you’re accumulating narrative debt which will lead to all the problems called out above

5. Align incentives to reality, not narrative

This is where most organisations quietly and invisibly can break.

People don’t really follow the strategy; they follow the incentives baked into process and culture.

If your teams are incentivised on the Bailey vision but rewarded (explicitly or implicitly) for protecting the Motte revenue, they will always default to survival.
Not because they’re wrong, but because the system teaches them to.

Here’s what those misaligned incentives look like in real life:

• Sales quotas tied to legacy features → sales keeps selling the old thing, product becomes the villain for “slowing deals down.”

• Engineering measured by output, not outcomes → teams optimise for volume, not impact, and innovation consistently loses to maintenance or polish.

• Roadmap “commitments” made in QBRs → PMs ship what was promised, not what was learned, killing adaptability and real innovation

• Design rewarded for speed over quality → UX debt piles up and “platform” claims fall apart under scrutiny as small disconnected slices of UI are delivered only.

• Leadership praising “big bets” publicly but penalising small experiments privately → teams stick to safe work and strategy stagnates.

• Performance reviews focused on stakeholder satisfaction → PMs avoid hard truths and keep the Bailey shiny while the Motte rusts.

The majority of investives don’t involve involve money. All of them shape behaviour.

Misaligned incentives will trap you in the Motte forever. As a product leader it is your job to identify what is really going on and surface these more difficult and sometimes more intangible aspects.

Action:

1. Run a simple audit with your leadership team: “What behaviour does this process, KPI or ritual actually reward?”

2. If it pulls people back to the Motte, acknowledge it and change the mechanism — not the messaging.

3. Repeat for what you are noticing and feeling.

Strategic alignment doesn’t happen because you tell a better story or just have the strategy written down in a way people can consume it. It happens because people are rewarded (socially, politically and operationally) for doing the work that makes the story true.

Closing thought

In an AI-first world, anyone can paint a bold story. The real advantage belongs to the product leaders who can close the space between story and substance. That’s why this matters. The Motte/Bailey gap isn’t a philosophical idea — it’s the root cause of slow delivery, eroded trust, confused teams and strategy that never lands. If you can name the gap and reduce it cycle by cycle, you build something far more durable than a moat. You build an organisation that learns, adapts and delivers in reality, not just in narrative. That’s the only defensibility that lasts.

The companies that thrive in this next era won’t be the ones with the flashiest narrative. They’ll be the ones whose narrative matches their operating truth.

Subscribe now

I’ve wanted to do this for a while. Too much product content still reflects the idealised version of the job. Most of the real craft sits with operators who are actually doing it — thinking deeply, listening hard and delivering — not shaping their work to fit an algorithm.

This series is for them. And you.

Each Micro-interview gives you a glimpse into how product leaders think when they’re dealing with complexity, constraint, politics, sub-optimal structures and consequence — the parts of the job most newsletters avoid.

The Micro-Interview format was inspired by an old colleague Eddie Shleyner who went on to create the excellent Very Good Copy. Helping create impactful landing pages and improving your content. Thanks Eddie for giving me your blessing to borrow this approach!

Every Monday, I’ll share a new interview. Short, honest, practical. No hype. Just thoughtful product operators talking about how the work actually gets done day in, day out.

I’m starting the series with Sam Moore, Director of Product Management at Unilink. We first spoke when Sam wanted a candid external view on his next steps, and it was immediately clear he was dealing with real product and career challenges, not abstractions. And it’s exactly leaders like Sam that this series is for. People operating in complex, long-standing organisations where you have to move carefully, earn trust, and still push for improvement and innovation. This isn’t the glossy, idealised Silicon Valley version of product; it’s the version most teams actually live today.

In 388-words, he shares:

• Why systems thinking beats feature thinking

• Why the fight to break a monolith was worth it

• What GOV.UK taught him about trust and clarity

• How AI-ambition can hit cultural and technical limits

• Why consistency, not slogans, builds psychological safety

Here’s Sam.

1. What’s your current role, and what makes it noteworthy?

I’m Director of Product Management at Unilink, building justice-sector SaaS across the UK, Europe, Australia, and New Zealand. What makes it noteworthy is the combination of complexity and impact - our products serve everyone from prison officers to those in custody. Leading product strategy here isn’t just about growth; it’s about delivering dignity and better outcomes in high-stakes, under-digitised environments where they’re needed most.

2. What superpower or lens do you bring to product work?

I bring a system lens fused with empathy. My strength is navigating complexity - connecting policy, operations, tech, and human behaviour - then simplifying that into a clear vision. I maintain strong emotional intelligence throughout, because understanding motivations behind decisions often matters as much as the data itself.

3. What’s a product decision you made that felt wrong to others at first, but proved right over time?

I proposed breaking our legacy platform into modular services despite concerns about cost and risk. Others saw only short-term pain, but I knew the monolithic structure was killing our delivery speed and innovation. The modular approach ultimately enabled us to serve different customer needs with greater agility, leading to stronger retention and ARR growth.

4. Which product (besides your own) changed how you think about building, and why?

GOV.UK reshaped my thinking around product simplicity and user trust in public services. It’s a masterclass in stripping away ego and focusing purely on user needs. The consistency and clarity show that scale doesn’t require complexity. It reminded me that the best public sector products feel invisible - they just work, building confidence in the system itself.

5. Describe a moment when strategy and reality collided. What gave, and what stayed?

We planned to embed AI-driven decision support into our justice products - bold and timely. But we hit fragmented infrastructure and cultural resistance. Instead of pushing through, we pivoted to build trust and data maturity incrementally. Our belief in insight-led systems stayed, but we chose a longer path that respected the environment’s readiness.

6. What’s a leadership lesson your team has taught you that you didn’t expect to learn

That psychological safety isn’t built through words - it’s built through consistency. You can say “challenge me,” but people only will if they’ve seen you respond to disagreement with curiosity, not defensiveness. Showing vulnerability - admitting when I don’t know - is the fastest way to unlock trust and creativity.

7. What moment, belief, or principle defines how you lead?

“Build for dignity.”

This principle shapes everything - from user interviews to feature prioritisation. Whether it’s someone in custody, a frontline worker, or a Junior PM on my team, people should feel seen, respected, and empowered by the products and cultures we create. That’s what good product leadership means to me.

If you’re a product leader that would like to share your views and experiences - send me a message:

Note: Product Leaders is intended to be a newsletter for real product operators who want to get product right in the real world. I’ve noticed an increase in fluff, noise and non-actionable articles on LinkedIn recently. So rather than moan about it, my goal is to cut through the noise to collate some grounded, commercially sharp guidance for product leaders, founders and C-suite teams. No jargon. No hype. Just practical insights on product strategy, execution and building teams that learn fast and deliver with intent. If you care about this rather than chasing the next framework, this is for you.

0. Most conversations about moats in AI still orbit the same clichés.

Data. Models. Scale. Flywheels. All useful, but increasingly insufficient.

Because the truth is uncomfortable for both startups and incumbents: in an AI-first world, the strongest moats are composite, not singular. And the only thing I believe that compounds faster than technology is learning.

1. The old moats haven’t disappeared; they’ve become interdependent

In the past, you could defend a market with one strong edge. Today, the advantage sits at the intersection of three forces:

1. Proprietary data - Not just volume, but structure, meaning and history.

2. Organisational design and behaviour - How fast your teams turn insight into action.

3. Product experience - The quality of your UX, your workflows, your nudges, your activation paths.

Individually they help. Combined, they compound. This is what I meant by “composite moats”.

The defensive wall isn’t a single asset; it’s the connection between them. Think of it as a flywheel of strategic learning rather than strategic assets.

2. Why AI makes adaptation the real moat

AI has levelled the playing field in ways people underestimate:

• Anyone can spin up a model

• Anyone can plug into an API.

• Anyone can deploy an LLM-powered feature and stick “AI” in the roadmap.

So the question stops being “Can you build it?” and becomes:

“How quickly can you adapt your product and organisation as the world shifts under your feet?”

Incumbents don’t lose because they lack tech.
They lose because they can’t rewire how they work.
The pain is cultural, not technical.

If your release cycles still depend on committees, your moat has already eroded. *insert empowered teams here*[sic] (This is a whole other newsletter waiting to be written about the millions of empowered teams out there with no clear mandate, no actual authority, lacking the appropriate skills or resource and many other dysfunctions yet are really only empowered in name when you get recruited…)

3. The only durable moat: your rate of learning

I’ve held a simple belief for years:

Your learning cadence beats your planning cadence.
Every time!

It’s why I use my own Winning Team Formula:

Work (transparently + small + meaningfully + swiftly) + Inspect/Adapt = high-cadence learning, compounding value, real accountability.

I’m pretty sure this is inspired by something John Cutler shared many years ago, but I can’t find the link. I’ll update if I can find it.

It’s intentionally unsexy.
No jargon. No mythical frameworks - although like any good product person and agile coach, I do, have and will continue to use what really matters as needed.
Just the habits that allow teams to move quickly without creating a mess.

But – and this is the uncomfortable part –it only works if Product is empowered to align the organisation around learning.

If Product doesn’t have the mandate to activate the full depth of the company’s data, talent and IP, the loop breaks. You get “activity”, not progress. You ship, but you don’t learn. You get asked ‘when is that thing going to be done?’.

4. So what does this mean for operators trying to build moats today?

Here are hopefully the practical signals that your organisation is building real defensibility and if not, you could consider:

A. You have a structured learning engine

Not just ad-hoc insights, but a repeatable loop:

• Clear hypotheses that are documented and tested

• Fast experiments and not too many at a time you don’t know what really had an impact

• Honest read-outs with the right audience to make a different

• The whole organisation feeding the same learning backlog

B. You treat data like an operating system, not a warehouse

It’s accessible.
It drives decisions.
People know how to get what they need from it and time has been invested in training them to actually use it as they need
Your AI features don’t exist in isolation; they make the whole product sharper.

C. Your product surface area is designed to compound

Every workflow, every nudge, every touchpoint helps you learn something useful about behaviour. (Massive Posthog fan here for this sort of thing)
This is where UX becomes a moat, not just a cosmetic layer.

D. You’ve built organisational muscle around adaptation

Teams make small bets. Lots of them. And you actually realise a lot of them didn’t work. And that’s ok.
Leaders remove drag, not add process. They actually get out of the way.
You ship, measure, adjust and repeat. Simple really…note you don’t measure, adjust, repeat, then ship. The order matters!

E. Your culture rewards truth over comfort

If your metrics tell you something painful, people aren’t punished for saying it aloud.
Moats rot when people protect their slide decks instead of their users.

5. The uncomfortable but liberating conclusion

AI has not killed moats.
I think it has raised the bar on what counts as one.

So this is my thesis (or is it a princple, or mini-manifesto, or mental-model [another impending article]):

• Your product wins when your organisation learns faster than your competition.

• When you can turn data + behaviour + UX into a system that evolves continuously.

• When teams know how to operate in ambiguity because they aren’t waiting for permission.

As true as I will always order whatever variation of Pepperoni and Nduja if its on the pizza menu…Tech will keep accelerating. LLMs will keep closing the gap between idea and implementation. But the companies that pull ahead will be the ones that can answer one simple question:

How quickly can you learn the thing your competitor hasn’t realised yet?

That is the real moat.
And it’s entirely within your control*

*unless you don’t actually have control over your product - then that is a whole volume of newsletters waiting to be written!