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.
There are four main ways to structure your product team:
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:
Where the functional model breaks down:
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.
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:
Where the managed UX model breaks down:
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.
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:
Where cross-functional teams break down:
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.
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:
Where product triads break down:
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.
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 |
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
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Learn how code-style reasoning helps product managers make sharper decisions, surface edge cases, and write clearer requirements.
A practical framework for product leaders to prioritize better, reduce noise, and focus teams on what matters most.
Explore how urban planning helps product managers think in systems, strengthen foundations, and build products that scale well.
Learn how product managers can move from output tracking to outcome-driven product management with metrics tied to user impact.
Learn more →
