The operating model that works at 20 people stops working as the organisation grows. This is not a failure of leadership or culture. It is physics. The communication pathways, decision-making structures, and coordination mechanisms that served you at startup scale become actively harmful at enterprise scale. The question is not whether to restructure, but how to restructure in a way that actually changes how decisions are made — not just who sits where.
The Pattern: Why Structure Breaks Down
At 20 people, trust is greater than process. Everyone knows what everyone else is doing. The founder or product leader can hold the full product vision in their head and communicate it directly to every team member. Decisions are fast because the decision-maker is in the room. Context transfer happens organically through proximity and frequency of interaction.
At 50 people, this model starts to strain. Communication pathways multiply. The founder can no longer be in every conversation. Teams begin to develop their own interpretations of the strategy, and those interpretations diverge. Coordination costs rise. What used to take a quick conversation now requires a meeting, and that meeting requires scheduling across multiple calendars.
Dunbar's Number and the Scale Threshold
At approximately 150 people, you hit Dunbar's number — the cognitive limit on the number of stable social relationships a person can maintain. Beyond this threshold, informal coordination mechanisms collapse entirely. People cannot maintain mental models of what every team is doing, who is responsible for what, or how their work connects to the broader strategy.
This is the point where organisations either implement deliberate structure or descend into chaos. There is no third option. The companies that resist structure because "we're not that corporate" inevitably develop informal power structures that are less visible, less accountable, and less effective than the formal ones they were trying to avoid.
The Established Business Problem
Most established businesses are organised by function. Engineering in one department, product in another, design in a third, QA in a fourth. Decisions require cross-functional meetings. Approval chains run through multiple managers. By the time a decision is made, the context that informed it has changed.
The common response is to reorganise into squads — cross-functional teams with a product manager, designers, and engineers. This is the right intuition but the wrong execution. Reorganising without changing how decisions are made gives you the same silos with new names. The squad has a Jira board and a stand-up, but the product manager still needs four approvals to ship anything. The engineering lead still reports to an engineering VP who has different priorities. The designer still sits in a design review cycle that adds weeks to every feature.
Speed at scale comes from structure, not pressure. Small autonomous units with full release authority, each owning a specific business outcome. This is not a new idea — it is Amazon's two-pizza teams, Spotify's squads, and Marty Cagan's empowered product teams. The principle is well-established. The execution is where most organisations fail.
The Structural Model That Works
The handbook contains the full implementation playbook. Here is the structure and the reasoning behind each element.
Step 1: Build Cross-Functional Product Trios
The fundamental unit of product development at scale is the product trio: a Product Manager, a Designer, and an Engineering Lead. These three people share responsibility for discovering the right thing to build, designing it well, and delivering it reliably. They are not representatives of their functional departments. They are a team with shared accountability for a specific outcome.
The trio model works because it brings the three critical perspectives — viability, desirability, and feasibility — into every decision at the point of decision-making. Instead of a product manager writing a spec, handing it to design, who hands it to engineering, who discovers that the spec is technically infeasible and sends it back — all three perspectives are present from the start.
Step 2: Assign Each Team a Specific Metric
Each trio-led team must own a specific business metric. Not a feature to build. Not a project to complete. A measurable business outcome to improve. The distinction matters enormously. A team that owns "build the new onboarding flow" will build the onboarding flow and declare victory. A team that owns "improve trial-to-paid conversion from 12% to 18%" will build, measure, iterate, and keep going until the metric moves.
The metric must be specific enough to be actionable and broad enough to allow the team discretion in how they achieve it. "Improve retention" is too vague. "Increase 30-day retention for enterprise users from 78% to 85%" is specific and actionable while giving the team space to determine the best approach.
Step 3: Grant Full Release Authority
This is where most organisations baulk, and it is where most restructurings fail. Full release authority means the team can ship to production without requiring approval from anyone outside the team. Not the VP of Engineering. Not the CPO. Not the CEO. The team owns the decision to release.
This requires guardrails, not anarchy. The team must meet defined quality standards (automated testing, code review, security checks). The team must operate within the strategic boundaries set by leadership (target customer segment, brand guidelines, regulatory requirements). But within those boundaries, the team decides what to build, how to build it, and when to ship it.
Without release authority, the team is not autonomous. They are a feature factory with a different name. If every release requires sign-off from a stakeholder who was not involved in the discovery process, you have not changed the structure. You have added a layer.
How AI Is Reshaping Team Composition
AI-assisted development is fundamentally changing the economics of product teams. The changes are already visible and accelerating.
The Ratio Shift
PM-to-engineer ratios are collapsing toward 1:1. Traditionally, one product manager might support 6–10 engineers. As AI tools handle more of the implementation and coordination work, engineers need less management overhead. The ratio is compressing because the nature of the work is changing.
This does not mean product managers are becoming less important. It means PMs who only coordinate — writing tickets, managing backlogs, running stand-ups — are being replaced by the tools themselves. PMs who discover — talking to customers, identifying problems worth solving, synthesising market signals into strategic direction — are more valuable than ever.
Step 4: Redesign Roles for the AI Era
The temptation is to cut PM headcount based on AI potential. Resist it. The correct response is to upskill, not cut. PMs who can leverage AI tools for research, prototyping, and data analysis are dramatically more productive than PMs without those skills. Engineers who can use AI coding assistants effectively ship faster than those who cannot.
The role redesign should focus on three areas:
- Shift PM time from coordination to discovery. If AI tools can write user stories, manage backlogs, and generate status updates, the PM should spend that reclaimed time talking to customers, analysing data, and developing strategic insight.
- Upskill engineers in AI-assisted development. Provide training, tools, and governance frameworks. Make AI tool usage a normal part of the engineering workflow, not a skunkworks experiment.
- Create new governance for AI-generated code. Code review processes, architectural standards, and quality gates need to account for AI-generated output. The speed benefit of AI coding is real, but so is the risk of accumulated architectural debt.
Step 5: Distribute Knowledge Deliberately
In a functional organisation, knowledge concentrates within departments. Engineers know the technical stack. Product knows the customer. Design knows the interaction patterns. The trio model requires cross-pollination of this knowledge. This does not happen automatically.
Deliberate knowledge distribution means structured practices: engineers participating in customer interviews, product managers attending architecture reviews, designers observing support calls. It means shared documentation that is actually maintained. It means regular cross-team sessions where teams share what they have learned — not what they have shipped, but what they have learned.
Step 6: Normalise AI Use with Clear Policy
AI tool usage should not be a grassroots experiment. It should be organisational policy with clear guidelines. Which tools are approved? What data can be shared with AI services? What review processes apply to AI-generated code? What are the expectations for AI literacy across different roles?
Without policy, you get inconsistency. Some teams use AI tools extensively. Others refuse to adopt them. The teams using AI tools ship faster but may be accumulating technical debt. The teams avoiding AI tools maintain quality but fall behind on velocity. Neither outcome is acceptable. Policy creates consistency.
Timeline and Sequencing
Realistic Timelines
- 3–6 months: First product trio established, operating with genuine autonomy and release authority. This is your proof of concept.
- 12–18 months: Model extended across the product organisation with adapted governance and knowledge-sharing practices in place.
The sequencing matters. Start with the trio model (Step 1). Assign metrics (Step 2). Grant release authority (Step 3). These three steps create the foundation. Role redesign (Step 4), knowledge distribution (Step 5), and AI policy (Step 6) build on that foundation. Attempting Step 4 without Steps 1–3 in place means you are redesigning roles within a structure that does not support the new role definitions.
Watch Out For
- Reorganising without changing decisions. If the new squads still need the same approvals, attend the same review meetings, and report through the same functional hierarchies, you have changed the org chart without changing the operating model. The symptom is easy to spot: teams complain that "nothing actually changed."
- Cutting PM headcount based on AI potential. AI tools augment product management; they do not replace it. The discovery, strategic thinking, and stakeholder navigation that define great PM work cannot be automated. Cutting headcount prematurely destroys organisational capability that takes years to rebuild.
- Assuming restructuring fixes culture. Structure enables culture change. It does not cause it. If the organisation's culture is one of blame, risk aversion, and political manoeuvring, a restructuring will reproduce those patterns in the new structure. Culture change requires deliberate, sustained effort alongside structural change.