Grounded: Product Management Lessons from the Southwest Airlines Fiasco
As a product manager and trainer, the recent Southwest Airlines flight cancellations over the holidays hit close to home for my family and me. We were one of the many passengers stranded at the airport, and it got me thinking about the challenges that growing organizations face in the product management space.
One of those challenges is managing and paying down tech debt. For those unfamiliar with the term, tech debt refers to the cost of maintaining and updating systems and technology platforms as they become obsolete or unsupported. As a product leader, I strongly encourage product managers to build strong relationships with their tech leads and address tech debt in every sprint cycle. If unchecked, tech debt can slow down teams, bring operations to a halt, and require significant cleanup.
I’ve read that Southwest Airlines had a system failure directly related to not addressing their tech debt over time. They needed to keep track of their crew and pilots after many flights were canceled, but their outdated systems could not handle the increased load. This lack of investment in technical architecture and infrastructure was one of the reasons the airline had to shut down for a few days to reset its schedule.
In our training and workshops, we stress the importance of allocating a portion of resources toward paying down technical debt. We also provide critical strategies for getting leadership to buy into this investment and its associated ROI.
Another critical challenge in product management is understanding the voice of the customer. Southwest Airlines is known for being very customer-focused, with reasonable fares, friendly flight crews, and an expansive flight schedule. However, “customers” are not just those who check in their luggage and fly to their destination. Customers include frontline employees such as customer service, baggage handlers, accounting, and sales.
In the case of Southwest, their frontline employees had been seeing the deterioration of their operations system for many years, and their voice and feedback needed proper consideration. Our training and workshops emphasize the importance of understanding an organization’s different ” voices, ” not just external customers.
As a product manager, your primary responsibility is to grow the business, but you also need to make sure you allocate a portion of resources for your internal customers. Their voices are just as critical as your paying customers.
Southwest Airlines is just one example of how easy it can be to get caught up in serving primary paying customers. Still, it’s important to remember that there’s more to product management than just calculating ROI. As product leaders, we need to have a holistic view of our product and organization, including protecting our platforms’ health by investing in technical debt and listening to external and internal customers.
Webinar Q&A Follow-Up
We had a lot of really great questions during and after the webinar; we just couldn’t get to them all. I wanted to take some time to address 6 questions that we didn’t get to.
How Do You Prioritize Your Tech Debt?
This should be a conversation that a product manager, product owner and engineering manager have together. Product management is a team sport and in many cases where I’ve been really successful in managing tech debt I’ve tried to delegate that tech debt, that prioritization, to my engineering manager.
Now, if you haven’t had that discussion, the way to think about that is it really falls into multiple categories. It could be managing your risk, it could be compliance, it could be a revenue or security risk component.
As an example, many years ago, when I was working in fintech, we would do pen testing. Pen testing is when you hire a third party to come out and try to poke holes and find any vulnerabilities in your platform. The agreement was anything that came back from the pen test vendor became high priority items; those immediately moved up to the top of the backlog. But that was an agreement I had between myself, my product owner and my engineering manager tech.
What you can do as a project leader is have the discussion with your engineering manager. Try to understand the impact. Try to build into your team working agreement: what are those different categories and what falls in the “immediate bucket” versus the “I can get to it later bucket?” It’s a negotiation that, when done right, allows you to always be paying down your tech debt.
Does it Take a Massive Failure Before Action is taken to Make Technical Debt a Priority?
The short answer: hopefully not. You don’t want to wait for disaster. Your job as a product manager is to communicate and educate stakeholders about what technical debt is and its importance. Don’t wait for disaster, but instead take what happened with Southwest Airlines and provide a summary and explain how you want to avoid that from happening at your company. What you want to do is use it as an opportunity to tell a story and to try to get some buy-in from your stakeholders, so that way you’re not making the same mistake that Southwest Airlines made.
Part of your job it to help everyone understand that it’s not about having to make a decision between making an investment in a new capability and paying down tech debt. Instead, you should be working with your engineering manager, your I.T. team to figure out how can you do both together.
Should Technical Debt Be Handled Differently with Internal Customers?
Short answer: no. When we’re thinking about managing technical debt the strategy should be the same with internal and external customers. You should allocate a portion of each sprint towards paying down tech debt, and the impact for managing tech debt with internal customers is very noticeable.
What was the impact for Southwest Airlines when they didn’t pay down the tech debt for their internal customers? Well, their flight attendants, baggage claim handlers, people on the front line, all of them were not able to perform their jobs at the level expected, which directly impacted the experience for their external customers. It’s important to keep in mind that tech debt for internal customers has a very real effect on external customers, and the internal tech debt needs to be managed appropriately.
How Much of Your Sprint Should be Dedicated to Technical Debt?
It’s going to really depend on where your product is in the maturity. For example, if you have a product that’s new to the market, let’s say you’re a startup, then your tech debt may be very minimal. You’re in a growth mode, so it may be 10%. However, as you release new features you’re going to accumulate a little bit of tech debt with every new release.
The earlier you are in your product lifecycle that percentage is going to be really low and you should be able to pay down the debt quickly. However, in the case of most product managers, where you have a mature product, you want to be in this in the range of around 20% to 25%. As I said before, this is a negotiation you need to make with the members of your team.
You want to be in a position where you’re still allocating the majority of your work, around 60% towards those new, bigger capabilities that are going to delight your customers. That gives you around 40% to keep your existing customers happy.
What this looks like in reality is one or two user stories within each sprint towards my tech debt. But again, have that negotiation and the discussion with their engineering manager to come up with the right percentage that works best for you.
How Can Product Managers Get Stakeholders to See the Value in Better Maintaining Technical Debt?
Sometimes, I’ve seen product leaders think they have to justify doing tech debt instead of the big, new and shiny object, or the new initiative. That’s really where the misunderstanding happens. When I partner up with a lot of organizations and teams, I try to stress the importance of doing tech debt and new features asynchronously. Meaning, in a given sprint, you should be delivering both value to your customers as well as paying down your tech debt during a sprint, (in the form of a couple of user stories).
If stakeholders are asking questions around tech debt, try to understand it from their point of view. Product managers often talk about empathy for our customers, but we also need to have empathy for our stakeholders.
In many cases, stakeholders don’t want to think that the investment they’re making into an entire sprint is only on fixing stuff. They want to know that things are still happening to move the business forward. You have to appeal to their concerns and help them understand that you’re going to do both.
How Should Product Managers Manage Dependencies When it Comes to Technical Debt?
It’s not uncommon to see a need for alignment across different teams when it comes to tech debt. The only way to tackle the tech debt is to have transparency and alignment.
To get aligned you may need different events like Scrum of Scrums, where you get your scrum masters together with some regular cadence and you have them meet and talk about those key dependencies that you relying on. Or you may get your product owners together with some regularity and discuss those different dependencies.
One of the ways that I find a lot of value when I’m working on dependencies across the organization is utilizing a technique called quarterly planning, where as a product team you’re getting together on a quarterly basis any teams that you interface with your product, and you’re going to be talking about what is your strategy for that quarter. That strategy not only includes what you’re going to be doing for the new capabilities that you want to deliver, but that strategy includes what are you going to do to manage your technical debt so you can identify the key dependencies and key risks ahead of time.
Then what you can do is you can be transparent about it not only with your product team but with the other teams in the organization. And then you’re going to manage those dependencies through those different events mentioned earlier. Be transparent and clear about what your dependencies and what your risks are and who or how are you going to manage what those dependencies look like.
About the Author
Joe Ghali – Principal Consultant & Trainer at 280 Group
Joe Ghali is a Principal Consultant and Trainer at 280 Group. With over 15 years of experience in Product Management working for Fortune 100 & 500 organizations, he has been part of several significant product launches throughout his career. Joe’s experience as both a Product Manager and Product Owner has given a strong conviction that the most successful products are the result of strong Product and Agile teams who are transparent, collaborative, and vulnerable. And the key to those high performing teams is strong Product Management leadership at the helm.