Já recebi mais de uma vez a pergunta sobre “o que é produto?” e “qual é a granularidade de um produto?”.

Por exemplo, a funcionalidade de busca dentro do um produto, pode ser chamada de produto? E a funcionalidade de edição de texto da mensagem, pode ser chamada de produto? E a funcionalidade de cadastro de usuários, pode ser chamada de produto?

Resposta curta: não.

Todos esses exemplos são funcionalidades. O produto é algo que existe de forma independente. Uma funcionalidade não existe de forma independente. A cliente ou usuária não consegue adquirir e usar somente a funcionalidade, ela precisa do produto inteiro. Não tem como só usar a busca do Spotify, do Netflix, de um portal de imóveis ou de um site de notícias. Não dá para usar somente o editor de texto de mensagem do Gmail, ou da funcionalidade de postagem do Linkedin. Não dá para usar só o cadastro de usuários do Jira ou do Slack. Mesmo uma funcionalidade muito relevante, que pode ter nome próprio, como é o caso do Receba Fácil da Conta Azul, é uma funcionalidade do produto Conta Azul, pois não é possível só contratar e usar o Receba Fácil de forma independente, é preciso contratar o produto completo. Se algum dia o pessoal da Conta Azul decidir vender apenas o Receba Fácil, aí sim ele passa a ser um produto que poderá ser adquirido e usado independente do produto Conta Azul. Contudo, desde que foi concebido até hoje, o Receba Fácil é um funcionalidade dentro do Conta Azul.

Conversando com algumas pessoas sobre essa pergunta da granularidade, comecei a entender uma das possíveis razões que pode estar por trás dessa necessidade de chamar de produto pedaços de produto que claramente são funcionalidades. Essa razão é uma terminologia muito utilizado em gestão de produtos, a terminologia de time de funcionalidade, ou feature teams, em contraste com o que chamamos de times de produto, ou product teams.

Times de funcionalidades = times de projeto

Os times de funcionalidades são aqueles times em que:

O stakeholder define o que fazer. O time implementa o que foi pedido. Stakeholder normalmente é alguém da “área de negócios”, que pode ser de vendas, marketing, sucesso do cliente, suporte, financeiro, operações, uma liderança sênior (C-level) ou uma pessoa founder.

enquanto os times de produto são:

Times que recebe um problema para resolver e um resultado para gerar. O time tem total autonomia para decidir como resolver o problema e gerar o resultado, e é incentivado a fazer isso o mais rápido possível. Idealmente, o time também tem autonomia para definir qual problema resolver e que resultados gerar.

Essas definições vêm dessa tabela que preparei há algum tempo atrás com o objetivo de deixar bem claras as diferenças entre esses dois modos de desenvolver produto:

Essa tabela também ajuda a entender porque “negócios demanda => tecnologia implementa” não funciona.

A partir dessas definições começamos a entender que ninguém quer trabalhar em um time de funcionalidades. As pessoas querem trabalhar em times de produto, por isso que elas chamam a parte do produto que elas cuidam de produto, mesmo sendo claramente funcionalidades. As pessoas querem trabalhar em times de produtos, e não em times de funcionalidades. E aí entra a pergunta sobre a granularidade do produto, ou seja, se podemos chamar funcionalidades de produto.

Não, não podemos. Funcionalidades são funcionalidades, produtos são produtos. E o fato de trabalhar em uma funcionalidade não quer necessariamente dizer que o time trabalha no modo de trabalho de um time de funcionalidades.

Para ajudar a entender melhor a nomenclatura, pense que time de funcionalidades é um time de projeto, que trabalha naquilo que foi pedido, com escopo claramente definido, enquanto o time de produto é um time de resultado, de entrega de resultado tanto para a empresa que é dona do produto, quanto para a usuária que quer ter seu problema resolvido.

Preparei uma versão revisada da tabela acima para trazer essas diferenças de forma ainda mais explícita:

Essa nomenclatura (time de funcionalidade e time de produto) serve para explicar o modo de trabalho, não o tema do trabalho, mas consigo entender a confusão que ela pode causar. Não é porque a gente trabalha em funcionalidades, que a gente trabalha no modo de trabalho de um time de funcionalidades. Não devemos trabalhar como um time de projetos. Devemos sempre estar focados em gerar resultados, tanto para a empresa quanto para o cliente. Por isso, mesmo que trabalhemos em funcionalidades, devemos usar o modo de operação de um time de produto, ou um time empoderado de produto, ou um time de resultado, ou um time de entrega de resultado.

Essa nomenclatura poderia ser qualquer coisa:

• Time A e Time B, ou Time Z, ou qualquer outra letra…
• Time Azul e Time Vermelho, ou Time Amarelo, ou time qualquer outra cor…
• Tima Alfa e Time Beta, ou Time Gama, ou qualquer outra letra…
• Time Dinossauro e Time Gazela, ou Time Golfinho, ou qualquer outro animal…

Enfim, a nomenclatura é o de menos. O que importa é ter a clareza de que existem duas formas distintas e opostas de trabalho e, do ponto de vista de denvolvimento de produtos digitais, o modelo Time de Funcionalidade ou Time de Projeto pode até produzir algum resultado. Contudo, o modelo Time de Produto ou Time de Resultado é o que tem comprovada e sistematicamente gerado os melhores resultados e é o modo utilizado pelas melhores empresas de tecnologia.

Existe alguma situação em que o modo de operação de time de funcionalidade é o mais indicado? Pode fazer sentido utilizar esse modo de operação em desenvolvimento de projetos, mas não quando estamos desenvolvendo produtos. Já expliquei a diferença entre projeto e produto em um artigo anterior.

Como fazer um time mudar do modo de operação de time de funcionalidade para o modo de operação de um time de produto? Esse foi o tema de um outro artigo que escrevi há algum tempo atrás.

Resumindo

• Os termos “time de funcionalidade” e “time de produto” são termos bastante conhecidos da gestão de produtos. Apesar de eles falarem de funcionalidades e produto, eles servem para dar nome à forma de trabalho e não ao objeto de trabalho.
• Time de funcionalidade = time de projeto.
• Time de produto = time de entrega de resultado.
• Por outro lado, funcionalidades são funcionalidades, produtos são produtos. Produtos existem de forma independente e podem ser adquiridos pela cliente. Funcionalidades existem dentro do produto e não podem ser adquiridos e usadas de forma independente.
• Não é por que o nosso time desenvolve um funcionalidade de um produto que ele será um time de funcionalidade. O termo “time de funcionalidade” refere-se ao modo de trabalho. Podemos ter um time que trabalha em uma funcionalidade e opera no modo “time de produto”.

Treinamento e consultoria em gestão de produtos e transformação digital

Ajudo líderes de produto (CPOs, heads de produtos, CTOs, CEOs, tech founders, heads de transformação digital) a enfrentarem seus desafios e oportunidades de produtos digitais por meio de treinamentos e consultoria em gestão de produtos e transformação digital.

Newsletter

Escrevo reguIarmente sobre gestão de produtos, desenvolvimento de produtos, liderança de produtos digitais e transformação digital. Vc pode receber uma notificação por email sempre que eu publicar algo novo, sem depender dos algoritmos de notificação de redes sociais. Basta assinar minha newsletter.

Gestão de produtos digitais

Você trabalha com produtos digitais? Quer saber mais sobre como gerenciar um produto digital para aumentar suas chances de sucesso, resolver os problemas do usuário e atingir os objetivos da empresa? Confira meu pacote de gerenciamento de produto digital com meus 3 livros, onde compartilho o que aprendi durante meus mais de 30 anos de experiência na criação e gerenciamento de produtos digitais. Se preferir, pode comprar os livros individualmente:

• Liderança de produtos digitais: A ciência e a arte da gestão de times de produto.
• Gestão de produtos: Como aumentar as chances de sucesso do seu software.
• Guia da Startup: Como startups e empresas estabelecidas podem criar produtos de software rentáveis.