Last October news spread that Skyscanner bought Distinction. Since then, the change-over has been completed and the one-time Distinction is now 100% in charge of Skykescanner’s mobile application development. It’s flagship is the Flights app. In connection to the “Travel is mobile” concept, one of the main goals is to provide complete coverage of the travel experience and to present a unified solution for it. I spoke to Laci Kardos, one of the product managers of the Skyscanner Apps Tribe, asking him about the goals, challenges, strategies as well as about what kind methods they develop with and how.
Tomi: What does the current company structure look like?
Laci Kardos: The present organizational model is similar to Spotify’s. There are tribes, within that squads, and running through those are chapters and guilds. We, the Budapest team and numerous colleagues from the company, who all worked with mobile apps in the past form the Apps Tribe. The product manager is Bálint Orosz, and Ákos Kapui leads the technological department. The “flagship” of Apps Tribe is Flights, this is the primary product. One element of the long-term company strategy is to cover the complete Travel world, so as not to split into “Hotels”, “Flights” or “Car Hire” apps, but to offer a global travel solution: not just the booking, but all the airport stuff, then the flight itself, after that the stay… we want to make this whole thing very simple (finger snap).
Where do you think you’ll be in 1 year? In 3 years? 5 years?
The goal is to establish ourselves as a significant, strong travel brand with the numbers to back it up. The company is growing quickly, and we are relishing in it. From the Distinction period we brought with us an intense delivery-orientated spirit. We enjoy “delivering”, pushing forward and driving ahead, this way great things can be born. Besides this, it is essential to deliver a good product in an appropriate way. This is where our strength in product discovery comes into focus.
How do you measure the success of a product?
This is the kind of question I cannot answer with a clear, tried-out method, seeing as we have not launched an app since the acquisition. In any case, one of our most important metrics are the “conversion” types, nowadays you can buy app store ratings to attract new customers… With Flights for example, what percentage of people go from our site to the external service provider (e.g. to the page of the airline booking sites), and how many actually buy tickets.
Primarily the most developed expenditures or A/B tests try to improve these ratios. From the aspect of viability it’s obviously essential to have high conversion, but what is becoming more important is how to increase the “frequency of use”, that is continuous return.
As traveling is not just about the person booking everything, and never dealing with it again, never thinking about where he/she will travel to. It’s more a case of playing around with the idea, checking out the blogs. Then booking the plane ticket, then the accommodation. Afterwards looking into some sort of map services. Planning with local transportation, how to reach the accommodation from the airport. Then he/she starts thinking about what is worthwhile to see in the given city. These depths are not yet available in our product. For this reason we will be paying more attention to these factors. This way we force ourselves to come up with products people will use often.
So the goal is for people to use the app prior to traveling as much as possible?
That’s right. Or whilst traveling. If you think about it, even packing your suitcase is a “pain-in-the-neck”. Afterwards you fly off and get your phone out to search for places, sights. Mobile phones are fundamentally linked to the experience of travel. And this is a huge opportunity for Skyscanner. One of our strengths is our advanced technological background, and that we depict travel offers with full transparency. We show all the prices, whether it’s the price of the agency or that of the service provider. Ticket bookings are shifting more and more in the direction of mobile platforms. And travel in essence is mobile. You travel with a mobile, take pictures with it, afterwards you share it and have others view it also via mobile.
And it’s due to this strategic shift that Distinction came into the picture?
Yes. In the strategy, we have formulated this as mobile-first or “Travel is mobile.” Our other motto is “Travel is social.” You travel with someone, to someone, from someone or you get inspired by someone’s idea.
The fact that there hasn’t been a release means that you haven’t done any tests yet?
In our current apps we obviously have numerous analytical libraries where we measure these things. But we, as a team have not done major tests, as the product has not reached that stage yet. The products/features which we are building will essentially be going out via A/B tests, so first off only X percent of users will receive it. We compare the old and the new.
Besides this we have the Hotels app. Its development is also done in the same way. Actually we were the ones who originally developed Hotels, during the Distinction period.
What does the team look like?
Basically there are “cross-functional product squads” and “technological squads”. In the former there’s a product manager/owner, a researcher and a designer – in my team for example, there are two – a tech lead, developers and testers. These are middle-sized teams, so they’re roughly made up of 8 people, which will probably be split into smaller units as we grow. And then there are the technological squads. Those are mainly comprised of developers. Of course there’s a squad-lead there as well.
What does the researcher do in the team?
The task of our researcher is basically to gather insight from the world and to provide it to our product team in the appropriate form. This of course includes both quantitative and qualitative research as well. So the researcher position is interpreted quite flexibly. Tasks include UX research (usability tests, interviews, etc) and data analysis as well.
What does this process look like with you?
The product development process heavily relies on research. This means that from the very beginning stages, when we have no kind of development or design, we start to deal with things which are derived from insights. E.g. we find out that there is a need for something from earlier interviews. It’s based on these kinds of things that we start to work on solutions, designs, and prototypes. Afterwards we validate these. Typically we can test these out with various users in our office. Often these are codeless prototypes. We measure these from different viewpoints.
The most important question is would the product or function be useful for the user?
Countless times we find out that it’s not, so we remove these functions from the prototype or we try to rework them. As we do so, we continuously examine the design utility as well. Eventually when we get to the stage where we can say the product/feature is valuable, user-friendly and achievable, the decision is made on what to develop. It’s only after this that development takes place, and after that comes the release. Every product has a purpose. We can measure whether we have achieved our goal during release through quantitative measurements. This is done based on the actual user product-usage. We work on the product based on the results derived from these measurements.
How can we picture codeless tests?
Just imagine a simple wireframe-featured prototype. We create screens and we link these together. It’s very important for the rhythm of the tests to provide a base rhythm to the entire product development. If we meet a user, we want to show them something. We give them a prototype, and the researcher’s job is to do the test. It’s in the basic interest of the team to be at as many testings each week as possible.
Since it’s not just important for the designer, the product manager or the researcher to see whether what they have created works, whether it’s valuable, usable, but it’s also crucial for the developer too. These are generally 30 minute tests. Sometimes they are built upon scenarios. For example „Imagine that you want to travel and you start to use the app you have downloaded” – on iOS, Android, a tablet or on a mobile.
During the user test we can see where the process halts – during this we speak to the tester to understand the „why’s”. Then we speak to the team and go through what we have learned, what we heard. As before this, we had certain presumptions, and following the test these are either verified or not. It’s at times like these when we see what doesn’t work, what works really well and sometimes we even see things we did not expect. In my experience the value and utility of a product can be judged after 3-4 tests.
Is there anything else you’re working on nowadays?
We are working on building an Analytics system which is suitable for long-term usage, where each user interaction is logged in a big data store, which we can analyze afterwards, even with deep statistical methods (establishing correlations, etc…).
We can also use this for techniques needed for making product decisions:
Eg. examine a funnel, analyze a cohort, etc. We want to expand upon this with an A/B test (feature-switching) solution, with which we can quickly measure variance performance.
Moreover, we would like this to build upon the first big release so we can use it. Luckily this is not just our task within the company, but other squads are working together with us on this in Edinburgh, Barcelona and other places too, so we can build on these.
How does it feel to be a part of such a big company from one second to the next?
An integration has many aspects: cultural and organizational as well. This is the process which is taking place right now. The mother company is really amazing, we learn a great deal from them and they also want to learn from us. For example, what’s the Distinction culture like, what it’s like and how to integrate new elements, which work really well with us. And for us it helps that they are larger in size, considering their infrastructure and processes.