By Marty Cagan · svpg.com · LinkedIn
Marty Cagan argues that splitting product work across teams is one of the hardest and most recurring organizational questions once a company outgrows its earliest stage, and that there is no quick general answer. He lists five factors he weighs when recommending a structure, ranked roughly by priority: clear ownership, alignment with users, alignment with the development team, alignment with the software architecture, and alignment with business units. He notes that business units are often the highest-weighted factor in practice, which he considers a mistake. The piece stresses that structure is a moving target to revisit about yearly, that platform or common-services teams need strong technical product leaders, and that every structure involves trade-offs.
01Key takeaways
- Prioritize giving each product team something significant it can truly own and be accountable for.
- Structure product teams around actual users and customers rather than internal functions or revenue streams.
- Work with engineering to find alignment instead of letting the product structure be dictated by engineering teams.
- Treat software architecture as a constraint to evolve, not as the thing that drives product decisions.
- Staff common platform or core services teams with strong technical product leaders, since they have high leverage and high difficulty.
- Revisit your product organization structure roughly every year, accepting that no structure is perfect.
02Key sections
- Why team structure is hard
- Splitting product work becomes a persistent challenge as soon as there is more than one product manager or designer. Cagan avoids quick answers because many factors must be weighed together.
- Five prioritized factors
- The core list runs from clear ownership and user alignment down to engineering, architecture, and business units. Cagan admits he sometimes adjusts the ranking based on company culture.
- Balancing engineering and architecture
- Teams should work with engineering rather than building structure around it, and architecture should enable the product without driving it. Evolving old architectures can be a major undertaking.
- Business units and user alignment
- Product structures often mirror business units or revenue streams, which the author sees as a mistake. When alignment conflicts, he advises aligning first to users, then technology, then business units.
- Ongoing notes and trade-offs
- Revisit structure about yearly, staff shared platform teams with strong technical leaders, and accept that every structure optimizes some goals at the expense of others.
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.