I have already received the question more than once about “What is a product?” and “What is the granularity of a product?”.

For example, can the search feature within a product be called a product? And the message text editing feature, can it be called a product? And the user registration feature, can it be called a product?

Short answer: no.

All of these examples are features. The product is something that exists independently. A feature does not exist independently. The client or user cannot acquire and use only the feature, she needs the entire product. There’s no way to use just the search on Spotify, Netflix, a real estate portal, or a news site. You can’t just use Gmail’s message text editor or Linkedin’s posting text editor feature. You can’t just use Jira or Slack user registration. Even a very relevant feature, which may have its own name, as is the case of the Receba Fácil (this feature name translates into something like Easy Collect) from Conta Azul, a Brazilian ERP for small businesses, is a feature of the Conta Azul product, as it is not possible to use it independently, it is necessary to become a customer of the complete product. If one day the Conta Azul team decides to offer only Receba Fácil, then it becomes a product that can be purchased and used independently of the Conta Azul product. However, since it was conceived, Receba Fácil is a feature within Conta Azul.

Talking to some people about this granularity question, I started to realize one of the possible reasons that could be behind this need to call parts of a product that are clearly features of this product as “product”. That reason is a terminology often used in product management, the “feature team” terminology in contrast to what we call “product team”.

Feature team = project team

Feature teams are those where:

Stakeholder decides what to do. Team implements what is asked. Stakeholder is normally someone from the so-called “business area”, which can be someone from sales, marketing, client success, customer support, finance, operations, a C-level, or a founder.

while in product teams:

Team is given a problem to solve and an outcome to achieve. The team has complete autonomy to decide how to solve the problem and achieve the outcome and is incentivized to do so as fast as possible. Ideally, the team has also autonomy to define what problem to solve and outcome to achieve.

These definitions differences come from the table that I prepared some time ago with the objective of make it very clear the differences between these two models of product development:

This table also helps explain why “business demands => technology implements” doesn’t work.

From these definitions, we begin to understand that nobody wants to work in a feature team. People want to work on product teams, that’s why they call the part of the product they care about a product, even though they are clearly features. People want to work in product teams, not in feature teams. And then comes the question about the granularity of the product, that is, if we can call “features” the product features.

No, we can not. Features are features, products are products. And the fact of working on a feature doesn’t necessarily mean that the team works in a feature team’s way of working.

To help better understand the nomenclature, consider that the feature team is a project team, which works on what was requested, with a clearly defined scope, while the product team is a result team, delivering results both for the company who owns the product and for the user who wants to have her problem solved.

I’ve prepared a revised version of the table above to bring these differences even more explicitly:

This nomenclature (feature team and product team) explains the way of working, not the subject of the work, but I can understand the confusion it can cause. It’s not because we work on features that we work in a feature team’s way of working. We should not work as a project team. We must always be focused on generating results, both for the company and for the client. Therefore, even if we work on features, we must use the operating mode of a product team, or an empowered product team, or a result team, or a result delivery team.

This nomenclature could be anything:

• Team A and Team B, or Team Z, or any other letter…
• Team Blue and Team Red, or Team Yellow, or team any other color…
• Time Alpha and Time Beta, or Time Gamma, or any other letter…
• Team Dinosaur and Team Gazelle, or Team Dolphin, or any other animal…

Anyway, the nomenclature is the minus. What matters is to be clear that there are two distinct and opposite ways of working and, from the point of view of digital product development, the Feature Team or Project Team operating model can even produce some result. However, the Product Team or Result Team model is the one that has been proven to systematically generate the best results and is the way used by the best technology companies.

Is there a situation in which the feature team mode of operation is the most appropriate? It might make sense to use this mode of operation in project development, but not when we are developing products. I already explained the difference between project and product in a previous article.

How to make a team switch from the feature team operating model to the product team operating model? This was the subject of another article I wrote some time ago.

Summing up

• The terms “feature team” and “product team” are well-known terms in product management. Although they talk about features and products, they serve to name the way of working and not the object of work.
• Feature team = project team.
• Product team = result delivery team.
• On the other hand, features are features, products are products. Products exist independently and can be purchased by the customer. Features exist within the product and cannot be purchased and used independently.
• It’s not because our team develops a feature of a product that it will be a feature team. The term “feature team” refers to the way the team works. We can have a team that works on a feature and operates in “product team” mode.

Workshops, coaching, and advisory services

I’ve been helping companies and their leaders (CPOs, heads of product, CTOs, CEOs, tech founders, and heads of digital transformation) bridge the gap between business and technology through workshops, coaching, and advisory services on product management and digital transformation.

Newsletter

I write regularly about product management, product development, digital product leadership, and digital transformation. You can receive a notification whenever I publish a new article without depending on any social network algorithms to notify you! Just subscribe to my newsletter.

Digital Product Management Books

Do you work with digital products? Do you want to know more about managing a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books, where I share what I learned during my 30+ years of experience in creating and managing digital products:

• Startup Guide: How startups and established companies can create profitable digital products
• Product Management: How to increase the chances of success of your digital product
• Leading Product Development: The art and science of managing product teams

You can also acquire the books individually by clicking on their titles above.