What product managers and fighter pilots have in common

Maverick gives a thumbs up to good product management

Truth be told I’m not a fighter pilot but Top Gun was my favorite moving growing up so hear me out…

In the 1960s an Air Force pilot and military strategist named Col. John Boyd developed a decision-making process called the OODA loop. In short, the OODA loop is a continuous cycle in which an individual observes external data, orients himself based on his internal factors (i.e. experience, thoughts, and beliefs), decides on a potential course of action, and then acts.

Image credit: https://commons.wikimedia.org/w/index.php?curid=3904554

The key to the loop is the speed at which it’s completed. If you cycle through the process faster than your opponent then you can gain the advantage by “getting inside” his loop and forcing him to react to your moves.

A perfect example of this occurs during a training mission in Top Gun:

https://www.youtube.com/watch?v=fGeiL1uhMxU

During the dogfight, Jester gains the initiative first by getting on Maverick’s tail and inside his OODA loop. However, Maverick turns the tables by maneuvering behind Jester, effectively disrupting his loop and winning.

So what relevance does this have to product managers?

A similar cycle exists in product development called the customer feedback loop. It occurs when a team builds quickly — and minimally — so that they can get something into the hands of the customer in order to receive feedback and iterate.

Although there’s no distinct “opponent” in the customer feedback loop, the importance of speed is the same. The faster a product team can cycle through the loop, the greater their chances of success.

Simply put, the speed of the cycle allows them to build the exact solution to its customers’ problems, albeit in small increments. Conversely, if they attempt to build too much at once they risk finding themselves in a situation where they lack critical feedback and miss the mark when they eventually ship.

Also, small iterations are critical because they allow teams to experiment and learn quickly. This helps minimize the risk of failure, especially in the early life of the product. Even if the incremental release fails the team doesn’t sacrifice much time and energy. On the other hand, a big release requires a bunch of assumptions during the course of development, any one of which can cause the entire thing to fall flat.

What do you do if you find yourself outside of the customer feedback loop?

  1. First, talk to your customers. This means having live conversations where the goal is to develop a clear understanding of the problems they want your product to solve.
  2. Next, tease out broader themes you’re hearing. These will help inform what to build.
  3. Finally, speed up your cycle time of your feedback loop by shipping small iterations to your customers and immediately reaching out for feedback.

More on how to conduct customer conversations in a future post. Until then, be sure to get permission before buzzing the tower.

Like what you read? Give Patrick Donohue a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.