Fix Delivery First
Hey Ant here 👋 I write a newsletter that won't go viral - and that's the point.
Because hot takes, clickbait and AI slop won't help you ship better products. But practical content grounded in real work will. Join 15,000+ product people who subscribe. Same applies to my YouTube channel!
Recent posts you might have missed:
- Escape OKR Theatre
- How product companies operate without BAs, Scrum Masters, Release Managers, etc
- You Don’t Need Another Prioritization Framework: Just These 4 Components
Why OKRs, discovery, and AI won’t fix your dysfunctions — and what to do instead.
I've observed a pattern after working with dozens of companies to introduce the product model; you can try to talk about strategy, outcomes - even do discovery - all you want, but often their biggest barrier is delivery.
Which is very counter to what you think most organizations need.
Often these organizations have little-to-no discovery, no clear strategy and are very much output focused - so why wouldn't those things help?
I wish it was that simple.
Why they don’t also explains why many attempts to introduce frameworks like OKRs or Opportunity Solution Trees also fall flat.
Perhaps you’ve been there like this VP I’m working with in the Product Mentorship.
Are you shipping faster than you can learn?
Are you shipping faster than you can learn OR are you learning faster than you can ship?
When delivery is good, you can find yourself "shipping faster than you can learn". But that’s a simple fix = Introduce discovery, start talking about outcomes and measure.
In these cases, companies often solve this themselves (although not always, I do get these companies as clients but it’s less transformational and more evolution)
BUT if you're stuck in quarterly releases and long 12+ month initiatives introducing discovery will only lead to "learning faster than you can ship".
Discovery insights go stale, opportunities are missed and OKRs can't be measured turning them into nothing more than a checkbox activity.
Another way to think it is; outcome thinking is only as valuable as your ability to act on it.
I actually had a good example of this yesterday in the Product Mentorship; a PM had done all this great discovery work to solve a key customer problem. He had tested the solution and had high conviction in what needs to be delivered to have impact.
But the company is still stuck in quarterly releases - and worse they had descoped the work for the quarter which means it’s going to be even longer until he sees this follow through.
It’s easy in these roles that you end up looking back and wondering; what did you actually deliver? What impact do you have to show? - so you can probably guess that we’re currently working on landing him a new role.
Of course the opposite isn’t perfect either.
Endless sprints with no discovery, no direction or impact isn’t ideal.
But if you dig a bit deeper - like all great product people should - the problem isn’t as straightforward as being unable to define value - if it was then starting with discovery and OKRs would work.
What the actual problem is
Long delivery cycles are a symptom, not the root problem.
What it actually means is:
We have decades of tech debt that makes everything slow and hard.
We don’t have strong technical leadership and a clear tech strategy.
Because of 1 & 2; we have fragile releases, high regressions leading to low trust with product and engineering.
Low trust means decisions become top down.
People leave and we have a gap in technical leadership
And so forth…
And research backs up my experience.
The DORA research program, captured in the brilliant book Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim, spent over a decade measuring delivery performance across thousands of organisations. What they found was that high-performing teams;
deploy code multiple times a day,
with lead times under an hour
and change failure rates below 15%.
Low performers on the other hand deployed either once a monthly or quarter, with lead times of weeks-to-months.
It’s clear that strong delivery capabilities are the foundation that everything sits on top of.
Until you fix that, no amount of OKR theatre or discovery work will change things.
This feels counterintuitive until you understand The Theory of Constraints.
Theory of Constraints
Mr Beast, widely regarded as the most successful Youtuber of all time, made his first 250 employees read a book called ‘The Goal’ - and you should read it too!
The book’s core idea is the Theory of Constraints. Coined by the author Eliyahu M. Goldratt.
Every system has a bottleneck. One constraint holding everything up.
Until you resolve that bottleneck, trying to fix anything else is just a vanity exercise.
“Since the strength of the chain is determined by the weakest link, then the first step to improve an organization must be to identify the weakest link.”― Eliyahu M. Goldratt, The Goal
This is where I and many others have gone wrong in the past.
It’s not that the company didn’t need to do more discovery, or need more outcome thinking, or to have a clear product strategy.
All of those are true.
But none were the bottleneck.
The wrong assumption is assuming that since those things are absent then introducing them will improve the system.
But as mentioned before, discovery and outcome thinking are dependent on delivery to establish a feedback loop.
Therefore what you’re actually doing is introducing something behind the bottleneck, like trying to pour more water into an already full funnel.
“Show Don’t Tell”
Fixing delivery isn’t just about solving the bottleneck. It’s about earning trust.
A broken delivery is often a symptom of a deeper problem. One where years of piled up technical debt has taught stakeholders to expect things to be slow, expensive and late.
This is also a core reason why in these companies there’s push back against discovery in the first place. It’s seen as yet another ‘slow and expensive’ thing.
And I get it. When you feel like everything takes twice as long as it should you’re not exactly excited about being asked for more time to do discovery.
The fastest way to change this perception is to show them a better way.
I have a coaching principle for how I work with my clients that is; “show, don’t tell”.
I’ve come to learn that I can spend all the time in the world giving examples, talking about how other companies operate but nothing beats rolling up your sleeves and showing them - after all ‘seeing is believing’.
That’s how you earn trust.
As much as we’d love management to unconditionally trust us, it’s a two way street.
Which is why I emphasize the importance of getting quick wins in your first 90 days.
But there’s also a knock on effect.
Not only do you build trust but the bottleneck is often where all the energy and mental capacity goes. Once you resolve it you’ll be surprised to find how quickly the door opens for conversations about discovery, strategy, empowerment, etc.
The best part is, often it’ll be them bringing it up, instead of you.
AI Won’t Fix It… Sorry!
I have to touch on AI quickly because someone will be wondering - what about AI? Isn’t that solving delivery?
But just like how OKRs and discovery won’t fix your dysfunctions, neither will AI.
And I’m seeing companies realise this in real time right now.
AI won’t solve your problems, if anything it’s going to amplify them.
What many companies are starting to learn the hard way is that AI needs a solid foundation.
If you want to give everyone the ability (including AI) to make code changes then you need a strong CI/CD pipeline and automated tests.
If you want to make people more effective with AI then you need to have your data sorted out and context documented. Otherwise AI is flying blind.
If you want AI to speed up delivery but you’re stuck in quarterly enterprise release cycles, then that’s still the bottleneck.
What I’m seeing across my clients and the many PMs I coach is those getting the most ROI out of AI already have a strong foundation to work from.
They were already shipping every couple of days with strong documentation, clear direction, insights and data. Adding AI in to speed things up wasn’t too much of a leap.
However, if you’re like what I’ve described above - which many are - then you’re miles away!
Shipping a feature in a day with AI might as well be on another planet. That’s how much work you have ahead of you, you need to literally get yourself to a new planet first before you can even consider adding AI into the mix.
This has been an eye opening learning for me over the last 12 months.
But it makes sense given the Theory of Constraints.
I framed what I’m seeing like this to a product leader the other week;
“People commonly quote that with AI a senior engineer is now equivalent to ~5x engineers. That’s true in companies with strong foundations, little technical debt, clean architecture, modern software languages, etc. What I’m seeing in enterprises with tech debt, complex tech stacks, etc it’s more like only 1-1.5x.”
And this is part of the argument I made the other week in The AI Chasm. You need to reinvent yourself first. AI just amplifies whatever's already there.
The Anti-hot Take
Look, I get that this isn't sexy advice; "Fix your release pipeline" doesn't get clicks or sell courses.
But every transformation or introduction of a new framework I've watched fail started with addressing the wrong constraint. They spent days at strategy off-sites with consultants or discovery training for product teams stuck in quarterly release cycles.
And I worry that the same is happening now with AI.
AI companies, consultancies - and even Product Coaches who have pivoted to AI content - all selling you something that you’re not ready for.
Worse they leverage clickbait and fear tactics like this 👇(by the way, have a read. You can tell it’s clearly written by AI. “That’s not [blah]. It’s really [blah]”)
But this is the reality and the real work that needs doing.
You need to be intentional, have patience and play the long game.
Start with diagnosing and fixing your bottleneck first. Building trust.
And only then can you get to the meaningful stuff like AI, discovery and strategy later.
I hope that helps.
It’s a lesson I’ve learned the hard way - straight from the trenches, not theory or picture perfect like the books.
This is the type of content I always try to deliver.
Whilst it’s not the most viral, I believe it’s the most impactful and that’s what I’m aiming for.
So if you appreciate the more grounded, hype free take, forward this newsletter to someone who needs to read this.
It really helps this newsletter grow because it’s not clickbait-viral-content so the majority of subscribers come from referrals.
And as always, any questions, hit reply. It comes straight to me.
/Ant
P.s. if you want some help with identifying and solving your bottleneck - hit reply and let’s chat!
Or join the Product Mentorship — this is exactly the kind of conversions I have with product leaders in there.
Now is also a great time to join as the ‘Product Strategy in Practice’ live cohort kicks off in 4 weeks (included in the product mentorship).
Your OKRs don’t live in a vacuum.
Yet this is exactly how I see many organizations treat their OKRs.
They jump on the bandwagon and create OKRs void of any context.
Here’s what I see all the time…