How Booking.com manages hundreds of autonomous product teams at scale

Despite being one of the largest e-commerce travel companies in the world — it has more than 15,000 employees in 198 offices in 70 countries worldwide — Booking.com has managed to remain a lean and learning organization.

I’ve been fascinated by it for a while. It’s a place where decentralised and autonomous product teams can thrive, supported by a strong, data-driven culture.

In this interview we talk to Kelly van der Veen, Product Owner (Attractions) at Booking.com and Zania Barnum, UI/UX Designer (Transport)at Booking.com.

We discussed how hundreds of product teams operate across the organisation, how they use customer feedback to design scalable products and what it takes to succeed in this type of organization.

Sofia: Kelly, Zania, why don’t we start talking a little bit about what you do at Booking.com and how your product teams work together.

Kelly: I’ve been at Booking.com for over three years. I joined this specific track [Attractions] about three months ago.

At the moment Booking.com may have over 150 product teams, but as this changes almost every day it’s hard to keep up. On a higher level, we have departments. Departments could be around our core product’s customer experience, our customer service or the partner side — our accommodation partners. Within such departments we have tracks of teams that are formed around specific topics.

In our case, we work in new product development in a track focussed on attractions. Within such a track, there are multiple product teams. One thing that every department and every track has in common is that the individual teams are relatively small. Most teams have about four to eight people and they’re very autonomous.

Those teams almost always have a product owner and then, depending on what kind of problem they are focusing on, development resources like a front- and backend developer, designer and sometimes a dedicated copywriter or data scientist, or native app developers. It depends on what the team is working on.

Each team is given a topic or a problem to tackle and it’s very much up to the team how to solve it. In our case, it’s figuring out how we can sell attractions. It can also be something like how to book non-hotel accommodation or how to book for business. It’s up to the individual teams how to solve these problems. Each team decides for themselves what kind of tools will give them the best results or the most insights. We also have shared resources such as data scientists, web analysts or user researchers that we can ask for help.

Product teams work like little startups within a bigger organisation, but to make sure there’s some sort of order, we use the Objectives and Key Results framework (OKRs) to provide alignment on goals. The company has objectives and so does every team, track and department, though most input comes from the teams themselves.

Sofia: How did your team start using EnjoyHQ? What was the problem you were trying to solve?

When I joined the Attractions team, they were already using EnjoyHQ, one of the product owners in team told me, this is EnjoyHQ, this is where all the feedback comes together so I started using it right away.

The current process is that after people use our product, we request feedback and that feedback will come to EnjoyHQ. We also get feedback from both customer service and/or commercial people. This also goes into EnjoyHQ. And we have people who opt out of our emails and that feedback will go in there as well. It’s a really helpful digest of everything that would otherwise be scattered all over the place.

Within Attractions, we have people working on both the customer and the partner side of the product, with both sides looking at our EnjoyHQ feedback. If it’s something that has to do with an attraction venue, for instance, then we might tag someone from the commercial side to get them in touch with them. When it’s an angry customer then we might tag someone from Customer Service.

We use EnjoyHQ to find issues. Sometimes we find bugs even before they’re reported, which is really helpful.

Sofia: How did Booking’s culture evolve? How did the organization manage to remain so flexible and autonomous as it grew?

Kelly: From what I’ve heard, we’ve always had small teams which set their own objectives. Obviously, when you have more and more teams it gets a bit harder because there can be a bit more overlap between them but the big advantage of this way of working is that it creates a lot of ownership.

Sometimes when new people join they might think, ‘Oh, is my scope only this?’ and it might seem limited, but when you dive into it you find a world of opportunities and many challenges to solve. Also, the huge amount of traffic we have makes it extremely exciting. Even if you’re focused on a small segment, it can still be relatively big.

It’s a very experimental culture and very data-driven. As long as you have data to show that what you’re doing contributes to the business, it’s fine. The culture itself creates a safety net in that sense because if a team is not bringing in results, it’s very visible. You’re challenged to be focused.

Sofia: Before, you mentioned having over 150 product teams and that that number may change every day. Could you tell us what triggers those changes?

Kelly: There’s actually multiple ways that can happen. For example, it could be that a team works on something and then finds something they think could be more valuable and, once there’s some data to prove it, the team decides to pivot. It could also be that a team did the best they could but concluded that they would be better off doing something different. In that case either the people get distributed or they change the whole team’s focus. Every team is continuously asking, ‘Are we bringing in as much value as we can? Are we solving the most pressing issues or chasing the biggest opportunities?’.

It’s very normal for a new team to form or for a team to shift focus. There will be areas that will always require attention and are, in that respect, more stable. But there are also a lot of shifts going on all the time.

Sofia: What type of person tends to succeed in this type of culture?

Kelly: I would say people who thrive in this environment are those who take ownership. For example, we don’t expect a developer to come in and just open their Trello board or whatever backlog tool they use and just work on the descriptive stories that the product owner wrote. That’s not really how we approach things.

In most cases, we require everyone to bring in their own ideas. Everyone needs to take ownership of the product and be commercially aware. When we hire developers or designers or any type of people, we always ask them how they would prioritize their work and what they would focus on. We also want people who are very open and humble. I’ve never encountered anyone who wasn’t nice when asking questions — that’s also a very important thing.

People here are mostly very customer-focused and really want to understand what the product does for their customer, whether it’s a hotel partner, someone who used the website or an affiliate partner or whoever. One very important thing is that people should also be adaptable to change. It can be a very nice environment but there can also be some uncertainty around it and people need to be flexible to an extent in order to adapt.

Sofia: How do you as a product owner help to preserve and leverage that culture?

Kelly: A tool like EnjoyHQ helps because we can encourage everyone to go through the feedback in a very easy way. Just this morning, one of our copywriters said, ‘I’m gonna browse through EnjoyHQ a bit and try to see if I can come up with some ideas from the feedback that we’re getting’. It gives easy visibility to all that information by aggregating everything that would otherwise be scattered all over the place.

People challenge each other when it comes to ideas that have been put forward. Even new people do it. They’re encouraged to, in fact. They ask, ‘Why do you think this is a good idea? What kind of data points do you have?’. That’s the kind of culture we have.

Also, we do as much qualitative or quantitative research as possible. We encourage everyone — not only product owners — to talk to customers in the lab or even in Starbucks or wherever. We then proactively share that feedback.

Sofia: What is your advice for other product owners in large organizations that may not have the same level of empowerment but want to start introducing more customer centric behaviour?

Kelly: Maybe this is a bit optimistic, but I believe that if you have strong data points or a voice of a customer, even people at the top will listen. An idea is not worth anything if it’s not backed up, including the CEO’s! Every idea should be welcomed but it always needs to have some reasoning behind it.

I think if you want to establish such a culture, it’s very much about understanding what your customers are using your product for and what things they like or don’t like about it. You need to have a way to quantify that feedback so you don’t run after every little thing you find. To try to find out if the issue affects just one person or many. If you do that, it’s much easier to figure out where you should focus your energy.

Sofia: Zania, you work in a completely different vertical. What do you do there and how is your team using EnjoyHQ?

Zania: I’m a designer and I work on a team with about six other people — a product owner, two backend developers, two full-stack developers and a copywriter. My team works closely with another team that has the same skill-set, more or less. We’re focused on helping people arrange transportation to their stay.

During New Product Development, as you know, it’s really important to stay close to your users throughout the development process. We’ve been collecting qualitative feedback from our users in a variety of different ways. After a while, we gained so much qualitative feedback that we needed to figure out a way to aggregate it so we could quantify trends.

I talked to somebody on Kelly’s team about our issue and found out that they were using EnjoyHQ. After receiving a demo from a colleague, my team understood the value and we decided to start using EnjoyHQ.

Sofia: What type of feedback are you aggregating?

Zania: We’re aggregative user feedback from surveys, feedback loops, and emails to our customer service inbox.

Every morning we look at all the feedback that’s been put into EnjoyHQ and tag it. We’ll go through it and add themes and put them into research projects.

Every two weeks we create reports. The report identifies the top themes and tags. It also includes some highlights from these themes and tags. The report also highlights some of the feedback we received that we’ve tagged with positive or negative sentiments.

Sofia: As a designer, what is your advice for product teams who are not taking advantage of the qualitative data they already have?

Zania: Quantitative data can tell you what’s happening, but qualitative data gives you insight as to why that thing is happening. As I mentioned earlier, our team has always focused on getting qualitative feedback from our users, but we used to get overwhelmed because we have so many different touch points through which we receive feedback. Having it all in one place is really awesome because it gives us some clarity. We might be thinking that most people are concerned about ‘apples’ but when we actually quantify our feedback, it turns out that the top issue is ‘pears’.

I really love having EnjoyHQ. We use it when we do our sprint planning. We look at the aggregated feedback to understand what to tackle next — what to prioritize. It’s a part of our ideation process. We choose ideas for the sprint that we think are achievable within a certain time frame and that will make the most impact. We have a vision but, ultimately, we want customer feedback to reshape and fine tune that vision.

Going back to your question about my advice: Make sure you’re challenging your assumptions and really asking your users what they need. Identify their pain points. Listen. You need to be in touch with them, otherwise you’ll build a product that nobody wants. It might be a beautiful app that works really well but if no one wants it then who cares?

If you are interested in learning how other product teams from fast-growing companies use data make better product decisions click 👉 Here to read more success stories.