Product team structure: how to organize product teams at each stage

A product team structure is the way a company groups the people who decide what to build, design it and build it. At a startup, that usually means a product manager, a designer and engineers working as one team toward one goal, then several such teams as the company grows.

The right shape changes with each stage, and most structure problems show up as slow decisions or teams waiting on each other. If you are planning the next stage, our startup scaling strategy work maps the team shape and hiring order before the strain shows. This guide covers who belongs on a product team, the main structure models, what fits at each stage and the signs it is time to change.

What is a product team structure?

A product team structure defines who owns which product decisions, how the people on each team are grouped and how teams depend on each other. It covers the roles on each team, what each team owns and the reporting lines around them.

In most software companies the basic unit is a small cross-functional team: product, design and engineering working on the same problem at the same time. Structure is what happens when there is more than one of those teams. You decide how to split the product between them, who leads each one and how they share people, code and goals.

A good product team organizational structure gives every important decision one clear owner. A weak one leaves decisions with nobody, or with three people at once. Both show up quickly in missed releases and features that ship but do not move a metric.

Who is on a product team?

The core of a product team is a product manager, a product designer and the engineers who build the product. Teresa Torres of Product Talk calls the first three decision-makers a product trio: a product manager, a designer and a software engineer working together on what to build.

• Product manager. Owns the problem, the goal and the order of work. Says what to build next and why, and what to leave out.
• Product designer. Owns how the product works for the user: flows, interface and the usability tests that check them.
• Engineers. Build and run the product. A tech lead in the trio judges what is feasible and what it will cost to maintain.
• Supporting roles. Product marketing, data analysis, product operations and quality assurance join as the company grows, often shared across several teams.

Torres describes the old handoff model, where the product manager writes requirements, the designer draws mockups and engineers code, as the source of rewritten requirements and redesigned screens. In her explanation of the product trio she argues the three roles should decide together from the start. That shared work is the heart of a sound product discovery process.

Two titles cause most of the confusion at this point. Our guide to product owner vs product manager explains how those roles split, and the guide to the startup CTO covers the chief technology officer (CTO) who leads the engineers on the team.

Product team structure models compared

There are four common structure models: functional, cross-functional teams by product area, teams by customer segment or lifecycle stage, and platform teams that serve other teams. Most growing companies combine two of them rather than picking one.

Each model splits the work along a different line, so each one fails in its own way. The table shows where each model works and what to watch for.

Functional and matrix teams

In a functional structure, people sit with their discipline and work passes from one department to the next. It is simple to run at five people and slow at fifty, because every feature crosses every department. A matrix keeps the functional reporting line and adds a product team on top, so each person has two managers. It can work, but only when everyone knows which of the two decides what.

Teams by product area or customer

Cross-functional teams own a part of the product, such as search, reporting or billing, or a part of the customer lifecycle, such as sign-up and onboarding. Each team holds its own product manager, designer and engineers. Amazon describes the same principle as single-threaded ownership: each small team is focused on one service or offering and the customers who use it. One team, one outcome is the simplest test of a split.

Platform teams

A platform team builds shared internal services, such as a design system, data pipelines or deployment tooling, so the teams facing customers can move faster. In Team Topologies, Matthew Skelton and Manuel Pais name four team types (stream-aligned, enabling, complicated subsystem and platform) and three ways teams interact: collaboration, X-as-a-Service and facilitation. Their key concepts page describes a platform team as one that provides a compelling internal product to speed up delivery by stream-aligned teams.

Product team structure at each startup stage

Most startups move from a founder-led team to one product trio, then to several cross-functional teams, and later group those teams by customer and add a platform team. Funding stage is only a rough stand-in for team size and product complexity, so read the table as the usual pattern, not a rule. Each structure has a point where you adopt it, a stretch where it fits and a sign that you have outgrown it.

At pre-seed, a separate product function is usually overhead. The founders talk to customers and decide, and the engineers build. The structure starts to strain when the founders become the queue every decision waits in.

At seed, the first dedicated product hire turns the founders' instincts into a repeatable rhythm of discovery and delivery. Some companies make that first hire part-time before they know the role well enough to hire for it permanently.

Product management team structure as you grow

Once there are several teams, the product management team structure needs its own layer. A head of product sets the strategy and the goals each team works toward. Each product manager owns one team's area. Later, group product managers each lead several product managers in one part of the product, and product operations looks after the tools, data and rituals that every team shares.

How big should a product team be?

Most product teams work best small: Amazon's two-pizza rule, as Amazon Web Services (AWS) describes it, is ideally a team of fewer than 10 people. The reason is communication. Every person added to a team adds a line of communication to everyone already on it.

The number of possible one-to-one lines in a team of n people is n times (n minus 1), divided by 2. Calculated with that formula:

• 3 people have 3 lines of communication.
• 5 people have 10.
• 9 people have 36.
• 15 people have 105.

Going from 9 people to 15 almost triples the lines while adding two-thirds more people. AWS makes the same point in its description of two-pizza teams: smaller teams minimize lines of communication and the overhead of decisions. When a team grows past the point where everyone can follow every conversation, split it along a line in the product rather than adding a coordination meeting.

What the Spotify model actually says

The Spotify model describes small autonomous teams called squads, grouped into tribes, with chapters and guilds linking people with the same skills across squads. It is the most copied team structure in software, and its own authors presented it as a snapshot, not a template.

The model comes from Henrik Kniberg and Anders Ivarsson's paper "Scaling Agile @ Spotify". In 2014, Kniberg introduced Spotify's engineering culture videos on Spotify's own engineering blog by calling them a work in progress, with a lot of variation from squad to squad. The second video, he wrote, sits somewhere between how things are and how Spotify wanted them to be.

The useful lesson is the principle underneath: small teams with a clear mission and the skills to deliver it. Renaming teams as squads and departments as tribes changes nothing on its own. Copy the ownership, not the vocabulary.

Signs your product team structure needs to change

A team structure needs to change when the way work is split, rather than the people doing it, is what slows delivery. The signs are predictable, so you can check for them before a reorganization becomes urgent.

• Decisions queue at the top. If every priority call waits for a founder or the head of product, teams do not own their goals. Give each team a goal it can move on its own.
• Teams split by layer. A front-end team and a back-end team turn every feature into a handoff. Teams that each hold the skills to ship a whole feature remove that wait.
• One engineer pool, several product managers. When product managers compete for the same engineers each sprint, nobody owns delivery. Stable teams with their own engineers fix it.
• Every feature needs two teams. The split no longer matches the product. Redraw the boundaries around what customers do, not around the original code.
• A platform team with no customers. A platform team started before several teams share a real need builds tools nobody asked for.
• Two managers, no decision. In a matrix where both managers can say no and neither can say yes, work stalls. Name who decides what.

Change one boundary at a time and watch delivery for a few cycles before the next move. Every reorganization costs a team the shared habits it built, so it should solve a problem you can name.

A product team structure example after Series A

A typical structure after a Series A has a head of product and three cross-functional teams, each owning one part of the product. This product team structure example is an illustration, not a client: a business-to-business (B2B) software as a service (SaaS) product with onboarding, reporting and billing.

• Onboarding team. A product manager, a designer and engineers who own everything from sign-up to a new account's first useful result.
• Reporting team. The same trio shape, owning dashboards, exports and the data customers see.
• Billing team. Owns plans, invoices and payments, including the compliance work that comes with them.
• Shared work. The design system and the deployment pipeline belong to nobody yet. Each team maintains its own copy.

This is a sound SaaS product team structure until the shared work starts to slow all three teams. That is the point to form a small platform team that serves the other three in an X-as-a-Service mode. Until then, a named owner on one of the existing teams is enough.

How we help startups shape their product teams

We help founders design the team the next stage needs, before growth exposes the gaps. Our scale planning work covers team shape, hiring order and role briefs for founders working out how to scale a startup past its first teams.

When the first product hire is not yet a full-time role, a fractional product manager can run discovery and delivery in the meantime. When you need more hands as well as structure, team augmentation adds senior engineers to your own teams. Every engagement is under a non-disclosure agreement (NDA), the intellectual property (IP) is always yours, and each one is quoted after a short call.

Frequently asked questions