In the tech world, there are really three distinct types of, loosely speaking, “product teams.”
Origen: Product vs. Feature Teams | Silicon Valley Product Group
…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.
The most common in terms of sheer numbers are not really product teams at all, they are delivery teams.
The product owner in this model is what I refer to as a “backlog administrator.” 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. Now fair warning that I am about to introduce some nomenclature that is non-standard and certainly not agreed upon. … 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.
Much more often than not, the teams are not empowered at all. In contrast, they are there to serve the business. In this article, I will refer to this third class of teams as feature teams. …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. 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.
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.
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. 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 hoped-for results are not realized.
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.
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.
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).
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. …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 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.
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:
- 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?
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.