Does the fastest team win? No.
Does the largest team win? No.
Does the team with the most money win? No.
Does the smartest team win? No.
Does the first team to market win? No.
Does the most efficient team win? No
The team that changes the fastest wins.
Why is the ability to change so important?
Well, it’s because none of us know what we’re doing.
Business is not physics. There are no laws. No handy equations that explain the fundamentals of our environment. Business is messy. It’s uncertain. It’s a massive fog of confusion, half-truths, guessing, and random luck. And even when something starts to work consistently, it doesn’t stay that way for long. The meta-game is constantly evolving. Markets change because people are constantly changing. Nothing is static.
Now, most people spend their entire careers fighting this uncertainty by trying to contain it. They’ll build 100-page business plans, 10-year financial projections, 3- to 5-year plans, and approval processes that require a dozen signatures from different stakeholders.
What if we flip it? Instead of trying to control the uncertainty, we embrace it. To do that, we’d have to admit a couple of fundamental truths to ourselves:
- None of us have any idea what’s going to work.
- It’s not our job to predict what will work ahead of time.
- We don’t decide when something works, our customers do.
- All wins decay with time.
In other words, the faster we can test different ideas, get feedback on how those ideas perform, and move on to the next idea, the more effective we’ll be in this highly uncertain game.
How do we know if we’re changing quickly enough? How do we measure this?
One of the most important military strategists of the last century, John Boyd, built a framework for improving and measuring a team’s capacity for change. It boils down to a simple question:
How fast can you move through an OODA loop?
The OODA loop
Observe — Building your feedback loop
First and foremost, we must see our environment. With an online business, this takes a lot of work and never happens by accident. With a warehouse, you can see the inventory piling up. With a retail business, you can see customer reactions in person every day.
For online businesses like yours and mine, we don’t see a damn thing unless we work for it. And you better be working for it. To do this well, you must put in the effort up front to collect the quantitative and qualitative data you need in order to determine if you’re making progress. I’d make sure you always have:
- A strong sense for your primary key performance indicator (KPI)
- The ability to break down that KPI so you know which piece is working or not working
- Accurate data in your reporting (always question the data in front of you until you know you can trust it)
- A reliable source of qualitative feedback to give you ideas for why your KPI is increasing or decreasing
Note: If you don’t have the data you need, you need to build the means to get it. Also, you MUST include data from the outside world. This can’t be an internal loop, otherwise you’ll just spin in circles. Remember: “Internal stakeholders” are not the customer, customers are the customer.
Orient — Defining your hypotheses
We have our data, now it’s time to interpret that data.
Here’s what folks typically say to themselves after gathering data:
“Oh, that’s an interesting data point. Time to go work on that other project that I’ve been meaning to do for the last three months.”
When new data comes in or a new project goes live, you CANNOT immediately rush to the next project on your list. You and your team have to pause to interpret what that data means.
This is why I harp on coming up with hypotheses so often. They’re a way of interpreting our environment by saying, “Based on everything we know today, if we do X, Y will happen.”
Without this orientation, you’re in a backlog treadmill, endlessly chewing through whatever random project comes up in your queue. That’s not how you drive a business forward.
Also, be very careful that you’re focusing your hypotheses on the most important problem. Most people just insert whatever random theory they’ve had regardless of how the environment has changed recently.
- Define your most important problem first based on the data you now have.
- Then come up with hypotheses to solve that problem.
Decide — Make a call and commit
Once you have your hypotheses and analysis, it’s time to decide.
Look, this is a judgement call. There’s no guarantee of success, that’s the entire point of operating in an environment full of uncertainty. That’s the name of the game in online businesses.
For myself, I’m looking for hypotheses that are big enough to matter (most folks try ideas that are way too small) and can also be launched fairly quickly (no six-month projects). Anything that will take more than 30 days to complete an OODA loop makes me nervous.
If you’re having trouble deciding which project to take on, here’s the simple framework I always go back to in order to make a decision:
- Rate your ideas on a 1-3 scale for how easy it is to ship.
- Then rate them on a 1-3 scale based on your predicted impact.
- Multiply the scores and rank.
- Start with the idea with the highest score.
- If there’s a tie, skew towards ideas that have higher expected impact.
Act — Get your decision live as soon as you can
Now that you’ve decided what to do, only one thing remains: make it a reality.
During this stage, it’s critically important NOT to waver on your decision or reverse it. Unless you’ve observed a radical change in your environment, in which case, it’s time to start the whole loop all over again.
When you and your team are in this stage, only one thing really matters: How can we get your idea live as fast as possible and see if the environment changes?
No one gets any credit for anything until the idea is live and we’ve completed our OODA loop.
Really drive that execution. Do less stuff, put concurrent projects on hold, and get that core project out the door. Until it goes live, we don’t have a chance to learn anything. And if we’re not learning, we can’t change with intent. Any change we implement in the meantime is merely floundering.
Once you go live, remember to go back to the observe stage and start the loop all over again.
Implementing OODA loops
Most people go through the motions of these loops without actually doing them. They’ll use bits and pieces or go through the motions without actually changing anything. And as soon as something starts to fail, they’ll immediately fall into old habits of trying to plan their way out of a mess.
So here’s a number of signs to tell whether or not you’re actually using these loops.
Signs that you DO NOT have an OODA loop
You judge your success based on meeting deadlines.
Look, the world does not care about your deadlines or if you checked all your boxes. The world cares about you giving them something they care about. Deadlines are a tool to keep ourselves accountable, they don’t tell us if we’re successful.
You have dashboards and reports with dozens of metrics.
If you cannot explain how you’ll change your priorities based on a specific metric, you shouldn’t be looking at that metric. Don’t drown yourself with data, focus on just a couple that help you make real decisions.
You just scoped a project with multiple phases.
The results of phase one will probably tell you to go in a completely different direction. And the environment will probably shift by the time you even get to phase two and beyond.
You ship something once and then move on to the next project.
Instead of iterating on a project until it has the impact you’re looking for, you move on to the next project in your queue.
To produce quality work, you get feedback from people who aren’t customers.
A lack of a relevant, external feedback loop should terrify you. Find one.
You operate with a “spaghetti wall mindset.”
Let’s just throw a bunch of stuff on the wall and see what sticks, right? Wrong. That’s a luck-based strategy. You need to focus on the quality of every bet to make sure you’re genuinely learning with each OODA loop. Work on the right problem.
You’re building infrastructure before you know if something works.
Over-engineering anything means you’re slowing down your own OODA loop. You don’t even know if it’s going to work yet. Start with a hacky solution, then build the real infrastructure once you know it works.
When asked how to make something work, you list dozens of items to focus on.
Yes the world is complex. Lots of variables comprise every problem. But instead of methodically learning which variables matter, you try to describe all the complexity at once. Which means you don’t know which variables matter more than others.
You regularly make mistakes on execution, which botch your learning.
The only thing worse than a slow OODA loop is an OODA loop that doesn’t tell us anything because the project was dead on arrival from poor execution. If you can’t execute on your hypothesis, you’ll never have a chance to find a win.
You’re using the data you have available.
You shouldn’t take the OODA loop you’ve been given, you should build the OODA loop that you need.
When you’re overwhelmed, you seek control and planning.
The greater the uncertainty, the greater the impulse to reign projects in and personally oversee more of them. This is usually a mistake. Instead, make sure your OODA loop is stable and that your teams know how to move through them. Then increase speed through the loop. Lastly, improve the quality of the orient step. After that, pray.
You’re working on dozens of projects concurrently.
Nothing slows an OODA loop down like trying to do multiple OODA loops at once. Do fewer things faster so you can increase the number of OODA loops that you complete.
Signs you DO have an OODA loop
You judge your success based on seeing a genuine lift in a core metric.
Your work isn’t done until you’ve gotten external feedback that the business has changed for the better.
You don’t know what you’re doing next month and you’re completely okay with that.
If we’re rapidly moving through OODA loops, our priorities will be changing in a major way every month. And we won’t really know what we’re working on past 30-60 days.
You’ve iterated on a project dozens of times in order to get it to work.
Settle in and get used to having to iterate on your work 10-plus times before it makes a difference.
To produce quality, you get feedback externally.
Quality work is only produced after many iterations based on feedback from an external source.
You’re testing your idea manually, then building the infrastructure once it works.
Doing a project manually is a great way to get through a single feedback loop faster. Build the infrastructure you need later once you know it works.
Before trying something, you focus on the most important hypothesis you need to test.
Before queueing any project, you always ask yourself “Is this the most important project I need to work on right now?”
When asked how to make something work, you list 2-3 items to focus on.
You’ve taken the time to methodically test the dozens of other possibilities and you know they’re not important. We only understand something once we can explain it simply. Complex solutions or explanations mean we don’t understand what’s truly important.
You’ve taken the time to get the data you really need, you’re in control of your feedback loop.
You know your data and KPIs cold. Observing your environment accurately is so important that you have personally verified every piece.
When you’re overwhelmed, you seek more attempts.
When your back is against the wall, you ask yourself: “How can I go through my OODA loop even faster so I get more attempts before it’s game over?”
You’re working to train others so they can make more decisions on their own.
OODA loops always work faster when the folks closest to the problem own the entire loop. Granted, folks need to be skilled enough in their area to work through the entire loop so it might not be possible right away. But you’re working to get them there.
You’re working on your single most important task above all else.
One completed OODA loop today is more valuable than two OODA loops tomorrow. Get the most important project out sooner so we can then change based on another round of feedback.