From domain silos to strategic ownership: How FloHealth evolved its operating model with the GM structure

Company context

Flo Health is on a mission to build a better future for female health — an area of health care that has been overlooked and underserved for too long. Founded in 2015 and now Europe's first femtech unicorn, Flo is the world's #1 women's health app, with over 380 million downloads, 78 million monthly active users, and 5 million paid subscribers globally. It is the #1 OB-GYN-recommended app for period and cycle tracking among 500 surveyed US obstetricians and gynecologists and backed by a team of 120+ doctors and medical experts.

Flo supports women and people who have periods across their entire reproductive lives — from menstruation and fertility to pregnancy and perimenopause. The app combines AI-driven personalization, medically reviewed health content, cycle and ovulation tracking, and a private peer community into a single daily health companion used by 1 in 4 women in the United States every month.

With over 500 people across the company and more than 350 in product and engineering alone, Flo is not a start-up navigating its first scaling challenge. The organizational complexity is real: 20+ cross-functional product teams, multiple value streams, and a product surface that spans mobile, AI, content, medical, and commercial. And yet, for a period during the company's growth, the organization struggled to ship large, cross-functional bets at the speed and with the ownership clarity the business demanded.

This is a case study about why that happened — and what we did about it.

The starting point: A domain-oriented structure

Flo's product and engineering organization is built around two primary value streams.

The first — value creation — owns the core user experience: cycle tracking, health insights, symptom logging, content, and the daily product interactions that bring 78 million users back to the app every month.

The second — value capture — owns monetization and commercial performance: subscription flows, paywalls, pricing experiments, and the conversion and retention mechanics that turn engaged users into paying subscribers.

Surrounding both streams is a broad supporting infrastructure: medical experts, analytics, marketing technology, product marketing, social growth, and user acquisition — functions that don't sit within either value stream but are essential to delivering meaningful outcomes.

Each team within these streams has a dedicated product manager and engineering manager. Teams are domain oriented — they own their area deeply, they know their users, and they have the expertise to execute within their scope.

This structure has not changed, and that's intentional.

The challenge Flo faced was not that the domain structure was wrong. Domain teams are effective at owning and improving their product slice. The challenge was that Flo's most important opportunities — the bets that could meaningfully move the business — didn't fit inside a single domain. They required coordinated delivery across six, eight, and 10 teams simultaneously. And the existing structure had no answer for that.

On an Org Topologies™ map, this is a classic tension within a Delivery Topology. Domain teams — Tracker, Health Monitor, Onboarding, Monetization, Chatbots — are PART-3 units: complete end-to-end within their scope and deliver partial solutions within the women's health ecosystem. Platform teams — Survey Engine, AI Platform — are CAPS-3 units: building infrastructure and capabilities that other teams depend on, with value delivered indirectly. Directing roles — product managers, designers, analysts — sit in WHOLE-1: they think at the whole-solution level but are incomplete without the teams that execute.

The archetypes were in place. What was missing was a single accountable owner at the whole-solution level. Without one, cross-domain initiatives had no single accountable leader — and coordination collapsed into informal escalation.

What made the structure hard

Flo's biggest opportunities weren't domain sized. Perimenopause — a new health vertical targeting a chronically underserved user segment — required changes to onboarding, the home screen, the symptom checker, content, notifications, chatbots, and monetization. That's six or more teams.

The challenge wasn't capability. It was coordination.

When a cross-domain initiative needed to ship, someone had to drive it. But the structure didn't designate who. The result was a recurring pattern: A new initiative was identified as a priority; someone informally stepped up to lead it or was informally nominated; that person spent most of their time negotiating priorities and chasing alignment rather than driving the work forward; domain teams received competing requests from multiple stakeholders with no shared priority framework; and conflicts escalated directly to the CPO or CTO — informally, often via whoever raised their voice loudest.

Planning reflected the same dysfunction. Each team prepared its backlog based on its own domain priorities. Cross-team dependencies were rarely made explicit upfront. There was no shared program timeline — each team had its own, built in isolation. Predicting a delivery date for a cross-functional initiative was nearly impossible. In practice, "done" meant "when the last team finishes their backlog." Priority conflicts were resolved informally or simply deferred until they surfaced mid-delivery, at which point the only options were escalation or a missed date.

The turning point

In November 2025, as Flo was preparing for our 2026 planning cycle, product and engineering leadership gathered for a working session with a clear agenda: The company's strategic ambitions had outgrown the way we organized delivery.

Flo's 2026 priorities were sharpening around two directions: deepening the core product experience and expanding into new health segments. To pursue both simultaneously, the company had identified a small number of high-stakes, high-impact initiatives — what we call big bets. These weren't incremental improvements to a single domain. They were bets that required the entire organization to pull in the same direction, across every function, for an extended period.

The session surfaced three conclusions that became the foundation of the new model:

1. Flo's most important opportunities were cross-functional by definition — no single domain team could own them.

2. Coordination through informal leadership wasn't scaling. The organization needed designated, explicit ownership.

3. We needed a structural answer to a deceptively simple question: Who is accountable for this initiative, end-to-end, from insight to business outcome?

The answer was the general manager model. Describing the framework was the easy part. What followed — aligning teams, changing behaviors, and navigating the tensions that come with any real organizational change — is still very much a work in progress. This case study is as much about that ongoing journey as it is about the design itself.

The new structure: General managers and virtual teams

What a GM is

A general manager (GM) at Flo is a single-threaded owner of a strategic initiative — a big bet. The GM is accountable for the full life cycle: vision, strategy, delivery, go-to-market, and commercial outcomes, including revenue, average revenue per user, and lifetime value.

The GM role draws on the Amazon single-threaded leadership model: one person, clearly accountable for the success of a single initiative from end to end. Critically, the GM is not a project manager, coordinator, or second product manager. They own outcomes, not outputs. They lead through influence and shared goals, not authority or direct management.

In its fully realized form, the GM role is a dedicated, full-time position — a director or VP-level leader reporting directly to the CPO, focused entirely on one big bet. The scope of the role demands it. Coordinating across the product, engineering, design, marketing, medical, analytics, and commercial teams simultaneously is a full-time job.

In practice, Flo's current GMs are VPs and directors of product who hold the GM role in addition to their functional responsibilities. A VP of product has a distinct job: line-managing teams, developing people, and driving a broader product agenda.

Naming this tension honestly is important. The GM model is sound. The current implementation is a stepping stone toward a structure where GM is a dedicated role — not a hat worn on top of another.

The core team structure

Each GM leads a core team — a virtual, cross-functional group of dedicated representatives from every relevant function: product, engineering, design, marketing, medical, analytics, and commercial.

These representatives are not merely consulted; they are personally committed to the initiative for its duration. Dedication is time phased — not every function is needed from day one. Representatives join when their function becomes critical to the program, and their level of commitment reflects the current phase — discovery, delivery, or go-to-market.

The core team sets initiative direction, sprint goals, and cross-functional alignment. The actual execution happens in domain teams — the same engineering and product teams that have always existed in the organization. Domain team product managers (PMs) and engineering managers (EMs) manage sprint-level priorities in coordination with the relevant core team representative.

This is the key design principle: the GM model is an overlay, not a replacement. Domain teams retain their structure, expertise, and line management. On the Org Topologies map, this overlay sits within the Delivery Topology, adding a WHOLE-1 coordination layer on top of the existing PART-3 and CAPS-3 archetypes without changing their fundamental structure or reporting lines. The core team provides the cross-functional ownership layer that was previously missing, but it does not merge directing and doing into a single unit. Those remain separated.

The model draws on Large Scale Scrum (LeSS) principles to guide line managers' operations within this structure. In LeSS, managers are not priority setters or blockers — they are obstacle removers. Their job is to understand what's preventing their teams from being effective, resolve cross-team dependencies, and create the conditions for good work. This is what we expect from engineering and product leaders whose teams are contributing to a big bet: not to compete with the GM's direction, but to enable their teams to deliver within it.

Decision rights

One of the most important outcomes of introducing the GM model was making decision rights explicit. Before, the absence of a designated owner meant that anyone — any PM or EM — could walk directly to the CPO with a question, conflict, or priority request. The CPO, accessible and engaged, would often resolve things directly. This created a dynamic in which authority was effectively centralized at the top, regardless of the org chart.

Area	Owner
Initiative vision, goals, success metrics	GM — full ownership
Product strategy and business prioritization	GM — decides, informs CPO
Monetization and commercial model	GM + domain PMs, joint
Product execution and feature delivery	Delegated to domain PMs
Cross-functional dependencies and escalation	GM is the escalation owner
Resource allocation	GM requests; line managers and leadership decide based on program priorities

The GM model changed this. Within the scope of their big bet, the GM has full decision-making authority. The CPO is kept informed, not consulted for every call. Resource allocation deserves a specific note. Domain teams report to their own line managers, not to the GM. The GM cannot unilaterally assign teams to a big bet. They make the request, and leadership decides based on company-wide priorities. We attempted a more dedicated allocation model early on, but in practice, teams carry obligations beyond any single big bet, and maintaining full dedication proved difficult. The planning process we've developed for the second half of the year — with explicit capacity rules, sprint-level visibility, and program priorities set before team-level planning begins — is our current answer to making resource allocation more predictable and less reactive.

What changed in planning

The GM model also forced us to rethink our half-year planning. The domain-first, team-by-team approach that had defined planning before was incompatible with a structure where strategic priorities are set at the program level first.

We redesigned the planning process for the second half of the year around five steps:

1. CPO + GM session: The CPO sets explicit priority order across big bets — not "all are important," but a ranked list that domain teams can use to resolve conflicts without escalating. GMs surface their initiative needs: which domain teams, what capacity, what sprints. Known dependencies and conflicts are flagged.

2. Asynchronous engineering director review: Engineering directors review the initiative list within two to three days and flag anything unrealistic or incomplete — no meeting, written comments directly in the planning document.

3. Domain team input: Domain teams provide honest capacity assessments based on their historical baselines — typically targeting ~60% for growth initiatives, with the remainder pre-allocated to tech debt, operations, and support. For each initiative assigned to their team, they confirm whether they can deliver in the requested window, at what capacity load per sprint, and with what risks. They also surface already-reserved sprints and existing commitments that the GM layer doesn't see.

4. Conflict filtering: Before the final session, unresolved conflicts are reviewed and grouped by the head of product operations and the engineering directors. Only what genuinely requires CPO/CTO input goes forward — everything resolvable by program priority order is resolved at this stage.

5. Final session — GMs + engineering leadership: At a decision meeting, not a data-gathering meeting, trade-offs are made, conflicts resolved, and commitments finalized.

The process is supported by a shared planning document with an explicit structure: initiative owner, program priority, teams needed, sprint capacity required, dependencies, and a team response column. Focus over parallelism is a stated principle — one initiative completed fully is worth more than three running simultaneously at reduced speed. Teams decide how to sequence their work; the role of the process is to make priorities and constraints visible, not to prescribe how teams operate.

What we learned: Honest tensions in the new model

Engineering was often left out of discovery

In the early months, GM-led initiatives operated with a sequential pattern that looked uncomfortably like a waterfall: design → UXR → content → medical review → engineering. Our own Jira data confirms this: The median pre-engineering gap across product-led epics was five to seven days, but outliers ranged from 31 to 102 days. Two epics in early 2026 had zero engineering tasks after more than five weeks of active work — design, UXR, and content handled all child issues. Pure tech epics showed no such delay, confirming that the bottleneck was in the product and design pipeline, not engineering readiness.

Engineers were receiving handoffs rather than participating in cocreation. As one engineering manager put it directly, "This leads us to operate as an agency rather than a true product team." When engineering is excluded from discovery, the team loses its ability to propose technical alternatives, flag implementation risks early, or identify capability gaps that could shape the solution. Technical simplifications go unspotted. The scope of the minimum viable product goes unquestioned. The result is slower delivery and more expensive solutions.

We're actively working on this: a mandatory engineering checkpoint after initial design direction but before detailed specs, and a discovery trio model — PM, design, and engineering — starting together at day zero, not in sequence.

Race conditions on domain teams

The GM model created a new coordination challenge: multiple big bets, each with a mandate to deliver results, competing for the same domain teams. Some domain teams found themselves requested by two or three programs simultaneously — sometimes within the same quarter. The pattern repeated across verticals. One team was fully committed to a big bet. At the same time, another program was still expected to be delivered from the same team in the same quarter, unaware of the existing commitment.

Without explicit capacity visibility, GMs made plans in partial isolation. The consequences were predictable and documented: A domain team would receive an urgent, high-priority request late in the planning cycle with no room to drop existing scope. In one case, a request arrived at the end of January — weeks into the quarter — with an expectation to deliver by the middle of the second quarter. Nothing was dropped. Everything slowed down. In another case, home screen experiments from two separate big bets clashed because neither program had visibility into what the other was asking of the same team.

The tension was structural: GMs had delivery mandates and OKRs, but domain teams had finite capacity that was never made visible or negotiated at the program level. Each GM was optimizing for their own big bet without visibility into what the others were asking of the same teams.

This is precisely the problem the new planning process is designed to address, by creating a shared initiative radar that maps all active programs to the domain teams they require, with capacity and timelines visible before commitments are made, not after conflicts emerge.

Priority conflicts at the team level

Within a single big bet, the single-threaded owner model surfaced a different, but equally structural, problem: the domain team's own PM had no authority to protect their team's capacity.

Multiple product managers within the same program would approach the same domain team independently — each with legitimate work, each unaware of what the others were asking. The team's PM could see the collision coming, but had no process-backed way to resolve it. Without a formal intake mechanism, every request carried implicit pressure. It came from a GM-led program, it was aligned with the company's goals, and it was important. Saying, "Not this sprint," required a conversation that shouldn't have been necessary.

The result was that domain teams felt like order-takers rather than owners of their own delivery. The structural fix is clear: All requests, from a big bet to a domain team, must flow through a single, ranked priority list owned by the GM, and every domain team needs a formal intake process that gives their PM and EM the authority to sequence work. Building that discipline consistently is still a work in progress.

We expected adaptive; we found something more honest

When we designed the GM model, the aspiration was clear: move Flo toward a more adaptive way of organizing — where teams own outcomes end-to-end, where cross-functional collaboration is structural rather than coordinated, and where the organization self-steers rather than being steered.

That is not what happened. And mapping the organization honestly — before and after the GM change — made that visible in a way that no amount of internal discussion could.

Before the GM model, Flo was already operating as a Delivery Topology: PART-3 domain teams delivering partial solutions within the women's health ecosystem, CAPS-3 platform teams providing enabling capabilities, and WHOLE-1 directing roles thinking at the whole-solution level, but incomplete without the teams that execute. The organization had the right archetypes. What it lacked was a designated owner at the whole-solution level.

After the GM model, Flo still operates as a Delivery Topology. What changed is that we added a WHOLE-1 coordination layer — the GM — to explicitly own cross-program priorities, set direction for the virtual team, and hand off work to domain teams in a structured way. The domain teams remain intact. The reporting lines remain unchanged — the fundamental split between directing and doing remains.

It is one of the most useful things Org Topologies mapping can do: show you clearly where you are, rather than where you hoped you were going.

There is a second, harder tension that the GM model has also surfaced. In the short term, teams are more focused — they know which big bet they are contributing to, and that clarity drives performance. But focus has a cost. When teams orient around program priorities, something else gets deprioritized: domain work, technical debt, and improvements that don't belong to any big bet but keep the product healthy. The teams know what they are not doing. That knowledge lives with the people closest to the work — and making it visible is the next important step.

Where we are now

The GM model is now operational across Flo's current big bets. The structural foundations — core teams, decision rights, weekly business reviews, monthly business reviews, and capacity rules — are in place.

The early signals are encouraging:

• Escalations to the CPO have decreased. GMs are making decisions within their programs rather than deferring to their superiors.

• Ownership is more visible. It's now clear who is accountable for each strategic initiative, and that clarity has changed how teams orient around priorities.

• Cross-program prioritization has become more explicit. Instead of informal competition, programs are ranked, and domain teams have a framework for resolving conflicts without escalation.

• Team focus has measurably improved. We actively track which teams are working on which big bets, and the concentration of effort on strategic priorities is noticeably stronger than before.

  
  

But here is the honest mapping.

When we introduced the GM model, we hoped it would move Flo toward an Adaptive Topology — where directing, doing, and delivering merge into unified, self-steering units. That was the aspiration. The Org Topologies mapping tells a different story.

As the mapping shows, Flo was already operating as a Delivery Topology — and the GM model did not change that. What it added was a WHOLE-1 coordination layer: a designated owner at the whole-solution level that had previously been missing.

In Org Topologies terms, this is an improvement within Delivery Topology — making it more fit for purpose, not an elevation toward Adaptive Topology. The organization now coordinates better. It does not yet self-steer.

The work is not done. But the direction is now more honest. We have made the Delivery Topology fit for purpose. The next question — whether to elevate toward Adaptive Topology — is a separate decision, with different implications and a different kind of organizational change.

What the teams are telling us

The three tensions described above — engineering excluded from discovery, race conditions on domain teams, and competing priorities — emerged from structured feedback collection across engineering managers and product leads. But the teams surfaced two additional patterns that deserve naming.

The first is planning timing gaps. Late OKR finalization forced teams into double-planning cycles. Teams would plan on assumptions, then replan once direction was confirmed. Without a structured planning window, short-notice changes became especially disruptive. The five-step planning process we introduced for the second half of the year is a direct response to this, locking in program priorities before team-level planning begins, not after.

The second is portfolio add-only bias. New high-priority items were added to the initiative list throughout the quarter, but nothing was paused or removed. "Everything is a high priority" dilutes focus and erodes the list's signaling power. When every initiative is a priority, none is. We've since introduced a one-in, one-out rule for portfolio grooming and a monthly review cadence to enforce explicit trade-offs.

Together, these patterns point to the same underlying issue: The GM model created clearer ownership at the program level, but initially without the supporting mechanisms that domain teams needed to protect their capacity, sequence their work, and push back on unrealistic asks. Building those mechanisms — intake processes, capacity visibility, portfolio discipline — is the operational work that makes the structural change sustainable.

Key takeaways for practitioners

1. Naming the owner is necessary but not sufficient. Introducing a GM or single-threaded owner role creates clarity of accountability. It does not automatically create the conditions for that accountability to be exercised. Decision rights, escalation paths, and planning processes must be redesigned to match the new ownership model.

2. Domain expertise and cross-functional ownership are not opposites. The temptation in transformations like this is to dissolve domain teams and rebuild around feature teams or verticals. We deliberately avoided this — and not just for organizational convenience. Every time you restructure teams, you reset the clock. Managers change, career paths shift, and teams go back to forming and storming before they can perform again. In a large organization, this cost compounds fast. By the time the new structure reaches a state of performance, the strategic context has often already changed.

Flo's approach was different: Keep the domain teams intact and preserve their expertise, ways of working, and line management. Add the GM layer as an overlay. The domain teams already know how to perform. The challenge was to give them a coordination structure that enabled them to deliver cross-functional outcomes without abandoning what made them effective. You don't have to choose between domain depth and cross-functional ownership. The overlay model gives you both.

3. Planning must follow priority, not precede it. If program-level priorities are not set before team-level planning begins, teams will plan in silos. The order matters: CPO sets program priorities first; GMs surface initiative needs second; domain teams respond with capacity assessments third.

4. Capacity conflicts are a planning failure, not a team failure. When domain teams receive late, urgent, unresolvable requests, it means capacity was not made visible and negotiated at the planning stage. The fix is structural, not behavioral.

5. Engineering belongs in discovery. Sequential handoff from product and design to engineering is a symptom of a topology that hasn't fully evolved. Cross-functional cocreation from the start of discovery — not just from the start of delivery — is a marker of genuinely adaptive operating.

6. The GM role works best as a dedicated position. Asking a VP or director of product to be the single-threaded owner of a high-stakes, cross-functional program while also doing their day-to-day job is asking them to do two full-time jobs at once. It works as a starting point, and it is how Flo operates today, but the cost is real. The GM role competes with line management responsibilities, people development, and the broader product agenda. For any organization considering this model, the long-term direction is clear: GM should be a dedicated role reporting to the CPO, fully focused on a single big bet.

7. An overlay model improves your topology — it does not change it. Adding a coordination layer on top of existing domain teams — a GM, a program board, a virtual team — can significantly improve how your organization operates within its current topology. It reduces coordination waste, makes priorities explicit, and assigns a designated owner to cross-functional initiatives. These are real and valuable gains.

But an overlay does not elevate your topology. If directing and doing remain separated, reporting lines stay unchanged, and domain teams remain in their existing archetypes — you are still in the same topology, just a better-functioning one. Mapping your organization honestly before and after the change will make this clear.

In Flo's case, the mapping revealed that we were already operating as a Delivery Topology — PART-3 domain teams, CAPS-3 platform teams, WHOLE-1 directing roles. The GM model added a WHOLE-1 coordination layer on top. The Delivery Topology became better coordinated. It did not become Adaptive. The lesson is not that overlays are wrong.

The lesson is that you should know what you are getting. If your goal is to improve coordination within your current topology, an overlay delivers that. If your goal is to move toward Adaptive Topology, you need structural change: different team compositions, different reporting lines, and the merging of directing and doing into unified units. Those are different interventions, and confusing one for the other leads to misaligned expectations on all sides.

---

Vitali Kukharchyk is head of product operations at Flo Health, where he leads the product operations team embedded with general managers and partners with the CPO and CTO on planning, operating model design, and organizational effectiveness. He has 12+ years of experience in product operations and Agile coaching.

LinkedIn: linkedin.com/in/vitali-kukharchyk