3/26/24, 6:56 PM
Article: Product vs Feature Teams : Silicon Valley Product Group
NEW - June SVPG Product Masterclass - Early Bird Registration Available Here
back to all articles
Product Culture
August 29, 2019
Marty Cagan
Product vs Feature Teams
This article is certain to upset many people.
I’m sorry for that, but the degree of ongoing noise and confusion surrounding the role of
product at tech companies is only getting worse. Moreover, I see the issues and
problematic behaviors getting institutionalized in conference talks, training programs
and so-called certification programs for product people.
I have talked about this issue several times in the past, most specifically in the article
and keynote on Empowered Product Teams. However, so many people hear only what
they want to in that, and it has become clear to me that I need to be more explicit.
So while this article might be painful to read, if you’ve 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.
Product Teams vs Delivery Teams
In the tech world, there are really three distinct types of, loosely speaking, “product
teams.”
https://www.svpg.com/product-vs-feature-teams/
1/9
3/26/24, 6:56 PM
Article: Product vs Feature Teams : Silicon Valley Product Group
The most common in terms of sheer numbers are not really product teams at all, they
are delivery teams. Also referred to as “dev teams” or “scrum teams” or “engineering
teams” and if your company is running something like SAFe, then unfortunately this is
you. In this situation, there are some number of developers, and a product owner. The
product owner in this model is what I refer to as a “backlog administrator.” Someone
does need to do this administrative work, but this is all about delivering output, and it’s
really very little to do with what I am concerned about in terms of the need for true,
consistent innovation on behalf of our customers. I’ve written elsewhere about why this
model is really just re-packaged waterfall, and is not used at true tech product
companies. So let’s get that out of the way.
This article is really about the difference between the other two types of teams.
Product Teams vs Feature Teams
Now fair warning that I am about to introduce some nomenclature that is non-standard
and certainly not agreed upon. But I need to do this because today as an industry we
refer to both of the other types of teams as “product teams” or “squads.” But as you’ll
see, while they look similar at a superficial level, they are dramatically different,
especially when we talk about the role of the product manager.
When I wrote about the virtues of empowered product teams, I was referring to what I’ll
continue to call here as product teams. Specifically, they are cross-functional (product,
design and engineering); they are focused on and measured by outcomes (rather than
output); and they are empowered to figure out the best way to solve the problems
they’ve been asked to solve.
The purpose of a product team in this sense is to solve problems in ways our customers
love, yet work for our business.
As much as I might wish otherwise, I know that only a small percentage of teams out
there are product teams in this sense.
Much more often than not, the teams are not empowered at all. In contrast, they are
there to serve the business.
https://www.svpg.com/product-vs-feature-teams/
2/9
3/26/24, 6:56 PM
Article: Product vs Feature Teams : Silicon Valley Product Group
In this article, I will refer to this third class of teams as feature teams. I am bending a
little bit the more established definition of feature teams here, but I am using the term
because it helps to highlight that these teams are all about output. Features, and
occasionally projects. Usually provided to the team in the form of a prioritized list that is
called the roadmap.
Empowered Product Managers vs Feature Team Product Managers
But here’s where I need to go deeper.
Recall that in product there are always four risks:
Value risk (will people buy it, or choose to use it?)
Usability risk (can users figure out how to use it?)
Feasibility risk (can we build it with the time, skills, and technology we have?)
Business Viability risk (will this solution work for the various dimensions of our business?)
In an empowered product team, the product manager is explicitly responsible for
ensuring value and viability; the designer is responsible for ensuring usability; and the
tech lead is responsible for ensuring feasibility. The team does this by truly
collaborating in an intense, give and take, in order to discover a solution that work for all
of us.
When I talk and write about how tough it is to be a true product manager of an
empowered product team, it’s precisely because it is so hard to ensure value and
viability. If you think it’s easy to do this, please read this.
However, in a feature team, you still (hopefully) have a designer to ensure usability, and
you have engineers to ensure feasibility, but, and this is critical to understand: the value
and business viability are the responsibility of the stakeholder or executive that
requested the feature on the roadmap.
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.
https://www.svpg.com/product-vs-feature-teams/
3/9
3/26/24, 6:56 PM
Article: Product vs Feature Teams : Silicon Valley Product Group
It’s 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 hopedfor results are not realized. It took too long, the design was bad, critical capabilities
were cut to make the date, etc. And of course your team was probably never convinced
this was worth building in the first place. It’s an old song and I’ve written extensively
about this problem.
Superficially, a feature team and a true empowered product team are both squads. So
they look similar, but the differences run deep.
Let’s start with the role of the product manager. 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.
Yet in a feature team, that knowledge is (at best) dispersed among the stakeholders.
In any case, hopefully it’s clear that the responsibilities of the product manager in this
model are very different for a feature team.
The job of the product manager on a feature team is most commonly described as a
form of facilitator, “herding the cats” in order to get the feature designed and delivered,
or some nebulous and weak form of cross-functional leader that’s not really responsible
for anything specific. These feature teams will often think they are doing product
discovery, but really it’s just design and maybe a little usability testing.
But there are other consequences of the feature team on the product manager role.
Because the team is not empowered – to be clear, when you’re given output to deliver
you are not empowered in any meaningful sense – it is very hard to attract and retain
true product designers (someone skilled at service design, interaction design, visual
design and user research).
In the vast majority of cases where you have feature teams, the designer (if there is one)
is a graphic designer. It’s not that graphic or visual design is not important, but what’s
relevant here is that now there’s a big gap – someone needs to figure out at least the
https://www.svpg.com/product-vs-feature-teams/
4/9
3/26/24, 6:56 PM
Article: Product vs Feature Teams : Silicon Valley Product Group
interaction design and hopefully do some user research. Hence it’s very common to
see pressure on the product manager in this model to try to fill these gaps.
There are additional negative consequences of this situation, as it’s not hard to learn the
tools that designers use, but it is hard to learn how to do good design and user
research. Sadly, many product managers have never had the opportunity to work with
a true, professional product designer, so they don’t even know what they’re missing.
If you are fortunate enough to have a true product designer on your team (at least until
they leave to move to a company where their skills are able to be fully utilized), then they
usually (and rightfully) question what the purpose of the product manager is, as it’s not
hard for them to pick up the additional responsibilities of the feature team product
manager as they’re doing the bulk of the work anyway.
The result is that in feature teams, the product manager role is mainly project manager,
and partly (unskilled) designer.
There is often a similar frustration with the engineers. The product manager that is
really a project manager is often at odds with the way the engineers believe they need
to be working. Not to mention that in this model, the engineers are relegated to delivery,
and as I’ve said many times, if that’s the case we’re only getting about half their real
value (so again, the good ones will want to leave and join an empowered product team
where they can truly practice their craft).
So just to close on this critical point, when I write that the product manager needs to “be
among the strongest talent in the company,” and “the CEO should view the product
managers as potential future leaders of the company,” and “the strong product manager
is the CEO of the product,” I am most definitely not talking about a product manager for
a feature team.
Product Team vs Feature Team Indicators
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’re in the feature team model.
So here are some tests you can apply to your team:
https://www.svpg.com/product-vs-feature-teams/
5/9
3/26/24, 6:56 PM
Article: Product vs Feature Teams : Silicon Valley Product Group
Are you provided roadmaps with prioritized features and dates, or are you assigned
problems to solve with business outcomes?
Is there role confusion between you and your designer?
Is there role confusion between you and your delivery manager?
Do you spend most of your day doing project management?
Did you try using OKR’s and was it a mess, either ending up being rejected, or some
contrived mashup of outcomes and features delivered?
Do you have a team of missionaries or mercenaries?
What is the level of accountability?
While product and feature teams look very similar on the surface, they are dramatically
different in how they operate, the level of empowerment and accountability, and
especially the responsibilities of the product manager.
I can tell you that with few exceptions, the best product teams at the best companies
are all about the empowered product team model. However, I will admit that even in
what I consider the best product companies, not every product team is empowered. In
truth, some are feature teams. Usually that’s because the leadership does not yet trust
that particular team. Sometimes that trust needs to first be earned. And sometimes the
issue is with the leader wanting to dictate solutions.
I have never tried to hide my strong bias toward truly empowered product teams. But I
believe I now need to go further than just advocating for empowered teams; I need to
call out feature teams, the problems they cause, and the poor results they deliver.
Countless companies today realize the futility of the delivery team model, and they
know they need to transform into a true, technology-powered product company, yet
they think they can “check that box” by making the superficial changes to move to these
feature teams.
As I close here, I want to emphasize the difference between being a product manager
for an empowered product vs feature team. It is a completely different job, requiring a
very different skill set. It probably should not even be same job title.
It is sad to me that so many designers and engineers have never been exposed to a
true product manager, and have never been able to work on a truly empowered team.
https://www.svpg.com/product-vs-feature-teams/
6/9
3/26/24, 6:56 PM
Article: Product vs Feature Teams : Silicon Valley Product Group
This is why I argue that there is so much underutilized talent out there, and why I
continue to try to persuade people to try working like the best companies do.
One thing you can do immediately is that the next time you read a product-related
article or tweet, attend a conference talk, or attend some product training, consider
whether the author, speaker or trainer is talking about the empowered product team
model, or the feature team model?
UPDATE: I have posted a follow-on article addressing many of the questions I have
received about this post.
Marty Cagan
Founder, Partner - Product at SVPG
Learn more by attending our next workshop.
share: 

 
featured content
Product Operating Model
February 27, 2024
Lea Hickman
Transformation Theater
By Lea Hickman and Marty Cagan Recently we’ve been writing
about two very common and very problematic forms of theater:...
article
https://www.svpg.com/product-vs-feature-teams/
read more
7/9