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.

In the tech world, there are really three distinct types of, loosely speaking, “product teams.”

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.

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.

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.

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.

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. 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 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.

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?

While feature teams and product 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 a feature team versus an empowered product 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. 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.