Col. John Boyd came up with a theory of warfare called the OODA loop (Observe, Orient, Decide, Act). He theorized that all military action came down to collecting information, analyzing it, deciding how to act, and acting upon the decision – in short, OODA.
The side that moves quicker through this loop has a better chance for victory. More importantly, speed through the loop would disrupt the opponent’s OODA loop, putting it on the backstep, reacting to situations that have already become irrelevant due to speed. This disruption would turn an edge in conflict into a rout.
While Boyd’s ideas were rooted in military conflict, they are applicable to the world of business as well.
Companies compete through OODA loops in product. Instead of air-to-air combat, a company that is better at “rapidly delivering valuable software” has a better chance for overcoming competition.
This need for speed is reflected in the evolution of engineering tools and processes. Over the last 15 years, we have adopted ideas like continuous integration, continuous delivery, trunk-based development, and microservices, all with an eye toward speed. Today, at the edge of the industry, teams at Netflix, Facebook, and LinkedIn deliver changes to their product hundreds or thousands of times a day.
However, this focus on rapid delivery is broken, as it is concerned only with how quickly we can get code from the developer to the customer, and not on whether it created value for the end user or the business. In other words, we are fixated on the “Act” part of OODA loops.
We need to extend the conversation to what happens after the release. How do we Observe customer impact; Orient in the landscape; and Decide on how to iterate next? Without these other aspects, we may simply be shipping shitty software faster.
So how do we fix this situation?
Product and engineering teams should define metrics that measure the long term value of their product to the end user. The goal should no longer be to just ship a feature, but rather it should be to ascertain how every step impacts those metrics. There are a number of ways to measure this impact, but the gold standard – from companies like Microsoft, Netflix, and LinkedIn – is the concept of experimentation.
Measurement gives us the ability to observe, orient, and decide on how to act next. It is what completes the OODA loop of product management.
Stay up to date
Don’t miss out! Subscribe to our digest to get the latest about feature flags, continuous delivery, experimentation, and more.
With feature flags, you can control the percentage allocation of users you want to be exposed to a specific feature. This process provides risk mitigation and confirms both usability and scalability. Canary releases, or controlled rollouts, serve as an added layer of protection in case something goes wrong. What is…
Feature flagging is a technique development teams deploy to enable easy switches between codepaths in their systems, at runtime. In simpler terms, they’re control structures that toggle on and off the code inside them. Dev teams use feature flags for a wide variety of purposes, from canary releases to A/B…
If our organizations want to survive this period of political and economic uncertainty, they must be able to move with speed and adaptability.