Why Everyone Is Suddenly Asking About Lean Startup Again
Over the past few months, a noticeable share of the enquiries coming into McKenna Agile Consultants have had the same shape. A leadership team has a strategy they believe in. They have some form of Agile delivery in place. Some have OKRs. And yet execution still feels slow, expensive and oddly disconnected from what customers actually do. More and more of them are asking the same question: should we be running strategy the way a startup does?
Eric Ries published The Lean Startup in 2011. The ideas are not new. What has changed is the speed at which an organisation can now build something and put it in front of a real customer. AI-assisted development, low-code platforms, cloud infrastructure and AI agents that draft, test and summarise have compressed the cost of an experiment from months to days, and sometimes hours. When an experiment is that cheap, the rational thing to do is run more of them. That is the whole premise of Lean Startup, and it is why the approach has moved from the incubator to the boardroom.
In this post I want to set out how the Lean Startup approach fits with the frameworks most UK organisations already use, namely Agile, OKRs, Lean Portfolio Management (LPM) and the broader discipline of strategy execution. They are not competing methods. Used well, they are one system.
What the Lean Startup Approach Actually Is
Strip away the Silicon Valley mythology and Lean Startup is a disciplined way of reducing uncertainty. It rests on three ideas.
First, every strategy is a set of assumptions, not a set of facts. Ries called the two most important ones the value hypothesis (customers want this) and the growth hypothesis (we can reach them and they will keep coming back).
Second, the fastest way to test an assumption is the Build-Measure-Learn loop: build the smallest thing that can generate real evidence (the minimum viable product, or MVP), measure what happens with actual customers, and learn whether to persevere or pivot.
Third, progress is measured through validated learning, not through output. Shipping a feature nobody uses is not progress. Discovering in a fortnight that nobody wants the feature is.
Validated learning depends on leading indicators. Revenue, market share and customer retention are lagging indicators: by the time they move, the decision that caused them is months old. Lean Startup asks you to find the earlier signals that predict them, such as activation rate, repeat usage in the first week, or the share of customers who complete a trial, and to run your experiments against those.
If you have been anywhere near Agile or OKRs, that should sound familiar. It is the same philosophy, pointed at strategy rather than delivery.
AI Has Changed the Economics of Experimentation
This is the part that explains the timing. Ten years ago, a “small experiment” to test a strategic bet might have involved a six-week build, a data engineering ticket, and a slot on a release train. In practice, most organisations skipped the experiment and just committed.
Today a cross-functional squad with AI in the loop can prototype a customer journey in an afternoon, draft the test script, generate the survey, analyse the responses and summarise the learning before the next check-in. In our own AI-First delivery work, we routinely see cycle times fall by half or more once teams stop treating AI as a novelty and start treating it as a member of the squad. We have written previously about what AI agents actually do in OKR execution, and the pattern is consistent: the bottleneck moves from building to deciding.
When building is no longer the constraint, the constraint becomes how quickly leaders can frame a hypothesis, agree what evidence would change their mind, and act on it. That is a strategy execution problem, not a technology problem. And it is exactly the problem Lean Startup was designed to solve.
How Lean Startup Fits With Agile
Agile answers the question “how do we deliver in small, valuable increments?” Lean Startup answers the question “how do we know the increment was worth delivering?”
A Scrum team can be beautifully agile and still spend a year building the wrong product one sprint at a time. Velocity is not validated learning. The Lean Startup mindset adds a layer above the sprint: each increment should be framed as a test of a specific assumption, with a measurable signal agreed before the work starts.
In practice this changes three things in a squad’s ways of working. Sprint goals become hypotheses (“we believe that if we simplify the onboarding form, completion will rise above 60%”). Sprint reviews become evidence reviews, where the conversation is about what the data said rather than what was shipped. And retrospectives start to include the question “what did we learn about the customer?” alongside “what did we learn about ourselves?” We covered how AI can sharpen that conversation in our guide to redesigning sprint retrospectives with AI.
How Lean Startup Fits With OKRs
This is the pairing we get asked about most, and it is the most natural one. An Objective is a strategic bet. A Key Result is the evidence you have agreed will tell you whether the bet is paying off. A quarter is a Build-Measure-Learn loop with a calendar attached.
Where OKR programmes go wrong is when Key Results describe output (“launch the new portal”) instead of outcomes (“40% of customers self-serve by end of Q4”). Output-based KRs cannot be invalidated. You either shipped or you did not. Outcome-based KRs behave like a Lean Startup metric: they tell you something true about the world, and sometimes what they tell you is that the strategy needs to change.
The best Key Results are leading indicators. If your Objective is to grow revenue from a new service line, a KR of “£2m annual revenue” tells you nothing until the year is over. A KR of “30% of existing clients trial the new service by end of Q2” tells you within weeks whether the bet is on track, and gives you time to pivot if it is not. When we refine OKRs with clients, this is the single most common change we make: swapping a lagging KR the team cannot influence in-quarter for a leading one they can.
That is also why the OKR check-in matters so much. A weekly check-in is the “measure” step. If your teams are only looking at Key Results at the end of the quarter, you are running one experiment every 90 days when you could be running twelve. Our OKR Check-In Playbook sets out the weekly rhythm we coach, and our OKR execution services exist precisely because writing OKRs is the easy part. Running them as a learning loop is the discipline.
One practical tip from our engagements: write the pivot condition down when you write the OKR. “If this leading KR is below 20% at the mid-quarter review, we will stop and rethink the approach.” It sounds obvious. Almost nobody does it. Ries called the alternative “achieving failure”, which is executing a plan flawlessly that should have been abandoned in week three.
How Lean Startup Fits With Lean Portfolio Management
If OKRs are Lean Startup at team and department level, LPM is Lean Startup at the portfolio level. The idea, drawn from Lean and from the Scaled Agile Framework, is that funding should flow to value streams and strategic themes rather than to fixed-scope projects, and that the portfolio should be reviewed and rebalanced continuously.
Traditional annual budgeting is the enemy of Lean Startup. It forces leaders to commit twelve months of funding to a set of assumptions in November, and then punishes anyone who discovers in February that the assumptions were wrong. LPM replaces that with a portfolio Kanban, lean business cases sized as minimum viable investments, and guardrails that let leaders release funding in tranches as evidence accumulates.
We see this landing well in mid-sized UK and US firms that are not running full SAFe. You do not need the whole framework. You need a visible list of strategic bets, an honest view of how much each has consumed and what it has proved, and a monthly forum where leaders can stop, continue or double down. Our thinking on what happens to scaled Agile in an AI-first world goes deeper on why the portfolio layer is the one most in need of this shift.
Putting It Together: One Operating System for Strategy Execution
Here is how the pieces line up in the organisations we work with that are doing this well.
| Layer | Question it answers | Lean Startup mechanism | Cadence |
|---|---|---|---|
| Strategy | Where are we placing our bets? | Strategy as explicit hypotheses with lagging outcomes | Annual, reviewed quarterly |
| Portfolio (LPM) | Which bets get funded, and for how long? | Minimum viable investments, tranche funding | Monthly |
| OKRs | Are the bets paying off? | Leading-indicator Key Results with pivot conditions | Quarterly, checked weekly |
| Agile squads | What is the smallest thing we can test next? | MVP increments, evidence reviews | Fortnightly or continuous |
| AI in the loop | How fast can we get to evidence? | Automated build, measure and summarise steps | Daily |
The thread running through all of it is cadence. Strategy execution fails in the gaps between the layers, when the portfolio is reviewed annually, OKRs are checked quarterly and squads ship fortnightly, and nobody joins them up. A Lean Startup approach forces the question at every layer: what did we learn, and what will we do differently as a result?
Three Things UK Leaders Get Wrong When Adopting Lean Startup
Mistaking “MVP” for “first delivery.” A minimum viable product is the smallest thing that generates learning. If the thing you ship cannot tell you whether the hypothesis was right, it is not an MVP, it is just a small project.
Running experiments without decision rights. A squad can learn in a week that a strategic bet is wrong. If it then takes three months and a steering committee to act on that learning, you have a Lean Startup team inside a waterfall organisation. Decision rights need to move with the cadence. This is one of the nine boxes in our Agile Implementation Template for exactly this reason.
Measuring activity, or only lagging outcomes. Vanity metrics are the Lean Startup equivalent of output-based Key Results: number of experiments run is not a result. But the opposite failure is just as common. Teams set KRs on annual revenue or NPS, which are real outcomes but move too slowly to steer by. The discipline is to find the leading indicator that predicts the outcome you care about, and check it weekly.
Where to Start
If you are a leader with a strategy you believe in and an execution engine that is not keeping pace, you do not need a new framework. You need to run the ones you have as a learning system.
Start with one strategic bet. Write it as a hypothesis. Agree the Key Results that would prove or disprove it and the point at which you would pivot. Give a squad the authority and the AI tooling to get to evidence in weeks, not quarters. Then review it monthly at portfolio level and act on what you find.
That is the Lean Startup approach to strategy execution. It is what Agile, OKRs and LPM were always meant to add up to. The difference now is that the technology has finally caught up with the idea.
Talk to Us About Strategy Execution
We help leadership teams across the UK, Europe and the USA turn strategy into a rhythm of small, measurable bets, using Agile delivery, OKRs and practical, hype-free AI. If you would like to talk through how this could work in your organisation, book a free consultation with one of our practitioners.
You can also explore our OKR services, Agile services and AI-First delivery pages, or get in touch directly.
Aaron McKenna is the founder of McKenna Agile Consultants, a Harrogate-based consultancy specialising in Agile delivery, OKRs and AI-first ways of working. Aaron and the team have worked with organisations including Numatic International, Bettys & Taylors Group and IMI plc to close the gap between strategy and execution.
