4 product team structures and when each works best

The UX designer finally finished the prototype just to hear that it can’t be built within the necessary timeframe. You’re in a different meeting, and the design lead wants to escalate… but who even owns that decision?

Sound familiar?

Most of the time, situations like that aren’t a people problem, but a team structure one. The way the team is organized directly impacts its delivery speed, collaboration, and whether it delivers or not.

I’ve worked with various structures in the past, each one coming with its own advantages and challenges. In the end, all of them fit one of four major product team structure models.

Let me describe them for you so that you get a sense of what team setup makes the most sense for your individual case.

The 4 main product team structures

There are four main ways to structure your product team:

1. Functional product team structure

The functional model, often called the “siloed model,” is the old-school approach to delivering products.

PMs sit within a product unit, designers work in a design department, and so on. The work often moves linearly from one department to the other, sometimes bouncing back and forth as further input and clarification are needed.

Although often referred to as an “antipattern,” this model has some uses.

When the functional model works best:

• Large organizations with very specialized functions
• Agencies that provide niche, specialized services that don’t require input from other units
• Heavily regulated industries where sign-off chains matter more than speed

Where the functional model breaks down:

• Constant handoffs kill context — Fine details and the “why” behind decisions get lost in the transition, making it harder for further units to understand what actually needs to be built
• Ownership issues — The siloed approach encourages “not my problem” and “it’s their fault” thinking over focusing on actual results

With each department focusing on a fragment of the picture, creativity and collaboration are heavily limited.

The biggest danger of this model isn’t inefficiency — it’s lack of transparency. When people don’t know what other people are doing on the shared initiative, problems are noticed too late, and the feedback loop runs slowly.

2. Managed UX product team structure

A hybrid approach. Designers report to a centralized design function, often with a Head of Design or VP of UX, but get assigned to product teams for projects.

---

---

Think of it as a mix of functional and cross-functional models. The design team stays unified for hiring, standards, and career growth, while day-to-day work happens in cross-functional teams.

When the managed UX model works best:

• Rapidly growing SMEs, where design direction and consistency get shaken by the speed of work
• Organizations where development is design-system-driven
• Teams where the designer-to-engineers ratio is low (one designer serving two to three teams)

Where the managed UX model breaks down:

• Designers report to their UX manager but work with a product manager. When priorities conflict, the designer is often stuck in the middle
• Context switching when one designer serves more than one team
• An overly centralized UX org can become a bottleneck instead of an enabler

For this model to work, the Head of UX needs to be exceptionally good at shielding designers from conflicting priorities and context switching, while also being able to empower and support product teams rather than becoming a bottleneck.

It works well when the design team is small and extremely mature.

3. Cross-functional product teams

This is the most common team model nowadays. Each team has its own PM, engineers, QAs, and designers, as well as an area of ownership, whether it’s a feature or part of the funnel (e.g., onboarding team).

When cross-functional teams work best:

• Mature enough products where areas of ownership can be clearly divided with minimal overlap
• Teams where experimentation speed is among the top priorities
• Products where consistency and other constraints aren’t overly stiff

Where cross-functional teams break down:

• With each team working on its own, it’s hard to maintain a perfectly aligned tone of voice or priorities
• Most decision-making goes to product managers, with designers often being marginalized
• Overlapping work (e.g., when two teams want to make a change on homepage) can create a lot of friction and alignment work

The efficiency of this model scales with the level of independence each team has. Being able to ship quickly and make decisions within the team in a daily standup is awesome. Having to align with four other cross-functional teams to make sure you’re not interrupting one another isn’t.

4. Product triads

A product triad, also called a product trio, is a cross-functional team taken to the next level. Instead of a PM leading the team, the product manager, designer and engineer have equal decision-making power. No single function dominates the decision-making, and key decisions are made jointly.

For larger teams (e.g., those with numerous engineers), one person is usually selected to be “part of the triad” — usually the lead engineer.

When product triads work best:

• Teams working on complex initiatives, with lots of engineering constraints
• Organizations with senior and experienced engineers and designers that can operate with high autonomy

Where product triads break down:

• Requires strong, senior team members — One weak link can easily break the whole idea
• Slower decision-making — Without a single person able to break the tie or make on-the-spot decisions, decision speed suffers
• Diluted accountability — When a triad shares ownership, mistakes can often be boiled down to “shared responsibility,” making it hard for individuals to learn anything

In theory, it’s a great model. In practice, it’s the one I’ve seen fail most often. Usually, a clear boundary of responsibilities and ownership (e.g., PM decides this, designer decides that) is more efficient.

Don’t get me wrong. I’m all for increased collaboration between engineers, designers, and product people, as well as bringing engineers and designers into the process as early as possible. I’m just against the childish “let’s decide on everything together!” approach.

How to choose the right product team structure

So, which model should you adopt?

Well, there’s no straightforward answer. It depends heavily on your organizational context, the seniority of people you work with, and the maturity of the product itself. However, this table might make it easier for you to decide.

If your team…	Consider…	Why
Has 50+ people, needs deep specialization, and operates in regulated industry	Functional (siloed)	Clear accountability chains, deep expertise per function
Has a mature design system, low designer-to-team ratio (1:2 or 1:3)	Managed UX	Maintains design consistency while embedding in product work
Owns clearly separable product domains, needs speed and autonomy	Cross-functional teams	Independent shipping, full context for every team member
Has senior ICs across all three functions, builds experience-heavy products	Product triads	Balanced decision-making, no single-function dominance
Is growing fast and hasn’t standardized yet	Cross-functional teams first, evolve later	Lowest barrier to entry, most room to adapt as you learn what breaks
Is under 15 people and everyone wears multiple hats	Skip the labels, stay fluid	Formal structure adds overhead that tiny teams can’t afford — just ship together
Is fully remote or distributed across 3+ time zones	Cross-functional teams with strong async rituals	Minimizes cross-team dependencies that become brutal with time zone gaps
Has heavy cross-team dependencies and shared codebases	Functional (siloed) or one larger cross-functional team	Artificial team boundaries create more coordination overhead than they solve
Has one overly dominant function that overrides the others	Product triads (with coaching)	Forces equal decision-making power, but only works if leadership backs it
Runs an agency-style model but wants to shift toward product	Managed UX as a transition step	Lets designers build product muscle while keeping the consistency clients expect

The best product team structure changes as your organization evolves

There’s no need to choose and stick to a single model. In fact, you shouldn’t. These models are just a simplified view of various approaches one can take.

---

---

Each context is unique enough that it’s impossible to choose a single best model. They all come with trade-offs, and you need to decide which makes the most sense to you. If the importance of particular tradeoffs changes over time, so should your team model.

In the last three years, the context of the company I’ve worked in has changed so much that our team structure has gone through five major transformations. Each time, it adjusted to the new reality to serve our most pressing needs.

So, just like in product development, experiment, iterate, and adjust on the go.

Featured image source: IconScout