Designing Product Org Structures for Scale
The right product org structure is not universal — it depends on your product architecture, your growth stage, and your strategic priorities. Here is how to make the decision deliberately rather than by default.
Most product organizations choose their structure the way most companies choose their office layout: by copying what seemed to work somewhere else, without examining whether the conditions that made it work there are present here.
The result is product organizations whose structures are misaligned with their product architecture, their stage of growth, or their strategic priorities — and which spend enormous energy compensating for structural misfits through meetings, escalations, and informal workarounds.
Product org design is one of the highest-leverage decisions a Head of Product makes. It is also one of the least understood. Here is a framework for making it deliberately.
The Core Design Dimensions
Product org structures vary along four primary dimensions. Understanding where your organization should sit on each is the first step to deliberate design.
Functional vs. Squad Model
In a functional model, PMs are organized by functional area — PM for growth, PM for core product, PM for enterprise features. The functional model optimizes for specialization: each PM develops deep expertise in their domain.
In a squad model (also called product trio or cross-functional squad), PMs are embedded with specific engineering and design teams. The squad model optimizes for autonomy and execution speed: the squad has everything it needs to make and execute decisions without cross-functional coordination.
The functional model tends to produce better decision quality in technically complex domains (where deep expertise matters) and worse execution speed (because cross-functional coordination requires meetings). The squad model produces better execution speed and higher team ownership, at the cost of coordination at squad boundaries.
Most growth-stage B2B companies start with a functional model and transition to squads between 20 and 50 engineers. The transition point is typically when communication overhead for cross-functional work exceeds the coordination overhead of managing squad boundaries.
Platform vs. Feature Teams
In a feature team model, all squads work on customer-facing product capabilities. Each squad builds features for a segment of users or a product area. Engineering is oriented toward shipping new functionality.
In a platform team model, some squads work on foundational capabilities — APIs, data infrastructure, shared services, developer tools — that enable other squads to build faster. Platform teams do not ship directly to users; they ship to other teams.
The platform team model is appropriate when: foundational capabilities are becoming a bottleneck for feature teams, when technical leverage is significant (one platform team unlocking 3x the feature velocity for three product squads), or when the product is evolving toward a platform business model.
The costs of a platform team model: platform teams are harder to motivate (their customers are internal, not external), harder to measure (no direct user outcome metrics), and require a different type of PM (someone who thinks in APIs and developer experience rather than user journeys). Underestimate these costs and you will build platform teams that are underfunded, under-measured, and unable to attract strong talent.
Embedded vs. Centralized Research
Embedded researchers sit within specific product squads and develop deep expertise in a specific user domain. They conduct research in service of the squad’s current priorities.
Centralized researchers serve multiple squads from a shared pool, conduct both tactical and strategic research, and maintain organizational knowledge that spans product areas.
Embedded research produces faster decision cycles and deeper domain expertise within squads. Centralized research produces better organizational memory, avoids duplicate research across squads, and enables research that informs strategy rather than just tactics.
The right model depends on research volume (centralized makes more sense above a threshold of research needs), product coherence (embedded makes more sense when different product areas have genuinely different user populations), and the maturity of your research capability.
Most companies centralize research in the early stages and add embedded research capacity as product areas become sufficiently distinct and research-intensive to justify it.
Matching Structure to Product Architecture
The most important insight in product org design is Conway’s Law: organizations design systems that mirror their own communication structures. The inverse is also true — your product org structure shapes how your product is built.
If your product has two distinct user populations (e.g., buyers and suppliers in a marketplace) and your product org has squads organized by functional area rather than by user segment, every feature that spans both user populations will require cross-squad coordination. The product will accumulate cross-squad dependencies that slow delivery and produce integration failures.
The right structure aligns organizational boundaries with product architecture boundaries. Where the product has clear seams — distinct user populations, distinct technical subsystems, distinct revenue streams — the org structure should place a squad boundary there. Where the product requires tight integration — shared data models, interdependent user journeys, shared infrastructure — the org structure should ensure close coordination, either through shared ownership or through explicit interface contracts.
Stage Dependency
The right structure is also stage-dependent. The structure appropriate for a 40-person company is not the right structure for a 150-person company.
At early stages (< 30 engineers): Keep structure minimal. Two or three generalist squads with broad charters. Focus energy on product discovery and iteration speed, not coordination infrastructure.
At growth stage (30–100 engineers): The organizational architecture decisions described in this article become important. Squad boundaries, platform team investment, research model — these need to be made explicitly or they will be made by default, usually badly.
At scale (100+ engineers): Org design is a continuous investment, not a one-time decision. As the product evolves, as the company moves into new segments, as the technology stack evolves, the org structure needs to evolve with it. What made sense at 80 engineers may actively harm you at 200.
A Decision Process for Org Design
Before restructuring or designing from scratch, answer these questions:
- What are the natural seams in our product? (Where does user journey shift significantly? Where does the technical architecture have clear module boundaries?)
- What are our current coordination bottlenecks? (Where are squads spending the most time in cross-team meetings and escalations?)
- What is our primary growth strategy? (Expansion within existing segments, new segments, platform/ecosystem? Each has different structural implications.)
- What capabilities do we want to develop? (Research excellence, platform thinking, enterprise product design?) (The org structure should support capability development, not just current execution.)
The answers to these questions define the constraints within which the structural options should be evaluated. The goal is not to find the universally best structure — there is none. It is to find the structure that best fits your product, your stage, and your strategy at this moment.
That structure will need to change. Build that expectation in from the start.