Author

• Maksim Koutun (Director of Engineering @ Flo Health)

Review by

• João Rosa (Independent Consultant and Team Topologies Valued Practitioner)

Flo Health is the world’s most popular app for female health, with 350 million downloads, 70 million active monthly users and close to 5 million paid subscribers globally. After achieving a market fit, Flo embraced the super-app strategy for growth. With high product retention and the ability to grow the user base, our period tracker was a core part of this strategy while the app’s other domains exhibited high long-term value and willingness to pay.

In 2023, Flo added more than 10 million active monthly users. With growth, one of our main challenges was building holistic user journeys across domains. Delivering user value demands orchestration across multiple teams, which brings a lot of cognitive load due to the large number of team interactions.

We rethought our approach by introducing product platforms for personalization and explicit interaction strategy. Team Topologies helped shape our journey by providing a framework for structuring teams and optimizing their interactions.

Operating context

The Flo app prioritizes safety and aims to be the most trusted digital source of information on women’s health.

It is available in 21 languages on iOS and Android. The company employs around 500 people in offices across the United States, United Kingdom, Netherlands, and Lithuania, plus several fully remote staff members.

From an organizational perspective, Flo has three main areas:

●      Value Creation emphasizes product engineering to deliver value to users. Key domains include a period and symptoms tracker, a virtual assistant, a medical content library, and a community.

●      Value Capturing centers on product growth, optimizing user onboarding, pricing and engagement experiences.

●      The Delivery Stream supports product streams to accelerate the path to production and oversees horizontal platforms such as infrastructure and data.

Challenges

All the teams inside our streams formed around strong domain ownership; they are reasonably stable and autonomous. Platforms helped scale developer efficiency and brought additional autonomy to domains. The super-app strategy forced us to add more domains inside the app for extra user value.

The growth of Flo’s audience brought us more opportunities for targeted personalization and supporting different user needs, which means more specific modes based on user goals inside the application.

For example, a user trying to conceive prefers using one set of features while users trying to track menstrual cycles would choose another set:

To address this, we created mode teams focused on personalization and smooth transitions between different app parts, based on user goals. These teams work across domains on top of our platforms, allowing them to create features and experiment with them without writing code.

This solution was great for content personalization, but was not practical when we needed to develop new features across various domains. For example, our application provides an entirely different set of functionality for pregnant users, resulting in the constant need for cross-team coordination to deliver value, which brings a lot of cognitive load.

The side effect was unpredictable delivery timelines, which affected our time-to-market metrics and required extensive upfront planning.

We overused the collaboration pattern during mode development, when the mode and domain teams worked together around cross-team use cases. Сollaboration is a great pattern, but it can’t be used by a lot of teams at the same time. Team Topologies advises that “a team should collaborate with, at most, one other team at a time.”

For example, ten teams participated in developing our Flo for Partners (Partners Mode), which allows Flo’s primary users to share their experiences with their partners and creates a safe space where people can find information about health and relationships. I will offer this use case as an example.

Since we support many modes, our delivery would be complex and unpredictable without evolving our approach. That is why we developed the next set of requirements:

●      Less dependency between teams. It is okay to have dependencies, but we must define them beforehand as blocking versus non-blocking, with a pre-agreed interaction model.

●      The same number of teams. We should be able to scale modes without additional hiring, and teams are more adaptive to business challenges if they cover more extensive domains.

●      Defined prioritization logic. Simulate how our future roadmap and business expectations will work with the setup.

But what did it mean from an organizational perspective, and what kind of enablers did we need to make it happen?

Finding the solution

Based on the requirements, it was clear that we had to decrease collaboration in favor of platforms. Moreover, this strategy had been discussed for a long time, with the mantra that we must use our platform capabilities for personalization.

Actively using back-end-driven UIs  had  already improved many platform aspects. The main benefit is that we can now deliver different UIs without mobile client updates.

For example, the Stories team is a domain with clear business metrics related to user engagement. But Stories was also a platform that provided a way to personalize content with an independent release cycle:

The same was true for chatbots, onboarding, and other channels.

Our main challenge was domain discovery inside channels, and adapting domains for the new modes. For example, we need completely different calendars, libraries, reminders, and predictions for Pregnancy Mode. All of this required the attention of many domain teams.

That’s why we focused on building the right abstraction, which is crucial for any platform. In our case, that was the concept of widgets (an external representation of domains) and channels (places for user engagement and interactions, such as chatbots, feeds, or onboarding).

The idea was simple. We introduced widgets to navigate users across the app, or take action (for example, to log symptoms) inside channels. In that case, domain teams hide their domain’s complexity when mode teams could find the best place for widgets based on user goals or behaviors inside channels.

From the product perspective, we help users take needed actions at the most suitable time and place in the app:

This abstraction formed our super-app ecosystem, which is a working skeleton for any mode of our application. Instead of overwhelming collaboration around every use case, we split responsibilities with clear contracts:

●      By default, domains provide widgets as a way for users to interact with them in channels.

●      Channels are platforms for widget integration and content personalization.

●      Mode teams build user journeys based on specific goals on top of channels.

Triggers for change

We  identified the following triggers for change that are formulated in Team Topologies:

●      The software has grown too large for one team. In our case, the nature of building modes is not possible within one team. Before, this was not so critical because teams often simultaneously interacted around one use case, but this changed with our growth.

●      Delivery cadence slowed. Without a clear API interaction, many teams repeated the same formal procedures: understand what needs to be done, decide when, and only then develop it.

●      Multiple business services relied on a large set of underlying services. Engineering practices like inner-sourcing shaped our culture of collaboration, but as the number of teams and interactions grew, we needed a higher level of abstraction between teams.

However, the biggest trigger was the Partner Mode team’s lack of understanding of where to move after the initial product discovery. That is why we explicitly describe our strategy:

●      We build modes on top of platforms.

●      The domains team owns all modes-specific development related to their domain.

Our platform capabilities and interaction strategy helped to decompose Partner Mode development into three main parts:

●      Sharing data through the widgets for seamlessly linking partners’ accounts.

●      Partners’ screens are built on top of the feeds and stories channels.

●      The mode team configures all custom experiences, such as onboarding, on the platform level.

How Team Topologies helped

The capabilities of the Flo platform have evolved over the years. Building Partner Mode required various teams to create many new features. So, we changed the paradigm to have mostly non-blocking dependencies and narrowed the development scope for modes.

The most difficult obstacle was that we lacked defined team interactions, which is a key element for evolution. Understanding interactions' characteristics, advantages, disadvantages, and constraints allowed us to understand what to apply and how. The Team API approach helped us outline what was needed during the discovery phase.

Where we need rapid innovation and discovery, and fewer handoffs, we apply collaboration interaction. In the case of Partner Mode, we had to build new widgets for data-sharing between partners. For us, the best choice was to do it together as one team: Trust & Partner Mode.

Where we need to unblock teams detecting gaps and misaligned capabilities, we apply facilitation, in which experienced teams help with the proper implementation. In our example, the Stories team facilitated building partner screens on top of the feeds and stories channels.

Overcoming new challenges

The main challenge when our domain teams transformed into channels was to treat them as platforms.

We didn’t have the same level of service, responded to errors differently, and needed a common orchestration approach. It took a lot of work to accept that vertical platforms require the same governance as traditional horizontal ones.

It was not enough to conceptualize the desired state; we had to drive the changes through clear metaphors. The importance of socializing, often referring to the Team Topologies concept, was crucial in our journey:

1. We reinforced domain ownership and changed the paradigm from mode teams bringing features to the team, to bringing goals with a certain amount of autonomy.

2. We emphasized the importance of moving quickly and testing many hypotheses, even in complex projects, which is why we need platforms.

3. We developed a communication strategy for explaining why and how we work.

4. A simple abstraction of widgets and channels was easy to explain. We built nothing from scratch but adapted existing experiences when the need for change came from the product side.

Outcome

We launched Flo for Partners in October 2023 in English and worldwide the following March. Flo for Partners—which allows primary users to share period-tracking with a partner to make conception a team effort—unlocks a new audience and growth opportunities. Already, more than two percent of our monthly active users are male, with much better retention than we expected.

Thanks to our strategy’s formalization, the POC took only one quarter to develop. The ten participating teams performed with a high level of autonomy, using collaboration and facilitation in single cases only. However, it is worth noting that the road to this formalization was long, due to constant improvements within other complex features across domains.

We finally formed our channel ecosystem. Following this concept, we could scale modes and domains independently when channels provided a way to combine them into one holistic user experience from user acquisition to custom development and monetization:

With the explicit platform strategy, we simplified upfront planning for any mode for the whole organization. Defined interaction models between teams streamlined execution with just enough collaboration.

In April 2024, Flo's Partner Mode reached a significant milestone: 1,000,000 monthly active users. Partner Mode's popularity is growing, and in the last 30 days, we had half a million additional organic installs because of it.