Autonomy vs. Ownership

Cagan extends his series on product team autonomy by examining how code ownership interacts with it. When companies split a codebase among product teams, one team's changes often touch code another team owns, creating friction. He contrasts a dependency model, where teams request changes from owners and wait in line, with an open-source-style model, where teams make changes themselves and owners review them via pull requests. The open-source approach preserves owner control while boosting speed, though it demands strong developer skill and doesn't suit highly specialized or sensitive code. Strategic conflicts between teams still require head-of-product judgment, and leaders should openly decide which code is open to contribution.

01Key takeaways

• Splitting a codebase by team creates autonomy but also cross-team dependencies that must be planned for.
• Strategic conflicts between teams need a holistic view and should be resolved by the head of product, not the code.
• An open-source-style pull request model lets teams move faster without stripping owners of control over their code.
• The open-source model requires high developer skill and is a poor fit for specialized or security-sensitive code.
• Decide and communicate explicitly which parts of the codebase are open for contribution and which are restricted.

02Key sections

Slicing the codebase

Companies moving to dedicated product teams typically divide code by team, such as driver, rider, and common services. Each team initially feels like a small startup with full control of its area.

Strategic conflicts across teams

A change that helps one team may hurt another's users or goals, such as dynamic pricing. Resolving this requires a holistic view of vision and KPIs, with the head of product making the call.

The dependency model

Teams request changes from the owning team and wait for it to be scheduled. This preserves ownership but can make the requesting team feel slow and not autonomous.

The open source model

Teams make the change themselves and submit it as a pull request for the owner to review and approve. This speeds delivery while the owner keeps control of its software.

Limits and transparency

The open-source model fails for specialized or sensitive code like payments or authentication, where dependency remains necessary. Leaders should be transparent about which areas are open to contribution and why.

03From the post

“A partnership dedicated to teaching best practices to product teams and product leaders”

04Frameworks mentioned

Summary and takeaways written by PM Atlas; quotes are short excerpts. © the original author.