Southwest Fiasco: What every product manager can learn

First, let us say that we at craft.io are fans of Southwest Airlines. The company has been a technology pioneer for decades, and many of its ingenious business practices have forced other airlines to improve as well. Just a few of Southwest’s innovations over the years include:

• Using only one type of aircraft fleetwide (which simplified maintenance and lowered costs).
• Flying point-to-point instead of the traditional hub model (which enabled faster and more convenient travel for customers).
• Offering the industry’s first electronic (ticketless) travel on every flight — an enormous time- and paper-saving convenience for both the airline and its customers.

We’re not writing this to point fingers at Southwest Airlines. The company has gotten plenty of that already. In fact, the goal of this blog is just the opposite: to point out that if a product team as talented and dedicated as Southwest’s can make this mistake, it’s a lesson every Product Manager should learn. If this threat isn’t on your team’s radar, it could hurt your company, too.

Technical Debt Caused the Southwest Debacle

In case you’re not familiar with the term, technical debt refers to what happens over time when a company either puts off addressing a technical problem with its product or chooses an easier but temporary solution to patch the issue for the short term. But a small technical problem today can compound — like financial debt — and become a larger problem later.

If a company devotes all of its time and resources to new and exciting features, that could mean it’s also neglecting the mundane but important work of monitoring, testing, repairing, and updating aging tools. That neglect creates a debt. And if you ignore any type of debt long enough, it can grow into a catastrophe.

For many years, Southwest’s product and technology teams were busy introducing one innovation after another to the airline industry. Southwest was the first to equip domestic US planes with satellite-based inflight WiFi. The company pioneered the “10-minute turn” — getting planes offloaded, boarded with new passengers, and back in the air in 10 (but really, more like 20) minutes. And on and on the innovations came. During that same time, though, these teams were also allowing a small problem to grow bigger each year.

Several of Southwest’s internal software systems had built up such technical debt over time that they eventually collapsed. The airline’s crew routing and scheduling applications, for example, relied on outdated code and ran into problems as predictable as insufficient server space and system memory.

As crazy as this sounds — especially considering what a technologically savvy company we’re talking about — it seems most of Southwest’s thousands of flight cancellations were the result of the airline’s software not being able to accurately track crew around the country and route pilots, flight attendants, and other staff to the right places on time.

And that brings us to the lesson every Product Manager should learn from Southwest’s rare public misstep.

You Need to Balance Pursuing New Ideas (Even Great Ones) with Addressing Technical Debt

In a way, Southwest became a victim of its own success. Having earned such a strong reputation as an innovator, the airline understandably spent an ever-greater amount of time and money pursuing new ideas. In May 2022 (just a few months before the flight-cancellation fiasco), Southwest announced it was committing $2 billion for customer experience and cabin upgrades.

By steering just a small portion of that $2 billion to addressing its technical debt issues, Southwest could have prevented this very public failure. Of course, the public would never have known those upgrades had happened, and Southwest wouldn’t have won any awards or positive media coverage for doing that work. And that’s often the problem with technical-debt issues. It’s not as though putting off updating a piece of software is likely to bring down the whole company today.

Redirecting budget away from headline-grabbing innovations to update a software system no one outside the company even knows exists is a difficult decision to make. But it’s an important one. After all, passengers won’t care about your cabin’s new amenities if you cancel their flights and they never get to see the plane in the first place.

3 Strategies to Become More Proactive About Technical Debt

We know it’s easy to make this point after the fact. And as we said, we’re not finger-pointing. But Southwest’s product and tech teams had to know the decades-old software systems they were ignoring could eventually cause big problems.

If they had implemented a few proven product management strategies for managing technical debt, like the ones below, they might have had a better chance of realizing the magnitude of the threat before it became a top news story across the United States.

1. Make technical debt an explicit part of your roadmap.

Building and sharing roadmaps are exciting experiences for product teams. Everyone is thinking about new markets, new users, and new problems to solve. Who wants to ruin the fun by talking about committing some of the roadmap’s precious real estate to make sure all the existing tools and functionality are still running smoothly?

But this is a vital part of the product management role. If you want your products and your company to remain successful over the long term, you need to give the less-sexy initiatives like addressing technical debt a recurring role on your roadmaps.

The good news is that when you persuade your organization that it’s in everyone’s long-term interests to commit resources regularly to these functions, you won’t need to fight this battle again and again with members of your cross-functional team. It will increasingly become a valuable part of your company’s culture.

2. Don’t treat internal use cases, needs, and features as second-class.

This was clearly a trap that ensnared the product and technical teams at Southwest. The customer-facing initiatives always took precedence. That’s why they were willing to commit more than a billion dollars to new cabin amenities while their internal systems were on the brink of collapse.

Yes, as a Product Manager you always want to be advocating on behalf of your customers and trying to round up as many resources as you’ll need to build valuable solutions for them. But you need to balance those objectives with ensuring your internal teams also have the resources they need to deliver value to your customers.

In Southwest’s case, that meant ensuring internal teams could automatically track flight crews and route them to the right places on time. For your company, it might mean making sure your internal applications, databases, networks, operating systems, and machines are running smoothly and empowering your colleagues to do their best work efficiently and reliably.

Put another way: It’s a good idea to think of your internal teams as user personas and your company’s internal systems and tools as products. And as we noted in the first tip above, you’ll want to give those personas and products plenty of strategic attention on your roadmaps. Serving them is just as important to your organization’s long-term health as serving your external customers and customer-facing products.

3. Use multiple prioritization approaches to cover ROI and risks.

Some prioritization frameworks can create a bias in favor of exciting new features and epics over the less glitzy but equally important work of paying your technical debt. It all depends on how you score items and what metrics you use to define success in your prioritization approach.

For example, using only the Opportunity Scoring framework to weigh competing features on your backlog means your team is scoring items’ value only in terms of how they will affect customer satisfaction and customer loyalty. That’s fine for weighing new features against each other, but it means technical debt items will never rise to the top of your priority list.

If you also weigh items using MoSCoW prioritization — which groups items by overall importance from “Must Have” to “Won’t Have Now” — you’ll find it increasingly difficult to keep a technical debt item out of the “Must Have” (or at least the “Should Have”) column for long.

So, our final recommendation is to apply several prioritization methodologies to give your team a more objective understanding of both the potential ROI and the potential risks of adding one item over another to your near-term roadmap.

Make Your Product’s Technical Debt Payments Regular and Small

The bad news: Products of any type (but especially technical products) create technical debt. You can’t release a product to the market (or run a business) without regular maintenance and updates to critical systems.

But the alternative is worse. Yes, taking out the garbage at home every day or two is an inconvenience. But if you don’t take it out for a month, your home will stink and you won’t be able to walk through a room without stepping in filth.

Yes, it’s frustrating having to devote precious dev resources to fixing or updating a part of your product you built already. But that work will prove invaluable by keeping your products functioning smoothly and reliably, keeping your customers happy, and keeping your company from a fiasco like the one Southwest experienced.