\u2026while this article might be painful to read, if you\u2019ve been frustrated with the contradictory and confusing messaging from people in the product world, if you bear with me here, I am hopeful that this will provide some much needed clarity.<\/p>\n
![\"\"](\"http:\/\/silta.es\/juantatay\/wp-content\/uploads\/2020\/08\/EMPOWERED-Cover-3D-743x1024-400x551.png\")
<\/p>\n
The most common in terms of sheer numbers are not really product teams at all, they are delivery teams<\/em><\/strong>. <\/p>\n This article is really about the difference between the other two types of teams.\u00a0Now fair warning that I am about to introduce some nomenclature that is non-standard and certainly not agreed upon.\u00a0 \u2026 while they look similar at a superficial level, they are dramatically different, especially when we talk about the role of the product manager.<\/p>\n When I wrote about the virtues of empowered product teams<\/strong>, I was referring to what I\u2019ll continue to call here as product teams<\/em><\/strong>.\u00a0 Specifically, The purpose of a product team<\/em> in this sense is to solve problems in ways our customers love, yet work for our business<\/em>.<\/strong><\/p>\n <\/p>\n Recall that in product there are always four risks:<\/p>\n In an empowered product team, When I talk<\/strong> and write about how tough it is to be a true product manager of an empowered product team<\/strong>, it\u2019s precisely because it is so hard to ensure value and viability.<\/strong><\/p>\n However, in a feature team,<\/strong> you still (hopefully) have a designer to ensure usability<\/strong>, and you have engineers to ensure feasibility,<\/strong> but, and this is critical to understand: the value and business viability are the responsibility of the stakeholder or executive that requested the feature<\/em> on the roadmap<\/em>.<\/strong><\/p>\n If they say they need you to build feature x, then they believe feature x will deliver some amount of value, and they believe that feature x is something that is viable for the business.\u00a0It\u2019s worth pointing out that even though the stakeholder is the one implicitly responsible for value and viability, they will still find a way to blame you and your team if their hoped-for results are not realized.<\/p>\n Superficially, a feature team and a true empowered product team are both squads.\u00a0 So they look similar, but the differences run deep.<\/p>\n Let\u2019s start with the role of the product manager.\u00a0 In an empowered product team, where the product manager needs to ensure value and viability, deep knowledge of the customer, the data, the industry and especially your business (sales, marketing, finance, support, legal, etc.) is absolutely non-negotiable and essential.<\/strong><\/p>\n Yet in a feature team, that knowledge is (at best) dispersed among the stakeholders.<\/strong><\/p>\n The job of the product manager on a feature team is most commonly described as a form of facilitator, \u201cherding the cats\u201d in order to get the feature designed and delivered,<\/strong> or some nebulous and weak form of cross-functional leader that\u2019s not really responsible for anything specific.\u00a0 These feature teams will often think they are doing product discovery, but really it\u2019s just design and maybe a little usability testing. There is often a similar frustration with the engineers.\u00a0 \u2026in this model, the engineers are relegated to delivery, and as I\u2019ve said many times, if that\u2019s the case we\u2019re only getting about half their real value.<\/strong><\/p>\n <\/p>\n So just to close on this critical point, when I write that the product manager needs to \u201cbe among the strongest talent in the company,\u201d and \u201cthe CEO should view the product managers as potential future leaders of the company,\u201d <\/strong>and \u201cthe strong product manager is the CEO of the product,\u201d I am most definitely not<\/em> talking about a product manager for a feature team.<\/strong><\/p>\n <\/p>\n Hopefully at this point you know if you are working in a feature team model or an empowered product team model, but I have learned that people are often very reluctant to admit when they\u2019re in the feature team model.\u00a0So here are some tests you can apply to your team:<\/p>\n <\/p>\n I can tell you that with few exceptions, the best product teams at the best companies are all about the empowered product team model.\u00a0 However, I will admit that even in what I consider the best product companies, not every product team is empowered.\u00a0 In truth, some are feature teams.\u00a0 Usually that\u2019s because the leadership does not yet trust that particular team. \u00a0Sometimes that trust needs to first be earned.\u00a0 And sometimes the issue is with the leader wanting to dictate solutions.<\/p>\n","protected":false},"excerpt":{"rendered":" In the tech world, there are really three distinct types of, loosely speaking, \u201cproduct teams.\u201d Origen: Product vs. Feature Teams | Silicon Valley Product Group \u2026while this article might be painful to read, if you\u2019ve been frustrated with the contradictory and confusing messaging from people in the product world, if you bear with me here, […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[43,28,220,50,53,26,29,184,179,1,180],"tags":[297,209,301],"class_list":["post-4370","post","type-post","status-publish","format-standard","hentry","category-coaching","category-cosillas-empresariales","category-design","category-diseno","category-eficiencia","category-el-critico-como-artista","category-gestion","category-product-management","category-project-management","category-sin-categoria","category-team","tag-management","tag-product-m","tag-project-m"],"jetpack_featured_media_url":"","jetpack-related-posts":[],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/silta.es\/juantatay\/wp-json\/wp\/v2\/posts\/4370","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/silta.es\/juantatay\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/silta.es\/juantatay\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/silta.es\/juantatay\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/silta.es\/juantatay\/wp-json\/wp\/v2\/comments?post=4370"}],"version-history":[{"count":4,"href":"https:\/\/silta.es\/juantatay\/wp-json\/wp\/v2\/posts\/4370\/revisions"}],"predecessor-version":[{"id":4375,"href":"https:\/\/silta.es\/juantatay\/wp-json\/wp\/v2\/posts\/4370\/revisions\/4375"}],"wp:attachment":[{"href":"https:\/\/silta.es\/juantatay\/wp-json\/wp\/v2\/media?parent=4370"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/silta.es\/juantatay\/wp-json\/wp\/v2\/categories?post=4370"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/silta.es\/juantatay\/wp-json\/wp\/v2\/tags?post=4370"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\nThe product owner in this model is what I refer to as a \u201cbacklog administrator.\u201d \u00a0I\u2019ve written elsewhere about why this model is really just re-packaged waterfall, and is not used at true tech product companies.\u00a0 So let\u2019s get that out of the way.<\/p>\n
\nthey are cross-functional<\/em> (product, design and engineering);
\nthey are focused on and measured by outcomes<\/em> (rather than output); and
\nthey are empowered<\/em> to figure out the best way to solve the problems they\u2019ve been asked to solve.<\/p>\n
\n<\/strong>Much more often than not, the teams are not empowered at all.\u00a0 In contrast, they are there to serve the business<\/em>.<\/strong>\u00a0In this article, I will refer to this third class of teams as feature teams<\/em><\/strong>.\u00a0 \u2026these teams are all about output.\u00a0 Features, and occasionally projects.<\/strong>\u00a0 Usually provided to the team in the form of a prioritized list that is called the roadmap.<\/strong>\u00a0But here\u2019s where I need to go deeper.<\/p>\n\n
\nthe product manager is explicitly responsible for ensuring value<\/em> and viability<\/em>;
\nthe designer is responsible for ensuring usability<\/em>; and
\nthe tech lead is responsible for ensuring feasibility<\/em>.<\/strong><\/p>\n
\nBecause the team is not empowered \u2013 to be clear, when you\u2019re given output to deliver you are not<\/em> empowered in any meaningful sense \u2013 it is very hard to attract and retain true product designers (someone skilled at service design, interaction design, visual design and user research).
\n<\/strong>The result is that in feature teams, the product manager role is mainly project manager, and partly (unskilled) designer.<\/p>\n\n