Product Versus Feature Teams

I thought this was a good read from Marty Cagan: https://svpg.com/product-vs-feature-teams/

TLDR;

  • feature teams just facilitate the delivery of features requested by stakeholders; they’re not really doing product discovery – just design and maybe some user testing
  • empowered product teams have a product manager that is responsible for addressing two of the primary risks in relation to product development: Value Risk (will people buy or use the product?) and Business Viability Risk (will this solution work for the various dimensions of our business?)
  • (designers are responsible for usability risk and engineers are responsible for feasibility risk)
  • “In an empowered product team… deep knowledge of the customer, the data, the industry & especially your business (sales, finance, support, legal etc) is absolutely non-negotiable and essential. Yet in a feature team, that knowledge is dispersed among the stakeholders.

This triggered a few thoughts for me:

  1. Assuming one agrees with Cagan’s analysis in the first place (I’d be interested to hear folks views on that), I feel I work on an empowered product team. That is to say, the business is supportive of our steering the product ship and does not hand down directives, as a general rule.
  2. However, coming from a background that checks some but not all of the absolutely non-negotiable and essential boxes {the customer, check; the industry, check; the data, partial-check; the business, somewhat un-checked} – I’m conscious that if I’m not strong in all of these areas (arguably impossible), I’m at risk of working on a feature team rather than a product team, per Cagan’s definition, since knowledge is instead dispersed across the stakeholders.
  3. Finally and most personally, assuming there are gaps to be filled (primarily knowledge of other business areas) – what’s the best way of plugging these, particularly when working 100% remotely?
Thanks for reading. Feel free to reach out via a comment or on the socials if anything resonates.

Cheers,
Simon

One Comment

  • Unfortunately that article is based on a misinterpretation of Feature Teams. Authoritative sources include 1995’s Dynamics of Software Development by Jim McCarthy describing Feature Teams at Microsoft: https://www.amazon.com/Dynamics-Software-Development-Jim-McCarthy/dp/1556158238 and the Feature Team Primer by Craig Larman and Bas Vodde: https://www.featureteams.org
    In short, Feature Teams are essentially what Cagan describes as a “Product Team” but without the risk of a “small product definition” that the implicit 1-to-1 product to team relationship may lead to.

    There’s a huge amount of misinterpretation of “Product Owner” out there today including many who are no more than Team Output Owners serving internal stakeholders as Cagan rightly points out as a dysfunction. Here’s a video from Michael James that addresses that. ‘Why “Scrum” Isn’t Making Your Organization Agile: Harmful Misconceptions About Product Owner Role’: https://www.youtube.com/watch?v=cr2rjaGmUzo&t=2s

    I hope that clears up a couple of common misconceptions. It would be a shame for someone as prominent as Marty Cagan to propagate these myths further.

Leave a Reply