Durable product teams

As product and engineering organisations grow, leaders face the challenge of structuring teams to manage increasing complexity.

Recently, I came across Marty Cagan’s work, and his argument for durable product teams caught my attention.

While his writing primarily focuses on product management, I believe the same principles have a significant impact on engineering performance.

Project teams vs. product teams

The idea behind durable product teams is that a cross-functional squad is formed around a problem space rather than a single project.

Unlike project teams, which are dissolved once delivery is complete, durable product teams persist over time. They continue working within the same domain.

Here are 3 ways I see durable product team formations impact engineering function.

Domain expertise

Working on multiple projects within the same domain naturally develops domain knowledge.

Engineers gain a deeper understanding of the business context, stakeholder needs, and the problems they’re solving.

This enables them to design better software solutions and take a more active role in the early stages of the software development lifecycle.

Additionally, a deeper understanding of domain expertise facilitates the application of the domain-driven design paradigm.

Business metrics

Business domains usually have domain-specific performance metrics.

For example, in a lending domain, application intake might be measured by metrics such as cycle time or completion rate.

When engineers jump between projects in different domains, the metrics constantly shift, making it harder to see how their work drives outcomes.

Durable teams work with consistent business metrics over time.

That clarity helps engineers connect their work to business impact and fosters stronger ownership of results.

Codebase quality

It’s challenging to write maintainable code in an unfamiliar codebase.

Engineers in durable teams working on the same codebase over time build intimate knowledge of the codebase.

This makes it easier to identify refactoring opportunities and integrate those changes into ongoing development.

When engineers work on a part of the codebase only for the duration of the project, it’s hard for them to prioritise long-term investment and refactoring.

Durable product teams are not a silver bullet.

Project-based structures still offer benefits, such as providing engineers with broader exposure to different codebases and various parts of the organisation.

That said, forming a durable product team can have a positive impact on engineering performance, so it may be worth considering this approach.