Product vs. Project Teams

Marty Cagan revisits the distinction between product teams and project teams, which he says he should have written about sooner, after hoping the problem had faded. A product team is durable and owns an outcome over one to two years or more, while a project team exists only for one initiative and then disperses engineers back into a pool. Cagan argues the supposed efficiency of 'fully utilized' pooled staff is a myth, since non-trivial products require months of ramp-up and trust that project teams never build. He traces the persistence of project teams to IT's treatment of technology as a cost center and to project-based funding, which encourages waste and leaves companies vulnerable to disruption. He also notes that startups can drift into the same pattern as they scale.

01Key takeaways

• Organize around durable product teams that own outcomes for at least a year or two, not around one-off projects.
• Pooled, reassign-as-needed staffing hurts velocity because engineers, designers and PMs need months to ramp up on complex products.
• Project-based funding and business cases often reward delivering output rather than achieving results, so funding models need to change too.
• Transforming to product teams requires changes in finance and stakeholder relationships, not just in product and technology practices.
• Watch for project-team drift as a startup scales; preserve the empowerment and stable teams that drove early success.

02Key sections

The core distinction

Feature teams differ from product teams in empowerment, while project teams differ in ownership. Project teams deliver output and then move on, whereas product teams stay together to own results.

The pool model myth

Pooling engineers to maximize utilization looks efficient on paper, but learning a codebase, architecture and domain takes months, so constant reassignment destroys velocity and innovation.

Symptoms of project teams

Mercenary staffing, slow velocity, little innovation, growing technical debt, no ownership of results, and orphaned projects are the telltale signs.

Why companies still use them

Project teams are rooted in IT's cost-center culture and project-based funding, reinforced by CFO and CIO incentives that reward looking fiscally responsible or serving stakeholders rather than outcomes.

Startups are not immune

Fast-growing startups can lose their empowered culture when they scale by staffing project and feature teams instead of extending the autonomy that made them successful early on.

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.