From Airline to Super App – The Journey of AirAsia: A Case Study

Alfonso Fiore, Head of Product for packages at AirAsia, explains how teams might go about entering the super app race, by sharing how his team is in the process of doing exactly that, right now.

Overview

Since 2001, AirAsia has flown passengers to more than 150 destinations and its story is certainly one of rags to riches. Bought for 1 Malaysian ringgit (~ 0.25$) by CEO Tony Fernandes, the company, headquartered in Malaysia, has grown to become the biggest Asian airline outside China.

At AirAsia, the sky’s the limit (excuse the pun) and, in an effort to disrupt the online travel space, its aim to become a powerhouse of travel tech and join the super app race. The mission – to enable customers to buy far more than just flights. From hotels and activities to duty-free goods, travel insurance and even flights from other airlines.

Creating a super app, of course, requires mountains of relentless work from a dedicated team and, in this case study, I’ll explain how AirAsia transitioned from an airline to a technology company that just happens to fly planes.

The Approach

The journey began with a vision from our CEO, Tony Fernandes. Tony realised that with over 50 million monthly active users, AirAsia had the data and reach to grow its business in quite a phenomenal way. Consequently, three years ago, the AirAsia Group formed new partnerships and made investments to enable us to move towards Tony’s vision – a seamless, all-encompassing super app that would include hotels, insurance, activities, and so on: everything customers might need when booking a travel experience.

At the time though, AirAsia wasn’t a product company. There were plenty of incredibly talented people in aviation and operations, but not enough people with the right vision or experience to tackle the type of work needed to transform a single app to a super app. So, to drive the digital side of the business forward, the company made a number of significant hires, bringing in senior players in data, software engineering, design and product from top tech companies like Lazada, PayTm, Tokopedia, Grab, Expedia and Traveloka.

With a great team in place, the project kicked off with a long design thinking session, plus interviews with the main stakeholders to understand their point of view, expectations and requirements.

It was fascinating (but also scary!) to discover that, even after sharing an initial vision, people often had diametrically opposed views. Designers wanted the best design that ever graced the earth while engineers were imagining robots that jumped out of your screen (not quite, but imagine a lot of automation!). I really had to hold close my belief that only by building small and going live faster, would we have the best chance of success.

As many in the product space already know, during these periods of expansion your team faces a “buy vs build” moment. Often, the solution is to “rent” first, test, learn and build later. At AirAsia, the “build” stage was where I came into the picture, around six months ago. I was tasked to lead the product effort of the teams that had been, and still are, building new digital funnels to replace some of the initial products we “rented” to learn the needs of our customers.

The Building Blocks of a Super app

As an airline, we already had some of the blocks we needed to build our vision. For starters, we had flights in the bag, and with new whitelabel solutions we could add hotels from a world-leading Online Travel Agency (OTA), packages (by mixing our flights and hotels from our OTA partner), and activities such as restaurants, theme parks, attractions, spas and tours from Vidi, a startup AirAsia had previously invested in.

Choosing third-party integrations is an involved process. First and foremost we had to be sure that they would cover some of (if not all) the needs of our existing customers, in line with our product vision.

In addition, we had to ensure that these third-party products:

• Offered a mix of product/market fit, a price that allowed for a slim but sure margin, and optimised time-to-market (TTM)
• Allowed for quick and dirty integration but with a look and feel that wouldn’t be immediately different from the AirAsia style to the untrained eye

You might also like: Third-Party Software Integration:
Best Practice, Perils and Pitfalls

When I joined the AirAsia team six months ago, the time had come to internally build some of the verticals in our super app – those considered strategic to implement our vision. As such, we didn’t want these to remain whitelabels or partnerships. Among many other reasons, building these verticals internally would allow us to:

• Achieve a stronger integration of these products within our ecosystem (think, for example, of user profile integration, but also the ability to cross-sell across verticals)
• Guarantee a unified look and feel that would make users feel immediately “at home” with our various products
• Enable us to cater and optimise our various funnels for our very unique user profiles

I like to think of this process as being a little like building from a bag of Lego. In this analogy, the bag of Lego is the data from your third-party APIs.

While the front-end of your app is built by your company, behind the scenes you’re picking from the available Lego in your bag, building your product up, brick by brick. You integrate the data you have from these third parties into your core business and then, as your first users begin to uncover the chinks in your armour, you work through the feedback and refine your product.

Prepare for Trade-Offs

Something you quickly learn during this part of the process is that, most times, there will be limitations and trade-offs depending on what’s available in your bag of Lego bricks. If the data you need isn’t there, that doesn’t mean you have to abandon your vision altogether, but you might need to adjust your plan.

Here are two examples of trade-offs we had to make:

1. We wanted to offer our customers a simplified page featuring integrated hotel-level and room-level information. The APIs we had to use were designed to fetch this information with two separate calls, and so we decided a single page would be too slow and to the detriment of user experience. Instead, until we could build the necessary infrastructure to guarantee performance, we had to find a different solution with two distinct pages for hotel and room level information.

1. All of the APIs you deal with constrain your architecture. In one instance, we found that we received more items in a single API call than we wanted to display to our customers. Sometimes we received hundreds of options when we wanted to show just a few. In this case, the solution was to design a Machine Learning (ML) model to suggest the more interesting items for our customers. This was initially not in our plan, and it’s an example of an adaptation that was necessary due to the integration with external APIs.

Accept Your Imperfections

With our solutions integrated, our next move was to take a step back and to look at the big picture. This is when we began to see that, compared to an app that only sells flights and ancillary flight products (e.g. meals, seat selection, etc), our super app now supported new needs coming from our different business lines.

Our initial analysis indicated the following:

1. Our existing logic for languages and currencies were not built to serve many lines of business. This meant we needed to build an architecture that would automatically propagate changes across all verticals when, for example, we added or removed a currency.
2. We needed a separate engine to take care of purchases, one that did not explicitly require each customer to buy a flight with each and every transaction.
3. We needed a separate source of exchange rates.
4. We needed a totally new, centralised service to deliver transactional emails to all our lines of business.

The aim of the game here was to build logic that would ensure that any changes that might impact multiple lines of business (e.g. a new currency, a new language, a new taxation in a specific country, etc) could propagate to every product with a change in a single point in our codebase.

This wait and see approach might seem risky, not so scalable and perhaps even something you’d want to tweak with the benefit of hindsight. However, in my experience – having done something similar first at Agoda and then at Grab – it’s the right approach. But try to think of this problem from the opposite angle now. Imagine you’re building software for your first and only line of business: flights. It makes total sense to not separate currencies or language support to a separate service. Sure, doing so would build a good, scalable architecture, but you don’t even know yet if your company is going to be around for one month or one year. And remember: the sooner you go live, the better.

In fact, one of my favourite essays is Do things that Don’t Scale by Paul Graham. His points really ring true here – sometimes it’s the unscalable things you have to do to get going that will ultimately help you work towards where you need to be. It won’t be perfect in the beginning, the best startups rarely are, and you should never believe that your startup will run the world straight off the bat. The key is to start with the core and build out in layers.

Be Open About Optimisation

Optimisation begins as you build those layers into your product. The decision about how to present information is difficult, even in the simplest of products, and with a super app, the complexity of this optimisation increases exponentially.

Say you have seven products and your layout allows for three icons on each row. How do you present them all on your homepage? Which gets priority? The answer is that it requires a complex mix of financial analysis, customer insight and experience.

In general, our goal at AirAsia is to offer everything a customer might need at the best possible price point, in line with our motto “Now Everyone Can Fly”.  But, once you’re showcasing 6-8 products – that’s two lines of 3-4 icons on a mobile screen, the fight for prime real estate becomes very real. This requires A/B tests, ML models and innovation. Not to mention lots of very long conversations across different teams, including marketing and advertising. Should you prioritise your “sacred cow” or your most promising upstart? This is the typical type of problem statement with 10 people in the room and 20 strong opinions.

Our customers also need to be aware of all the services we offer and they need to be able to find them easily. So, when we’re already accommodating multiple products in limited space, we have to make time for discussions with the marketing team to consider how we might also make room for their campaigns. A recent example of this is where we decided to add a new visual element in our homepage titled “Important Notices”, visible ATF (above-the-fold). This came as a result of the disruption to the travel industry caused by COVID-19.

In addition, once you provide multiple services to millions of users, you have an opportunity to monetise the real estate of your app through advertising. This, again, requires careful discussion to ensure that you balance the needs of your internal teams and products with those of an external party who wants to advertise.

And of course, there are certain things that are simply straight-up unpredictable. Take Grab, for example. During the COVID crisis, it was able to quickly adapt, changing its lead product from transport to food delivery in its super app home screen.

Data and Digital Ready

Data is also an integral part of the road to the super app promised land. We have discussions with our data teams to determine the initial criteria for success whenever we have multiple items to show. More importantly, we discuss what data we will need to capture in our analytics to keep improving the model.

The key here is how quickly the model can improve and how much data it needs to train itself, rather than how good it is when we go live.

A super app lends itself very well to ML problems. Think of the famous “people who bought this, also bought that” example. Imagine if we could predict, based on a number of data points, whether you are more willing to buy an in-flight meal during your flight or a skydiving session at your destination? Or if you are more likely to choose a 5-star hotel over a hostel? With so many varied products and services, super apps are in a unique position to gather the data needed for these more complex ML models.

Constant Communication

All of this work requires regular communication with multiple teams and at AirAsia, where our teams are spread across multiple countries and time zones, communication is a challenge.

I personally interact with two business counterparts, two front-end teams, two back-end teams, a data science team, a design team, a user research team and a copywriter, with whom I work every single day. Perhaps, you’re thinking, this doesn’t sound too challenging but, look a little closer and the coordination efforts of this team become more and more complex.

Within each team, there are multiple people, all talking to each other. Sure, some teams don’t work directly with each other on a day-to-day basis, but there are so many more points of communication at any one given time than you might think.

And those complexities don’t stop there – the work we do doesn’t take place in a vacuum. Outside of our “tech bubble” (engineers, data scientists, designers, etc), AirAsia has tens of other teams to coordinate with, including the flights and the homepage team, the post-booking team, finance, customer support, refunds, info-security, legal, not to mention dev-ops, management and payments teams.

For me, the coordination effort all of this requires is huge. I personally have five or six, hour-long meetings each week just to sync with those teams (this will even increase as we get close to a big launch). They then have their own sync meetings and so on and so forth. What this means is that organisation is key, especially in an 18-year-old company which has world-class operational experience but that is relatively new to complex product launches (luckily in the last few weeks, a new colleague joined us and he is sharing the workload with me).

I did my best to find ways to create alignment across teams of people with varying levels of experience. This included:

• Sharing updates and information in a synchronised way using a cloud-based tool – I found this to be especially important; not all tools are created equal. A tool that helps create shared documents which are all disjointed is not as useful as a tool that allows you to create a structure that enables the whole organisation to search independently in a common knowledge base. You need to know which tool is best for different stages of the process
• Being strict in my documentation –  creating concise messaging and getting key points out to teams as early as possible, especially at critical times
• Talking with people in regular 121s, developing relationships and building trust to allow for open and honest conversations

Results

At this point in time, it’s fair to say that results are pretty tricky to share because of the current challenges in and around travel! However, ultimately, we can say that we’ve achieved what we’d hoped to achieve.

In 2020 we transitioned our app from one solely focused on flights – searching for flights, buying flights, checking in and managing bookings, to AirAsia 3.0 – a super app. It’s a journey, and as such, that was only step 1. There’s still much more to come.

When life goes back to normal, our customers will have the power to do everything they could before and also to book hotels, packages, activities; buy daily deals, duty-free products; use our fintech application (BigPay) and more, all at their fingertips.

Conclusion

Working on this with the AirAsia team has been a crazy and interesting ride and I couldn’t be more happy and proud of what the teams have achieved so far.

This type of work means that you’re constantly learning – you literally learn something new every day. You’re creating new funnels that didn’t previously exist, you’re managing multiple teams at a pace which, at times, gets completely nuts.

Imagine 10 different teams all working on something at once, it requires another level of organisation and the coordination that takes place never fails to blow my mind. It requires a passionate and dedicated team. Ours, as I previously explained, is big and complex and every member has (and continues to) put in an incredible amount of effort to get this project across the line.

Not only has it been fascinating to see so many people, across so many teams, working so well together, but it’s also taught me a lot about my own leadership. I had issues with some of my colleagues along the way and I made mistakes, but I sought advice from my peers and was amazed at the results I could get just by being honest, humble and in recognising my mistakes. This is something I cannot recommend highly enough.

For others who might be about to face this type of challenge, my main pieces of advice are:

1. Building a super app is an enormous endeavour. The work never ends, it’s exciting and tiring in equal measure.
2. Be ruthless about cutting back on what you need to build before you present it to your customers. Based on my experience, there’s almost always something else you can remove from your MVP.
3. Once it is ready, throw on a thick skin and prepare to be (immediately) slapped in the face by your customers. The mood has been steadily changing in Silicon Valley, but Reid Hoffman (LinkedIn co-founder) is famous for saying: “If you aren’t embarrassed by the first version of your product, you shipped too late.” This is why all feedback is valuable feedback, and negative feedback even more so. It’s only by listening to your customers and constantly iterating, that you will be able to consistently ship a product which provides value to your users and, I dare say, if all your lucky stars align, even be loved by them.

Rate this Article