SVPG · Free post · Org design & culture · Product strategy & vision

Product vs Feature Teams

Marty CaganAug 29, 20199 min
SourceSVPG
KindFree post
PublishedAug 29, 2019
Originalsvpg.com ↗
N:

Cagan argues that much of the confusion about product management comes from lumping together two very different team types that both get called 'product teams.' He distinguishes delivery teams (essentially re-packaged waterfall), feature teams (output-focused squads that receive a prioritized roadmap), and empowered product teams (cross-functional and outcome-driven). The core distinction is who owns the four product risks: in empowered teams the product manager owns value and viability, while in feature teams that responsibility sits with the stakeholder who requested the feature. He contends the feature-team model degrades the PM role into project management and weakens design and engineering, and he offers diagnostic questions for readers to identify which model they work in.

01Key takeaways

  • Distinguish delivery teams, feature teams, and empowered product teams before judging whether a product role is being done well.
  • In empowered teams, the product manager must own value and viability, which requires deep knowledge of customers, data, and the business.
  • Feature teams shift value and viability ownership to stakeholders who requested features, yet teams still get blamed when outcomes miss.
  • Feature-team PMs tend to drift into project management and fill design gaps, so ask whether your role has become administrative.
  • Check whether you receive roadmaps of features and dates or problems with business outcomes to know which model you operate in.
  • When reading product advice, ask whether the author is describing empowered product teams or feature teams.

02Key sections

Delivery teams are not product teams
The most common setup, often seen under SAFe, pairs developers with a product owner who mainly administers the backlog and delivers output. Cagan sets this aside as outside the scope of real product innovation.
Feature teams versus empowered product teams
Empowered teams are cross-functional and measured by outcomes, while feature teams are handed roadmaps of features and projects. Cagan admits his nomenclature is non-standard but uses it to highlight the difference in output versus outcomes.
Who owns the four risks
In empowered teams the PM owns value and viability, the designer owns usability, and the tech lead owns feasibility. In feature teams the stakeholder implicitly owns value and viability, yet still blames the team when results disappoint.
How feature teams degrade the PM, designer, and engineer roles
The PM becomes a facilitator or project manager, designers are often only graphic designers, and engineers are relegated to delivery, causing talented people to leave for empowered teams.
Diagnostic tests for your team
Cagan lists questions such as whether you receive prioritized feature roadmaps, whether your role overlaps with the designer's, and whether you spend most of your day on project management, to help identify the model you are in.

03From the post

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

“the value and business viability are the responsibility of the stakeholder or executive that requested the feature on the roadmap.”Marty Cagan · SVPG
“The purpose of a product team in this sense is to solve problems in ways our customers love, yet work for our business.”Marty Cagan · SVPG
“It is a completely different job, requiring a very different skill set. It probably should not even be same job title.”Marty Cagan · SVPG

04Frameworks mentioned

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