Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

OODA Loops in Product Management

DZone's Guide to

OODA Loops in Product Management

How is product management like warfare? Read on to see how the concept of the OODA loop dictates good strategy for product management in DevOps.

· DevOps Zone ·
Free Resource

Discover how quick and easy it is to secure secrets, so you can get back to doing what you love. Try Conjur, a free open source security service for developers.

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 more quickly through this loop has a better chance of 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 of 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.

Conjur is a free open source security service built by DevOps engineers. With integrations with all your favorite tools and an easy way to secure secrets, it's a no brainer. Come check it out!

Topics:
devops ,product management ,software delivery

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}