Cross-Functional Product Teams

The Squad Model

The cross-functional product team, often called a "squad," is the dominant organizing pattern in modern software companies. The core idea is simple: give a small team everything it needs to own a product area end-to-end. No waiting on other teams to design, build, test, or deploy. No handoffs across organizational lines.

A typical squad has a product manager who sets direction, a designer who handles UX research and interface design, 4-6 engineers who build and operate the software, and QA capacity that ensures quality. Some companies embed QA as a full-time squad member. Others have QA engineers who rotate across squads or provide testing frameworks that engineers use directly.

The key constraint is cognitive load. A squad should own a domain small enough that every member can hold a working mental model of the whole thing. When engineers start saying "I don't know how that part works, ask Sarah," the domain is too big for one team.

Ownership Charters

Every product team should have a written ownership charter. This doesn't need to be a long document. One page is enough. It covers:

• What the team owns: Services, features, data domains, and SLOs
• What the team does not own: Explicit boundaries prevent scope creep
• How other teams interact with them: API contracts, request processes, SLA for responding to asks
• On-call responsibilities: Which services this team pages for

Review charters quarterly. As the product evolves, ownership boundaries shift. Outdated charters create confusion about who's responsible when something breaks.

Handling Shared Services

Payments, authentication, notifications, and email are the usual suspects. These services are used by every product team but owned by one. There are a few models:

Dedicated shared-service team owns the service, maintains its own roadmap, and accepts requests from other teams through a formal intake process. This is clean but slow. Consumer teams wait in a queue.

Inner-source model lets any team contribute to the shared service under the guidance of a core maintainer group. This is faster but requires strong code review standards and architectural guardrails. Stripe uses this model for many internal libraries.

Platform team model (from Team Topologies) treats shared services as internal products with self-service APIs. Consumer teams don't need to file requests. They use the API. The platform team invests in documentation, developer experience, and reliability.

When to Split a Team

Three signals tell you it's time:

1. Sprint planning takes forever because the team juggles too many unrelated priorities
2. Engineers specialize into sub-groups that rarely interact ("the search folks" and "the recommendations folks" on the same team)
3. Team size exceeds 8-9 and communication overhead grows faster than output

When you split, do it along product domain lines, not technical layers. Each new team should be able to ship independently from day one. If they can't, you've drawn the boundary in the wrong place.