Being a Product Manager is awesome, but a few years ago I realized that it’s not nearly as interesting as what my brother does. He’s a commercial airline pilot.
Every time we are at a bar, my brother is hounded with questions like “How does wing lift work?” or “Do I really have to turn off my phone during takeoff?” Me, I’m lucky if I get “oh, cool. You manage software development…”
So, yeah. Fine. He is cooler than me!
After listening to hundreds of these conversations I started realizing that our jobs are not that different after all. In fact, there is a lot product managers can learn from pilots. At the most fundamental level:
- We are both trying to go from Point A to Point B
- We are both trying to achieve a complicated task that involves a lot of risk
- We both have people’s lives in our hands
No, we don’t actually have people’s lives in our hands. That’s a critical divergence that we can learn a lot from.
Risk Leads to Hard Lessons
As product managers, we fail often. We tell ourselves that it’s alright because we “learned” from it. This emphasis on failing fast sounds nice, but not exactly applicable everywhere. Can a pilot say “we killed 47 people, but it’s OK, we learned something”?
Some lessons are so painful you need to learn them only once. Not only you, but the entire industry won’t forget them. These hard lessons force robust processes to make sure nobody needs to learn them again.
You are probably thinking there’s no such thing in software.
One word: Agile.
If you see a software company using a Waterfall process you might feel the same way an airline captain does when seeing someone fly near mountains without altitude instruments: fear for their lives. So much so, that we’ve built robust processes around Agile, wrote books, hired consultants. Enough said.
The airline industry has faced thousands of these hard lessons and has learned from them. Product managers, meanwhile, experience disasters all the time and yet we (and our peers) keep making the same mistakes.
It’s for this reason that I want to leverage the hard lessons from the airline industry and apply them to product management. These are some of the big ones I’ve been able to apply in my work:
Preflight Procedure
Captains and first officers (a.k.a. co-pilots) have very strict procedures, which are the result of hard lessons. Someone, someday, somehow forgot to measure the fuel available before takeoff and now there’s a written procedure for it.
Seems obvious: you are doing something risky, so make sure you check your list.
Is the runway clear for takeoff?
Before moving the plane, captains check in with the tower to make sure it’s safe to taxi and approach the runway. In PM terms, this means letting your manager know when you are kicking off a big project. It can be a simple FYI, but your manager has a level of visibility that could prevent unnecessary accidents.
This is your captain speaking
Imagine you are mid-air and the plane starts shaking. Experienced travelers might know that to be severe turbulence, but some travelers might get really anxious. Your dev team can feel the same anxiety when business turbulence strikes. Communicating that they can expect a bit of turbulence on a given project can make a big difference.
Mayday, Mayday, Mayday
Your flight is going well, until… you start approaching the runway and discover your plane has been leaking oil and your landing gear isn’t working. Airline captains train quite a bit for emergencies, although, thankfully, they encounter them much less frequently than PMs.
PMs deal with Mayday scenarios a lot. You may not crash and burn, but they will be painful:
- There is a problem in production and the person you depend on is MIA.
- You were ready for launch and just discovered a major new requirement.
- The list goes on and on…
What would the pilot do?
Call it in. Yes, right now!
Yelling “mayday, mayday, mayday” to your manager might be an overreaction, but find a way to tell your manager. S/he is likely on solid ground and not in panic mode. They can think and help you find a solution you didn’t think of.
If you are indeed going to crash and burn, your manager can make sure the runway is prepared for the emergency. Because you know what is worse than a crash? A surprise crash. When you surprise stakeholders with a crash there is a good chance you also injure people on the ground.
While it’s likely not your fault that there is an emergency, it becomes your fault if you don’t let anyone know.
It Takes a Team
You are in an emergency and trying to resolve it as quickly as possible. Your heart is racing, your adrenaline is pumping, your brain is in overdrive. You are the captain/PM and you can fix this alone, right? WRONG!
You need help. Captains quickly delegate tasks to first officers so that they can focus on the highest priority parts. This might be your technical lead or just your favorite person. Trust someone to help you because doing this alone is a recipe for disaster.
Abort Landing
Say you determined that your plane is not going to land smoothly. Consider the options:
- Crash land and hope you walk away
- The “go-around:” Circle until you figure out a solution
The answer seems pretty obvious. Nobody wants to crash and burn. Yet the instinct of a PM is often to say “I’d rather hit the deadline, the landing will probably be fine.” That’s madness! Your company wants results, not a perfect score of hitting deadlines. Talk to your manager and come up with a plan. If you have to crash land it, so be it, but at least you talked through the options and you have your manager’s blessing.
Don’t Stretch the Metaphor
These lessons are useful for mitigating risk and dealing with chaos. However, software, unlike flying, doesn’t have to be perfect. In fact, if you try to ship something that’s perfect out of the gate I hear that Eric Ries will haunt your dreams. So, use this analogy with care and don’t refer to yourself as “the captain”. You’ll just look like a jerk.
Most of the time passengers are completely oblivious to the near-death experience they just had, but that means their pilot did an excellent job. Likewise, your users won’t gush over your product because you fixed bugs. The fact is, you are not always going to get an applause for your great work. That’s just the job. You might think you just performed the miracle of flight but your passengers just wanted to get to Point B. Celebrate your own way!
Big thanks to my brother Brian for years of insights. You are awesome and I’m proud of you!
