One thing is clear: there’s an urgent need to adapt in order to stay relevant in the tech industry and differentiate yourself among similar candidates.

The rapidly expanding capabilities of AI are prompting a fundamental rethink of the skills and expertise required to thrive. In this evolving world, the conventional wisdom of deep specialization may be giving way to a new imperative: cultivating a broader, more interconnected skillset. It’s no longer just about mastering your craft; it’s about understanding the crafts of those around you and how AI can bridge those divides.

As AI tools become increasingly sophisticated, they are effectively lowering the barrier to entry for certain tasks within specific domains. This doesn’t signal the demise of these roles, but rather an evolution. Consider software development. While AI can now generate significant amounts of code, the need for human developers to architect complex systems, debug nuanced issues, and ensure security remains paramount. However, the nature of their work is shifting. They are now augmented by AI, freeing them from repetitive coding tasks and allowing them to focus on higher-level design and problem-solving.

This augmentation necessitates a broader understanding. Developers who also possess a solid grasp of user experience (UX) principles will be invaluable. In a world where AI can quickly produce functional code, the true differentiator lies in creating software that is not only efficient but also intuitive and user-friendly. Understanding user flows, information architecture, and usability testing — traditionally the domain of designers — will allow developers to contribute more holistically to the product development lifecycle. As Satya Nadella, CEO of Microsoft, aptly stated, “AI won’t replace programmers, but it will become an essential tool in their arsenal. It’s about empowering humans to do more, not do less.”

Similarly, product managers are finding their roles expanding. No longer can they solely rely on market research, user stories, and traditional product requirement documents. The rise of AI necessitates a fundamental understanding of the underlying technologies. Product managers need to be conversant in AI concepts, able to contribute to discussions around evaluation metrics for AI models, and understand the implications of different Large Language Model training methodologies. This doesn’t mean they need to become machine learning engineers, but a foundational literacy in AI will enable them to make more informed strategic decisions and effectively guide AI-powered product development. As the 2025 DataCamp’s State of Data & AI Literacy Report highlights, organizations fostering AI literacy are already noticing faster and improved decision-making. This is exemplified by companies like Shopify, which has reportedly begun to measure employee performance based on their ‘Effective use of AI in their role.’

The impact is equally profound for designers and UX writers. Their focus is shifting towards crafting user experiences within AI-powered conversations. Designing intuitive and natural interactions with chatbots, virtual assistants, and other AI interfaces requires a new set of skills. They need to understand the nuances of natural language processing, including the critical skill of writing effective prompts, anticipate user needs in conversational contexts, and design for error handling and feedback loops that are unique to AI interactions. This demands a move beyond traditional visual design and information architecture to encompass the flow and logic of AI-driven dialogues.

One of the most exciting prospects of this AI-augmented world is the blurring of traditional craft boundaries. Product managers and developers, empowered by rapid prototyping tools often fueled by AI, can now quickly visualize and test ideas. This accelerates the innovation cycle and fosters a more collaborative environment. Machine Learning Specialists, whose work in training LLMs directly impacts the user experience, need to develop a deeper appreciation for UX principles. The quality and biases embedded in their models will directly shape how users interact with AI-powered products. Understanding user-centered design can lead to the development of more ethical, inclusive, and ultimately more successful AI applications.

This shift emphasizes the growing importance of a ‘T-shaped’ or ‘comb-shaped’ skill set — possessing deep expertise in one area coupled with a broader understanding of related domains — is becoming crucial.

The ability to collaborate effectively across disciplines, to speak the language of different crafts, and to leverage AI as a common tool will be the hallmark of successful tech professionals in the years to come. Generalized professional skills like critical thinking and problem-solving, alongside human skills like communication and collaboration, are gaining increasing importance in the age of AI.

The era of hyper-specialization is not over, but it is being complemented by the growing need for breadth. In the dynamic landscape shaped by AI, those who cultivate a diverse skill set, who are willing to step outside their traditional silos, and who embrace the potential of AI as a collaborative partner will be best positioned to not just survive, but thrive. The future of the tech industry belongs to the versatile, the curious, and the interconnected.

The AI-Augmented Tech Landscape: Why Going Wide is the New Going Deep was originally published in Product Leap on Medium, where people are continuing the conversation by highlighting and responding to this story.

Generative AI’s explosive debut in 2023 sent shockwaves through industries, accelerating innovation at an unprecedented pace. From revolutionizing content creation to transforming customer service and accelerating drug discovery, its impact is undeniable. But perhaps one of the most profound disruptions is reshaping the very foundations of product development.

Traditionally, product development within large corporations has been a structured, often hierarchical endeavor. These organizations have built complex teams, established elaborate processes, and relied heavily on specialized expertise. However, a new wave of innovative companies is challenging this established model. Companies like Perplexity and Nvidia are advocating for a “slim product structure,” prioritizing adaptable, self-driven individual contributors over large, specialized teams. This approach champions rapid self-learning, significantly reduced management layers, and a laser focus on problem-solving agility. At the same time, we’re witnessing the rise of increasingly powerful “one-person companies” — solo entrepreneurs and small teams leveraging Generative AI tools to build, launch, and grow their market share with remarkable efficiency. A impressive recent example I’ve encountered is Base 44, a one-person company that rapidly built, launched, and surpassed 100,000 users within weeks.

“The Future is Flat”: A New Paradigm

Proponents of the “slim org” approach highlight significant benefits: faster iteration cycles, accelerated innovation, and enhanced responsiveness to rapidly evolving technologies. Aravind Srinivas, CEO of Perplexity AI, emphasizes the importance of empowering individual contributors and fostering a culture of rapid experimentation. Similarly, Jensen Huang, CEO of Nvidia, has spoken about the need for organizations to be “flat and fast” to thrive in the age of AI.

However, while this model has proven effective in startups and scale-ups, can it succeed in large enterprises?

A Personal Perspective: Navigating Diverse Organizational Landscapes

Having worked across small startups, medium-sized companies, and large corporations, I’ve experienced firsthand the trade-offs between agility and structure.

Flat, startup-like organizations enable speed, ownership, and rapid decision-making. However, they can struggle with resource constraints, stability, and deep specialization. At some point these companies realize that they need to move to a more organized structure and that transition is often painful.

Conversely, corporate structures provide stability, vast resources, and domain expertise — advantages that have long allowed them to dominate industries. Yet, these same strengths can morph into weaknesses, breeding bureaucracy, slow decision-making, and a resistance to change. Large organizations often find themselves vulnerable to disruptive innovators who move faster and operate with greater flexibility. Moreover, internal politics, power struggles, and conflicting priorities can stifle innovation and even derail promising initiatives.

The Corporate Challenge: Adapting to the AI Revolution

Julie Zhuo’s insightful article, “The Death of Product Development,” raises critical questions about the need for change in how we approach product development. The “slim org” approach, exemplified by companies like Perplexity and Nvidia, demonstrates remarkable effectiveness in startups and scale-ups. While sounding like an attractive model, it is not likely going to prove successful as is in a corporate.

Large organizations face unique and complex challenges:

• Code legacy: Dealing with existing systems and infrastructure that can hinder rapid change.
• Strict compliance and regulations: With great power comes responsibility, or in this case — accountability.
• Convoluted approval processes: Overcoming bureaucratic hurdles that slow down development.
• Multiple stakeholders: Navigating multiple priorities and decision makers
• Relentless pressure for short-term gains: Balancing innovation with the need to meet quarterly targets.

A purely bottom-up, expertise-agnostic approach could prove unsustainable in such an environment.

The Balance of Scalable Agility

However, large corporations cannot afford to cling to their traditional, slow-moving structures. The transformative power of Generative AI demands a new paradigm. The key is to find “scalable agility”:

• Elevating the Individual Contributor Path: Prioritize the growth and recognition of Individual Contributors (ICs) by establishing comprehensive craft frameworks. These frameworks should clearly outline pathways for expanding scope, increasing impact, and achieving career advancement without necessitating a move into management.
• Embedding Innovation in Company Objectives: To truly foster innovation, explicitly integrate innovation-driven objectives into company-wide goals. Ensure that formal recognition programs and incentives directly reward initiatives that push boundaries and leverage emerging technologies like Generative AI.
• Strategic Foresight Through Deep Expertise: Capitalize on your organization’s deep knowledge base and well-established processes to proactively anticipate future trends. Develop a robust framework for rapidly assessing and prioritizing new opportunities and potential threats, while maintaining a long-term strategic outlook.
• Agile Governance and Risk Management: Empower your legal, security, and compliance teams to develop a risk-tiered assessment framework for evaluating new technologies and opportunities. Encourage a “golden rule” approach whenever possible to streamline approvals and accelerate responsible adoption.
• Tooling and Skills: Quickly open access to productively tools that enable more efficient development, prototyping and content generation, and train your workforce in using these tools effectively.

Final Thoughts: Thriving in the Age of AI

Generative AI is not just another technological leap — it’s a paradigm shift. Companies that successfully strike a balance between agility and stability will lead the next era of innovation. Those that fail to adapt risk irrelevance. The future of product development belongs to organizations that can both leap forward with innovation and maintain the expertise necessary to thrive in an evolving landscape.

Are Corporates lagging behind the Generative AI Product Development Leap? was originally published in Product Leap on Medium, where people are continuing the conversation by highlighting and responding to this story.

Conversational AI is transforming the tech industry, offering new ways to interact with products. At Booking.com, I had the opportunity to be part of our first steps with Generative AI. In April 2023, working with a team of highly skilled and talented individuals, we developed and launched our first AI chat assistant within 8 weeks, designed to help customers plan their trips.

Over a year has passed since then, and with the rapid advancements in technology and shifts in the industry, now seems like a good time to reflect on the lessons learned. Working with an AI chat assistant, I’ve developed a deep appreciation for this exciting technology and believe it has the potential to completely transform how we interact with products.

In this article, I reflect on our journey and share some of the lessons we learned.

What is the AI Trip Planner?

To start, let me introduce the AI Trip Planner. Booking.com is an online travel agency that offers a wide range of travel products, from accommodation and transportation to attractions. The AI Trip Planner is a chat interface that allows customers to start their trip exploration journey from the broadest point — seeking inspiration for places to visit — to specific queries like finding accommodation that suits their unique needs. Within the product, customers can share their travel wishes and receive recommendations for places to visit, things to do, and suggested itineraries. Recently, we’ve also started sharing relevant flight offers, and we plan to integrate our taxi, public transport, and car rental options in the future.

How to Train Your Dragon (LLM)

In the early days of working with Generative AI and large language models (LLMs), it felt a bit like training a mighty dragon. The technology was unpredictable — complex and mysterious, almost like a mythical creature. Working on the AI Trip Planner reminded me of my son’s favorite TV show, How to Train Your Dragon. In the show, the main character, Hiccup, learns to train dragons by understanding their unique behaviors, strengths, and weaknesses, ultimately building a trusting, symbiotic relationship.

Similarly, training an LLM involves fine-tuning the model to understand language patterns, contextual nuances, and user needs, creating a “bond” between the model and its users. Both processes require patience, ongoing adjustments, and a deep understanding of underlying complexities to achieve a harmonious interaction — whether between human and dragon or user and AI.

Much like Hiccup, we initially proceeded cautiously, putting in place many rules. This led to our first version of the AI Trip Planner feeling more like a traditional chat assistant that is built on top of a decision tree, rather than a natural flowing conversation. But we soon realized two important lessons:

1. UX skills are essential: While our machine learning scientists (MLSs) were highly skilled in working with AI, they didn’t hold the relevant knowledge in creating intentional user experiences. At the same time, as good as our UX writers were, they did not have the necessary knowledge required to work with an LLM. The solution was working together. In the early days of building the AI Trip Planner, this was done within a meeting where UX, Product and MLS set together, changing things and testing on the local machine of the MLS. Later on we’ve built tools to help streamline this process and make it scalable.
2. It’s a fine line between predictability and determinism: To minimize hallucinations, we initially added more restrictions and examples to guide the conversation. While this made interactions more predictable and accurate, it also made them repetitive and, frankly, a bit boring. You have to have some faith in the LLM. A good practice is to run the same queries on generic LLMs such as ChatGPT or Gemini and see what experience you receive. If the result in your product is worse, iterate until you get it right.

Thankfully, we ran internal tests with almost 200 testers before launching the AI Trip Planner. This allowed us to refine the model and ensure the version that reached our customers offered a more natural, engaging conversation.

Launching within 8 weeks

When we started developing the AI Trip Planner, very few companies had a similar live product. The technology was still in its infancy, and although OpenAI has since improved its B2B support, at that time they were overwhelmed with inquiries and were essentially unresponsive. This meant that we had to navigate this journey on our own.

But not only did we make it — we did it in 8 weeks, which was unprecedented for a product of this scale at Booking.com. I remember the immense pride we felt and the euphoria that enveloped everyone involved. However, there was no time to rest post-launch; it marked just the beginning of an incredible journey.

How did we manage it? Several key factors contributed to our success, from the people to the technology involved.

Lessons still learned

While I feel much more confident in this space now, I wouldn’t say I’ve “cracked the code” for the perfect Conversational AI product. But I’d like to share what I’ve learned along the way, both from our successes and the challenges we faced.

1: Investing in AI early on

Booking.com has been investing in AI for over 20 years, with machine learning (ML) models already powering many of our live features. This foundation gave us a head start, letting us build on a solid infrastructure and leverage a workforce well-versed in AI. Being able to combine Generative AI with our own ML capabilities played a big role in helping us launch a robust product in such a short timeframe.

2: The right people with a shared mission

When it came to assembling a team for this project, our leadership made the bold decision not to assign an existing team, but instead to pull in top talent from different departments to form a temporary “Tiger team.” That meant that we had 8 weeks to learn to work together, as well as launch a new product in an area that was new to all of us. This new team was given full autonomy, priority access to resources, and a clear mandate: deliver the product in 8 weeks and do it well.

For me personally it felt at the time like orchestrating a symphony, with many different talented players, all needing to come together in harmony. However, reaching that harmony took deliberate effort. Every member brought their unique expertise and ideas, and it was up to us to make sure all of it came together smoothly.

The Tiger Team

Our Tiger team was divided into two workstreams: one focused on creating the front-end experience, the other on building the complex “engine” that powered it.

• The “Experience” Team: This team, which included UX writers, designers and researchers, a product marketer, front- and back-end developers, and myself as Product Manager, focused on defining the user experience and the front-end logic for the product.
• The “Engine” Team: Comprising MLSs, back-end developers, data scientists, and other experts with years of experience in AI, this team built the model and data science components that made the AI Trip Planner work.

We also had a Legal and Compliance team to ensure the product aligned with Booking.com’s values around responsible AI. Leadership gave us a surprising level of freedom to innovate, though they were definitely sitting at the edge of their seat, hoping this ambitious bet would pay off.

The key factors that helped pulling this all together were:

• Defining a clear, unified objective — We aligned early on a single goal: to build a product that would both be helpful to customers and teach us something along the way. Anything that didn’t help, or that wasn’t necessary to achieve that was out of scope for the minimum viable product (MVP) version of the AI Trip Planner.
• Building trust among the product leads — working together with my talented colleagues — Hadas Harush that managed the ‘Engine’ side, and Diana Almeida that made sure we applied ‘Responsible AI’ every step of the way, we’ve established mutual trust early on and worked to keep it strong throughout, as well as beyond the launch.
• Frequent check-ins — Beyond daily standups, we used a shared Slack channel for ongoing updates and met with leadership twice weekly. This ensured everyone is always up-to-speed and gave us a steady flow of feedback, allowing us to adjust quickly.
• Small, testable milestones — With an 8-week timeline, every week needed to count. We set small but meaningful goals each week and tested rigorously, keeping us on track and ensuring our leadership team was in the loop.
• Eliminating noise for the “builders” — We kept distractions at a minimum for the engineers and designers. Feedback filtered through Product Managers first, allowing us to prioritize what really needed attention and keeping the development environment as focused as possible.

3: Happy Pathways — a way to plan intentional user flows

One of the challenges we encountered was that, as tech people, we’re often wired to think in rigid “if-this-then-that” structures when it comes to training machines, which aren’t always ideal for conversational AI design. To avoid falling into this trap, I developed a framework I called “Happy Pathways.” Inspired by how Neural pathways work, the core idea behind this concept is that our customers will be able to travel through specific pathways, given certain conditions are met, but will also be able to transition between pathways when relevant. In practice what it means is that I share with my UX and ML teams a visualization that maps out ideal user flows, guiding our UX and MLS teams to craft smoother, more intuitive experiences. These pathways highlight objectives at each interaction, allowing us to iterate on specific segments and refine the user journey step by step. It doesn’t mean we always get it right the first time, but it sets us on a defined path we can optimize individually over time, while maintaining the natural flowing conversation feeling.

4: The target keeps moving, and you need to move with it

In a fast-evolving field like Conversational AI, keeping up with constant change is a given. Since launching, we’ve updated our LLM model several times, adapting not only to the new capabilities. Rapid change also comes from the user side, with new behavior patterns emerging as users get used to this technology. Initially, most customers used the AI Trip Planner like a search box, entering short, specific queries. But as we rolled out educational user experiences, users began providing broader, more conversational prompts, which matched our initial vision for the product. For a product like this, it’s crucial to revisit assumptions frequently and ensure that both technology and user expectations align.

5: Returning to basics

While our team often leans toward solving novel challenges, some of the best solutions still come from traditional UI principles. One example is the suggestion bubbles we added — these are simple UI elements that display prompt ideas to help guide users in interacting with the AI. This small addition worked similarly to placeholders in traditional search boxes and in the AI Trip Planner it led to a significant increase in engagement. It was a reminder that even in cutting-edge projects, tried-and-true UX practices can still work wonders.

What is the Way Forward?

I started by comparing working with this technology to training a dragon. If we continue with this analogy, we might wonder: are dragons here to take over? Or, in other words, is Conversational AI here to replace traditional UI?

Especially with the multimodal capabilities of Conversational AI — where entire user experiences might happen via voice or video interactions — one might wonder where conversational ends and traditional UI begins. Since applied experience with this technology is still in its early stages, it’s hard to answer this question. But I wanted to explore it through analogical reasoning, a critical thinking method that uses past examples to analyze current topics. For this, the evolution of touchscreens came to mind.

Touchscreens vs. Conversational AI

Both touchscreens and AI technologies were introduced in practical applications long before they entered industry leading, mainstream applications:

• Touchscreens: The first practical application of touchscreens dates back to the early 1970s, primarily for industrial and scientific purposes. They were later introduced to point-of-sales devices commonly used in kiosks in the early 1980s. However, touchscreens became a groundbreaking technology only when they were introduced on mobile devices.
• Generative AI: Similarly, the first practical application of AI goes back to the 1960s, with numerous applications. Natural Language Processing (NLP) was used around the same time for tasks such as translations and simulating natural conversations. However, the groundbreaking usage of NLP and AI was through Generative AI, with the introduction of ChatGPT, followed by other powerful models such as Gemini and LLaMA.

Touchscreens changed industries and created new ones, much like Conversational AI today. Yet as we saw with devices like the iPad and the Blackberry, technology alone doesn’t dictate success — user preferences and adoption patterns play a pivotal role.

Holding on to old ways

To expand a bit more on this, let us consider the BlackBerry. The first model was launched in 1999 and was known for the QWERTY keyboards. While others in the mobile industry gradually adopted touchscreen and eliminated keyboards, BlackBerry devices, even when implementing touchscreens, continued to be released with this keyboard until the very last model. In 2014, John Chen, back then the Executive Chairman and CEO of BlackBerry said: “We listened closely to our customers’ feedback to ensure we are delivering the technologies to power them through their day…It’s the secure device that feels familiar in their hands, with the added performance and agility they need to be competitive in today’s busy world.”

From many to a single, to none:

In 2007, the first iPhone was introduced, marking a revolutionary shift in mobile phone technology by incorporating a touchscreen and eliminating all buttons except one. This launch sparked intense debates within both the tech industry and mainstream media. I still remember the passionate public debate that was centered around whether Apple was taking too big a risk by removing essential features that users were accustomed to and whether the lack of physical buttons would hinder user experience and if the touchscreen would be a viable replacement for traditional input methods.

Samsung, Apple’s main competitor back in 2007, adopted the touchscreen technology but chose not to fully eliminate physical buttons. Instead, they continued to produce various models that combined both touchscreen and buttons, although the number of buttons was reduced from its early models.

Fast forwarding to 2024, BlackBerry has been discontinued 2 years ago and iPhone and Samsung devices have become nearly indistinguishable from each other.

So, can we safely say based on this that Conversational AI is here to replace traditional UI completely?

Let’s consider another popular touchscreen device from the same period as mobile phones — the Tablet. When Apple launched the iPad in 2010, it sparked enthusiasm and speculation that tablets would eventually replace laptops.

Despite improvements in processing power and cloud services aiding memory conservation, user preferences ultimately determined the outcome. As a tech person, you likely still use a laptop, keyboard, and mouse/pad rather than a tablet operated solely via a touchscreen.

Considering both examples, it seems we are not yet at a point where we can definitively answer the question of Conversational AI vs. traditional UI. It could be that a brave single player will shift the entire industry, or it could be that users will dictate the way, or both.

Personally, and at least for now, I view Conversational AI as a complement to traditional UI, while I continue keeping an eye on emerging technologies and user behavior trends that might shift this paradigm and force me to reconsider this point of view.

Closing words

Whether you are just starting to create your own conversational experiences or are deeply involved in optimizing your existing AI chat product, I hope this article has helped alleviate some of the uncertainties and challenges you may face, if not validate your current ways of working. I firmly believe that sharing our knowledge accelerates our collective improvement and advancement. I look forward to learning from others who have encountered and perhaps even solved similar challenges, and I invite you to share your comments and thoughts.

8 Weeks to Innovation: Lessons from Building Booking.com’s AI Trip Planner was originally published in Booking Product on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this article, we share highlights and learnings from our journey of modernizing the codebase and design of the Booking.com app. The article focuses on the mechanics of getting such a program off the ground, keeping it running, and proving impact.

Around 2 years ago, we began talking about how might we help other teams to more easily launch features and innovate, while providing our customers with the best possible app experience.

At that point in time, the app was built over a +10-year-old codebase, with patches of multiple coding languages, the UI and business logic layers closely coupled and many existing unnecessary dependencies between different components and libraries. Introducing even the smallest change might mean months of work involving multiple teams, with these changes usually leading to bugs. This, of course, led to a higher than reasonable time-to-market and a less than optimal customer experience.

On the design side, we had an outdated, off-brand, inconsistent experience. Previous attempts to change or fix those usually failed because of the tech complexities and because no one was really sure where to start from given the scope of the problem.

To top it all off, using old technologies meant it was harder to recruit talent, which at the time was already challenging overall in the tech industry. It was clear that something needed to be done — and the sooner, the better.

In 2021, we began to modernize the app, primarily focusing on making it easier to ship features faster, making our app more stable and giving our customers a reliable, modern, on-brand, consistent experience.

So, where do you start when having to modernize an app of such caliber?

Before we dive in, it’s important to note that we believe modernization shouldn’t be a one-off program but rather a continuous evolution backed by built-in processes across any tech organization. As technologies and design trends constantly evolve, tech organizations must have such processes in place to keep up. However, if you didn’t have those in place for over 10 years, you might just need a centralized effort to help you get there…

To tell the story we’ll take you through 5 major challenges we faced, how we solved them and what were the key learnings we gathered in each.

Challenge #1: Defining what modernization work will be included in the program

The Booking.com app is massive, with hundreds of screens and dozens of funnels and sub-funnels, each composed of hundreds of thousands of lines of code, and this is just the client side. In addition, there was much to consider when assessing what to focus our efforts on — from backend refactoring, through modularizing libraries, to client-side code and design refactoring. We spent a full quarter learning, testing out different approaches, and gathering insights. It was clear that to try and do it all at once would be highly difficult to manage and would take way too long. We had to zoom in on a smaller but impactful scope.

How we solved it

Defining the key problems we want to solve

To help us determine what to choose, we went back to our motivation for launching the program to begin with:

• The longer than reasonable time to market and bad development experience
• The fact that our app was prone to bugs, ones that were difficult to troubleshoot and fix
• Our customers were receiving an inconsistent, outdated, and off-brand design

Considering the above, we chose to focus our efforts on two main pillars:

• Refactoring the client-side codebase by separating the business logic from the UI layer and moving to modern, standard frameworks
• Refactoring the design by implementing the design foundation and making small UI adjustments aimed to reach a more consistent information architecture and a modern look and feel

Understanding the scale of expected work

With the scope of our app modernization program at hand, it was time to figure out the effort and to try and estimate timelines. To better understand that, we went through a tedious exercise of mapping out the entire app, as you can see in the following illustration. Once we did that, we had a good sense of the amount of work that was expected — and it was massive!

Starting from a smaller, but impactful scope

We mentioned earlier that we spent a full quarter learning. The way we did this was through a small pilot that we ran for one quarter, testing out different working models and getting a sense of timelines and possible bottlenecks. By the end of that quarter, we had an implementation strategy and processes we believed would solve all identified bottlenecks. However, the strategy and processes were still hypotheses — they were created based on a very small sample of work. Given the expected disruption to the business and the large amount of resources and time that would invested, we decided to test our hypotheses before launching the program across the entire organization.

We focused on one strategic funnel — the Accommodation look to book (L2B) funnel — which takes our customers from browsing through our accommodation inventory to booking their desired property. This area was small enough to begin our work on and offered a potential big impact given its financial importance to the business.

We later learned that opting not to start with the entire app was the right decision, as it gave us time to expand our knowledge, optimize our processes, and, most importantly, gradually spread the word about app modernization while gaining the trust of our leaders and colleagues.

By the time we were ready to scale up to the entire app, we had around 45% of the Accommodation L2B funnel modernized, and we received positive feedback about the program from our peers and leadership. This made onboarding the rest of the organization to the program much easier as we proved app modernization could be done, we showed that we knew how to do it, and we had put in place enough validated processes, tools and documentation to make this type of work as systematic, seamless and frictionless as possible.

— · Our key learnings · —

💡Dedicating time for learning has set us for success

Dedicating a full quarter for learning wasn’t an easy decision, as it meant a delay of 3 months before launching the program. We chose this path because we started from a very ambiguous place, and we didn’t want to figure out critical aspects of the program while working with the entire org and possibly losing its trust if things went wrong or took too long. We relied heavily on collaboration throughout the program, and so trust was a big deal. By dedicating time to learn before officially launching the program, we got results faster and did things more efficiently once we actually launched the program.

💡Proper time estimates are difficult to make before work has begun

This program was one of a kind. We didn’t have anything to draw knowledge from internally or externally, so estimating the time it would take to modernize the entire app, or even one funnel within it, was initially way off. We estimated we could modernize 80% of the Accommodation L2B funnel in just under 6 months, and believed we could modernize the entire app within 1 year. In reality, after 6 months, we were at 45% of the Accommodation L2B funnel modernized, and as for the entire app, our current estimates are at 2.5 years in total. We learned that you can’t really know in advance how much time such a program will take, so it’s wise to make stakeholders aware that estimates are tentative and would become clearer and more foreseeable after more substantial work starts.

💡Providing detailed and specific guidelines

Initially, we went fairly broad in our documentation when it came to what it means for an area to be fully modernized. This led to gaps between what teams assumed was work done and what we expected. Once we’ve provided more specific guidelines for what is the bare minimum required when moving to the new, standard framework, it made things easier as teams knew how to better plan their work, and we could be more confident the work that needed to be done actually is.

Challenge #2: A Massive, Complex Organizational Structure

The Booking.com tech organization is as big as it is complex. Under Booking.com’s multiple business units, there are several dozens of teams, each focused on a different strategy, all pushing towards helping our customers experience the world. This leads to a very complex ownership model where 10 or more different teams sitting under different business units could own different parts within a single screen. This meant that when figuring out our modernization strategy, we had to answer the following questions:

• How do we ensure every part of the app has a team accountable for modernizing it?
• How do we make sure everyone commits to modernizing their area?

How we solved it

Securing accountability

We’ve already done a quite comprehensive work around mapping the entire app down to the level of a single component. We took advantage of that and worked to identify the owner of each area. Within that process, we onboarded teams to the program and gradually secured commitments for the work needed.

Work agreements were put in place to define the responsibilities of the different app product teams alongside our own responsibilities as a workgroup that is leading the program. We mapped out the accountability using the following RACI chart:

This proved to be a very successful work model that helped us navigate the complex organization structure and the large number of stakeholders we worked with.

As the workgroup leading and facilitating the program, we committed that we will:

• Provide guidance and support wherever needed
• Make relevant educational materials available
• Handle progress tracking and reporting
• Help remove blockers and solve dependencies
• And finally, pitch in with hands-on work (wherever necessary and possible)

A communication strategy for a large scale program

To kick start the program, we broadcasted a live stream to the entire app community and ran a roadshow, where we presented the plan to key stakeholders and decision-makers across the organization.

Over the course of almost two months, we had discussions with peers and leaders across the entire tech org. This way we could both onboard everyone, get their buy-in and secure commitments for the year.

For the date-to-day stakeholder management we strategically broke down our focus areas to different funnels, relying on our previously mentioned mapping of the app:

• We opened communication channels for each funnel, allowing us to personalize our messages, which made it less likely would be ignored, as it often happens with more generic communication.
• Within each quarter, we focused on a single funnel, for which we:
   — Ran deep analyses to identify blockers, dependencies, and opportunities for either ensuring commitments are met or pushing for a larger scope, where possible
   — Initiated 1:1 meetings or personal messages with area owners to ensure app modernization is still a priority and risks are being mitigated

— · Our key learnings · —

💡Securing official commitments early on

When we kicked off the program, initially focusing on the Accommodation L2B funnel, our agreements with the teams were less formal and on a peer level. We ended up not reaching our targets. While understandable, given our assessment was way off, we did identify that it was partly because we didn’t have official commitments in place. Our peers came with their best intentions, but considering org changes, reprioritization happening within each org, and the simple fact people leave or move roles, this was not enough. As we scaled up our operation to the entire app, we learned from our mistakes and made sure we secured commitments on director/VP levels for each area of the app. Mind that this process took us the good part of two months, so make sure you take that into account when planning your roadmap.

💡A program manager is a must-have!

Adding a program manager to support us played a critical role in our ability to scale up the program to the entire app. Even with our smaller scope, working with only 16 teams, it was hard to juggle the program management aspects of our work alongside our other product management responsibilities. Just as we scaled up, Rosangela Fonseca joined us as our Technical Program Manager.

💡Succeeding together

One of Booking.com’s core values is ‘Succeed Together’, and this value couldn’t have been more accurate when it came to this program. We depended on many teams to realize our vision. To secure their continuous collaboration, we had to empathize with their own priorities and challenges, be prepared to help as much as possible, accept it when they raised risks that might prevent them from fulfilling their commitments, and give credit where credit was due. This didn’t only help us succeed but also made the work enjoyable and helped strengthen collaborations across the app tech org.

Challenge #3: Experimentation-first Culture

Booking.com is known in the industry for its experimentation-first culture. Every small change introduced on our storefronts is done through an A/B experiment. These experiments are defined with business and behavior metrics, measuring if we improved or hurt the business and/or the customer experience. When modernizing the app, the expected number of changes that would be introduced was massive and translates into hundreds of experiments. We had to make sure these were done in the most efficient way so that experiments wouldn’t become one of our major bottlenecks.

How we solved it

Determining the success criterion

When setting up an A/B experiment, you need to define the success criterion — meaning the thing on which you’ll be basing your decision. While defining our hypothesis, we realized that our success criterion shouldn’t be an observable improvement of customer engagement or conversion, but rather aiming to hold the line — ensuring neither customer experience nor the business are hurt. The following hypothesis definition will help clarify our reasoning behind this decision:

Defining an experimentation setup strategy

We knew from experience that when running an A/B experiment, you want to set it up in a way that will allow you to easily pinpoint issues, should they come up. Or in other words — there should be few changes introduced per experiment, to minimize the number of variables impacting the outcome. To get a statistically reliable metric that accounts for weekly trends, each experiment needs to run at a minimum of 14 days and might require several iterations. Considering this work needed to be done within a reasonable time, we had to devise an experiment setup strategy that could move us forward fast enough while safeguarding the business and the customer experience.

After testing out different scenarios, we ended up with a recommended approach. We knew that not every case would fit this flow and that iOS and Android might differ to some extent. However, we wanted to offer our app product teams a best-practice approach they could rely on. In the end, this approach was relevant for many of the cases we witnessed.

The main principles of this approach were — break down big chunks of changes into individual phases and use the experiment runtime to continue developing the next big chunk of work.

— · Our key learnings · —

💡Aiming for improvement isn’t always the best course of action

When introducing a change, most businesses will aim to see an improvement. However, there are other factors that are, in some cases, even more important and that will lead to bigger value to the business in the long run. In our example, if we would have gone with incremental improvements rather than holding the line, experimentation would take much longer, significantly increasing the length of the program and wasting a lot more resources and time.

💡When experimenting, it’s important to be flexible and adjust as you learn

Our suggested experiment setup strategy offered a good enough solution for most cases. However, our best results were achieved via a more personal approach — as we gained more experience with app modernization experiments, we could tailor an experimentation strategy per area to further improve our chances to succeed.

Challenge #4: Design as a major potential bottleneck

In our defined scope, an area would be considered to have a modernized design when:

• The right design foundation was in place — meaning using the Booking.com design building blocks that are part of the design systems of the company
• The design language was implemented

When we started working, we still didn’t have a design language defined. There was a rough idea of what it should look like, and we did have overarching app design standards, but we still had to translate each screen into the new, modern, unified design language. In addition, adoption of our Design Systems component was at that point low. We needed to make sure the Design Systems team and infrastructure were ready for the rapid increase in adoption.

How we solved it

Creating processes to scope the work and track progress

The workgroup designer (Initially Catalin Bridinel, and later Bruno Lopes), composed a process that would allow us to gradually take each product team from onboarding to delivery. This was crucial, as it helped us to understand the scope of work expected around design language, and provided us with the base for measuring our progress when it came to design deliverables. In the following chart you’ll find the details of this process:

Defining the new design language out of the teams’ vision

When translating our existing design to the new design language, we had two options:

1. Looking at the current state of things
2. Looking at the teams’ vision

With option number 1, all we had to do was go through the app, take snapshots of the current design and craft the new language on top of that. With option number 2, we had to take into consideration the short/medium term plans each product team had for their area and work together with them to adapt that to the new design language.

We decided to go with the second option. It made the most sense to us for two reasons — the first and most important being assuming a team dedicated to an area which they have been working on for a while now, and have been optimizing it consciously, will know what would work best for that area. The second reason was that it saved us time in the long run — if we would have ignored the teams’ plans, their design, development, and experimentation work would have been doubled, and their vision would have been delayed.

Preparing for an increased adoption rate

When we started our modernization program, the Booking.com design systems were at a fairly mature place with a competent team leading the scaling up of coverage, ongoing support, and communication. However, up until that moment, the adoption of the design systems was low-key. We weren’t sure if the tooling, processes, and documentation in place would be sufficient to deal with the expected increased adoption.

The Design Systems team (At the time led by Mauricio Zaquia) worked closely with us to optimize the team’s support processes, aligned their roadmap for growing component coverage with the app modernization program needs, and ensured relevant documentation was in place. This alignment produced a work agreement with expectations and responsibilities in place. It helped us a lot down the road as the adoption of the Booking.com design foundation grew at a rapid pace.

— · Our key learning · —

💡Establishing processes wherever possible

Building processes helped us achieve fast progress in many parts of our work and prevented major potential bottlenecks. The comprehensive process we’ve built around design was the fruit of testing and iterating, while collecting learnings, identifying patterns and turning them into reusable work flows.

Challenge #5: Measuring progress and impact on the business

There were two main questions we needed to answer:

• How can we track progress so that we can ensure we’re moving forward and can create reports that will be shared with our peers and leaders?
• How can we prove app modernization is indeed positively impacting the business, as we claimed at the start of the journey?

How we solved it

Getting into the nits and bits for proper progress tracking

Once again, our tedious work around mapping the entire app came to our aid. By breaking down the app thoroughly from funnels to components, we could track progress from the biggest to the smallest area.

Initially, we relied on Google Sheets to track progress, asking teams to update their status per component and automatically translating that into a numerical value that indicates progress. This tracking approach served us well when only working on the Accommodation L2B funnel. However, it proved harder to manage and prone to errors when we scaled our operation to the entire app. We ended up uploading the data we had on Google Sheets to a program management software where we could assign tickets to teams and automatically generate reports and alerts where needed.

Our automatic cadences included:

• Direct messages to assigned owners, alerting them about upcoming and missed deadlines
• Monthly and quarterly reports sent to different tiers of peers and managers, notifying them about upcoming commitments and progress made
• A dashboard that was updated monthly, showing the current status of the program and allowing people to filter the information by area, department, or team

Finding the most efficient and reliable way to prove business impact

You might recall we’ve mentioned earlier that most of the targets we’ve set out to achieve weren’t measurable per change introduced. It is only after enough of the app was modernized that we could look at the cumulative impact.

But why did we need to prove impact to begin with?

If you have experience in a big tech company, you know that a program or a project might be deprioritized before it has reached its completion. This is especially correct with long-term projects. When we started modernizing the app, the leadership team had our back, but we knew we had to prove impact at some point to keep the program top-of-mind and a high priority. In addition, while intuitively knowing our work was bringing a positive impact, we were curious to learn by how much. We considered these two variables to evaluate our success:

• Development velocity — how fast can our product teams develop new features and ship them to market? Time-to-market has been on our radar from the very beginning, so it made sense to measure success by looking at the change in velocity.
• Product quality — how many bugs or issues come up during or after the release of a feature? We knew these were costing us time and money, so showing an improvement there proves direct value to the company.

When trying to get actual numbers of the development time or the number of issues raised, it was an impossible task or at least one that would cost us a lot of time and resources. Our goal was to find a reliable, measurable and reusable framework that we could use to measure impact periodically, with minimum effort. This led us to a survey, where we asked our tech teams (Developers, Engineering Managers, and Product Managers) to indicate to what extent they agreed with two statements connected with our chosen success criteria.

We also made sure we knew for each responder to the survey:

• How advanced modernization is in their area — meaning, is enough codebase modernized to make a difference
• How long they’ve been in the company — meaning, do they have experience with the old codebase with which they can compare their current experience
• What is their role

The results were staggeringly positive — with only 60% of the app modernized (at the time of the first survey), 67% of respondents agreed development velocity has improved, and 70% agreed our app is more stable than before.

The survey covered our tech modernization impact. We still needed to show a positive impact on our design modernization. For the latter, we relied on our A/B experiments. We’ve mentioned before that our success criteria was — causing no harm. However, in many of our design language experiments we could see significant improvement on conversion and in customer engagement. As we kept track of all of those experiments, we could easily show the impact generated by them.

Our key learnings

💡Automating as much as possible

Initially we relied mostly on a semi-automated process, where we counted on teams to update their progress using our app mapping sheet. This worked well while we were working on a small scale. However, the moment we expanded our operation to the entire app, moving from 16 to almost 60 teams, managing this manual tracking became a nightmare. We had to chase after people, there were many mistakes in the status updates and we found ourselves spending a lot of our time just dealing with tracking error correction. We would recommend moving into a fully automated system as early as possible. For us, it was Jira, as it was a tool already widely used in the company. But really, it can be any project management software that allows you to assign tickets, track progress and generate reports.

💡When running a survey, use the help of professionals

The results we’ve shared were actually from a second iteration of our survey. Our first iteration wasn’t as insightful. Initially, we worked alone, 2 Product Managers trying to figure out how to compose the survey and what would be the best structure for it. When creating the second one, we decided to get help from our data and research internal resources. This made a huge difference. Our second survey was so insightful that it not only provided us with good visibility on the impact of modernization but, it also provided some important learnings that helped us further improve our support and program management processes.

Wrapping it up

It’s important to mention that our success in driving the app modernization program and the progress made so far wouldn’t be possible without our track leaders (during the majority span of the program) — Alexandru Litu, Thijs van As, Gustavo Contreras, Tara Nielsen and Puja Nanda, who believed in this vision from the beginning, helped push it in the organization, and always had our back. Having a company objective of strengthening our foundation also plays a major part in the ongoing success of this program. At the end of the day, most people understand the value of getting your tech and design up to date. Still, not many companies would be willing to commit to such a multi-year endeavor, and it’s great to work in a company that does just that.

As mentioned at the beginning of this article, modernization shouldn’t be considered as a one-off program. While we’re heading towards the last milestone that will take us to a 100% modernized codebase and design, our Core tech teams are already busy defining ways to ensure that we never again end up in a situation where such a massive one-off program is needed.

How we managed to modernize the Booking.com app from the inside and out was originally published in Booking Product on Medium, where people are continuing the conversation by highlighting and responding to this story.