Time de Produto vs Time de Funcionalidades

Marty Cagan | 29 de Agosto, 2019 | Traduzido por Marcelo Knaka


Este artigo com certeza vai chatear algumas pessoas.


Me desculpe por isso, porém o grau de barulho e confusão a cerca do papel de produto em empresas de tecnologia apenas piora. Mais ainda, eu vejo que os comportamentos problemáticos estão se tornando institucionalizados em palestras de eventos, programas de treinamento e supostos programas de certificação para pessoas de produto.

No passado eu já conversei sobre esse problema várias vezes, mais especificamente no artigo Times de Produto Empoderados. Entretanto, muitas pessoas escutam apenas o que elas querem, e tem ficado claro para mim que eu preciso ser mais explícito.


Portanto, apesar deste artigo poder ser doloroso para ler, se você tem estado frustrado com a contradição e as mensagens confusas de pessoas no mundo de produto e persistir comigo aqui, eu tenho esperança que este artigo vai trazer uma clareza muito necessária.

No mundo de tecnologia, há três tipos distintos, falando de forma abrangente, de "times de produtos".


O mais comum em termos de números absolutos não são realmente equipes de produtos, mas equipes de entrega. Também chamadas de "equipe de desenvolvimento" ou "equipes de scrum" ou "equipes de engenharia" e, se sua empresa estiver executando algo como o SAFe, infelizmente este é você. Nessa situação, há alguns desenvolvedores e um Product Owner (dono do produto). O Product Owner neste modelo é o que eu chamo de "administrador do backlog". Alguém precisa fazer esse trabalho administrativo, mas tudo se resume à entrega de resultados e, na verdade, tem muito pouco a ver com o que me preocupa em termos da necessidade de inovação verdadeira e consistente em nome de nossos clientes. Eu escrevi em outro lugar sobre por que este modelo é realmente apenas um modelo cascata (waterfall) re-empacotado e não é usado em verdadeiras empresas de produtos de tecnologia. Então, vamos tirar isso da frente.


Este artigo é realmente sobre a diferença entre os outros dois tipos de times.


Agora, um aviso justo de que estou prestes a introduzir uma nomenclatura que não é padrão e certamente não foi acordada. Mas preciso fazer isso porque hoje, como indústria, nos referimos a ambos os outros tipos de equipes como "equipes de produto" ou "squads".


Mas, como você verá, embora pareçam semelhantes em um nível superficial, são dramaticamente diferentes, especialmente quando falamos sobre o papel do gerente de produto.


Quando eu escrevi sobre as virtudes de um time de produto empoderado, eu estava me referindo a o que eu vou continuar tratando aqui por Times de Produto. Eles são cross-funcionais (produto, design e engenharia); eles são focados e medidos por resultados (ao invés de entregas); e eles são empoderados o suficiente para descobrir o melhor caminho para resolver os problemas que foram entregues a eles.


O propósito do time de produto é resolver problemas de uma forma que os clientes amem, e ao mesmo tempo, funcionem para o nosso negócio.


Por mais que eu deseje o contrário, eu sei que apenas uma pequena porcentagem dos times por aí são realmente time de produtos como descrito acima.

Muito mais comum do que parece, os times não são empoderados de forma alguma. Pelo contrário, estão ali para servir ao negócio.


Neste artigo, vou me referir a este time de produto desfigurado por Time de Funcionalidades. Estou distorcendo um pouco a definição mais estabelecida de times de funcionalidades aqui, mas estou usando o termo porque ajuda a destacar que essas equipes tratam de entrega. Funcionalidades e, ocasionalmente, projetos. Normalmente tudo isso é fornecido à equipe na forma de uma lista priorizada chamada de roadmap.

Mas é aqui que preciso ir um pouco mais fundo.


Lembre-se que em produto há 4 riscos principais, são eles:

  • Risco de valor (As pessoas irão comprá-lo? Ou irão escolhê-lo?)

  • Risco de usabilidade (As pessoas saberão como usá-lo?)

  • Risco de viabilidade técnica (Conseguimos construir este produto com o tempo, habilidades e tecnologia que temos?)

  • Risco de viabilidade de negócio (Esta solução vai funcionar para as várias dimensões que nosso negócio tem?)

Em um time de produto empoderado, o gerente de produto é explicitamente responsável por garantir valor e viabilidade de negócio; o designer é responsável por garantir usabilidade; e o líder técnico é responsável por garantir a viabilidade técnica. O time faz isto através de uma colaboração verdadeira, de forma a descobrir a solução que melhor funcione para todos nós.


Quando eu falo e escrevo sobre quão difícil é ser um verdadeiro gerente de produto em um time de produto empoderado, é especificamente porque é muito difícil garantir valor ao usuário e viabilidade para o negócio. Se você pensa que é fácil fazer isso, por favor leia isto.


Entretanto, em um time de funcionalidades, você ainda (eu espero) tem um designer para garantir usabilidade, e você tem engenheiros para garantir viabilidade técnica, mas, e isto é importante entender: o valor e a viabilidade de negócio são de responsabilidade do stakeholder ou executivo que pediu a funcionalidade e a colocou no roadmap.


Se eles disserem que você precisa construir a funcionalidade X, então eles acreditam que a funcionalidade X vai entregar algum valor, e também acreditam que a funcionalidade X é algo que é viável ao negócio.


Vale a pena pontuar que mesmo que o stakeholder seja implicitamente responsável pelo valor entregue e pela viabilidade de negócio, eles ainda irão achar uma forma de culpar você e seu time se os resultados que esperavam não forem realizados. Demorou demais, o design era ruim, funções críticas foram cortadas do escopo para atingir a data esperada, e etc. E, claro, seu time desde o começo nunca ficou convencido de que valia a pena construir esta funcionalidade. É um caso antigo e eu já escrevi muito sobre esse problema.


Superficialmente, um time de funcionalidades e um time de produto empoderado são ambos squads. Sendo assim, eles parecem similares, mas as diferenças são profundas.

Vamos começar com o papel do gerente de produto. Em um time de produto empoderado, onde o gerente de produto precisa garantir valor e viabilidade, profundo conhecimento do cliente, dos dados, da indústria e especialmente do negócio (vendas, marketing, financeiro, suporte, jurídico, etc.) é absolutamente não negociável e essencial.


Já em times de funcionalidades, esse conhecimento é (no melhor cenário) disperso entre os stakeholders.


Em todo caso, é claro que as responsabilidades do gerente de produto neste modelos são diferentes do que em um time de funcionalidades.


O trabalho do gerente de produto em um time de funcionalidades é mais comumente descrito no formato de um facilitador, "pastoreando os gatos" de forma a garantir que a funcionalidade seja desenhada e entregue, ou uma forma nebulosa e fraca de líder cross-funcional que não é responsável por nada específico. Estes times de funcionalidades vão, frequentemente, pensar que estão fazendo descobertas de produto, mas na verdade é apenas design e talvez um pouco de teste de usabilidade.


Mas há outras consequências no papel do gerente de produto em um time de funcionalidades.


Pelo fato do time não ser empoderado - para ser claro, quando você está pensando na entrega você não está sendo empoderado de forma alguma - é muito difícil atrair e reter verdadeiros designers de produto (alguém habilidoso em design de serviço, design de interação, designe visual e pesquisa de usuário).


Na vasta maioria dos casos onde você tem times de funcionalidades, o designer (caso exista um) é um designer gráfico. Não estou dizendo que design gráfico ou visual não é importante, mas o que é relevante aqui é que há uma grande lacuna - no mínimo alguém precisa entender o design de interação e fazer pesquisa com usuário. Além disso, é muito comum neste modelo haver pressão sobre o gerente de produto para cumprir essa função.


Há consequências negativas adicionais nesta situação, uma vez que não só é difícil aprender as ferramentas que são usadas pelos designers, mas também é difícil aprender como fazer um bom design e uma boa pesquisa com o usuário. Infelizmente, muitos gerentes de produtos nunca tiveram a oportunidade de trabalhar com um verdadeiro profissional de design de produto, então eles não fazem ideia do que estão perdendo.


Se você tem sorte suficiente para ter um designer de produto de verdade no seu time (pelo menos até enquanto eles não migraram para uma outra empresas onde eles consigam utilizar suas habilidades por completo), eles normalmente (e corretamente) questionam qual é o propósito do gerente de produto, já que não é difícil para eles absorverem as responsabilidades dele em um time de funcionalidades, uma vez que já estão fazendo a maior parte do trabalho mesmo.


O resultado é que em times de funcionalidades, o papel do gerente de produto é na sua maioria um gerente de projeto, e parcialmente (e sem habilidade para) de designer.


Frequentemente há uma frustração semelhante com os engenheiros. O gerente de produto que é na prática um gerente de projetos, muitas vezes discorda da maneira como os engenheiros acreditam que eles precisam trabalhar. Sem mencionar que, neste modelo, os engenheiros são exilados na entrega e, como eu disse muitas vezes, se for esse o caso, estarão entregando apenas metade de seu valor real (novamente, os bons vão querer sair e se juntar a uma equipe de produtos capacitadas, onde eles possam realmente praticar seu ofício).


Apenas para fechar este ponto crítico, quando eu escrevo que gerentes de produtos precisam estar entre "os mais talentosos da empresa", e "o CEO deve olhar para os gerentes de produtos como potenciais futuros líderes da empresa" e "um bom gerente de produto é o CEO do produto", eu definitivamente não estou falando sobre o gerente de produto de um time de funcionalidades.


Eu espero que a esta altura você saiba se você está trabalhando com um modelo de times de funcionalidades ou times de produtos empoderados, mas eu aprendi que as pessoas são frequentemente relutantes para admitir quando elas estão em um modelo de time de funcionalidades.


Aqui estão alguns testes que você pode aplicar no seu time:

  • É entregue a você um roadmap com funcionalidades priorizadas e com datas, ou você foi direcionado a um problema para resolver com resultados do negócio?

  • Há alguma confusão entre o seu papel e o do designer?

  • Há alguma confusão entre o seu papel e o do Delivery Manager?

  • Você passa a maior parte do seu dia fazendo gestão de projeto?

  • Você tentou usar OKRs e foi uma bagunça, terminando ou por ser rejeitado ou acabou virando uma mistura entre resultados e entregas de funcionalidades?

  • Você tem um time de missionários ou mercenários?

  • Qual é o nível de responsabilidade (accountability)?

Apesar de times de funcionalidades e times de produtos serem parecidos olhando de longe, eles são muito diferentes, principalmente em como operam, no nível de empoderamento e no compromisso que o time tem, e especialmente nas responsabilidades que o gerente de produto tem.


Eu posso dizer pra você que com algumas exceções, os melhores times de produtos das melhores empresas são sempre o modelo de time de produto empoderado. Entretanto, admito que mesmo nas empresas que considero as melhores, nem todos os times de produto são empoderados. Na verdade, alguns são times de funcionalidades. Usualmente isso acontece porque a liderança ainda não confia naquele time. Algumas vezes a confiança precisa ser conquistada para formar um time empoderado. E outras vezes o problema está no líder que quer definir como a solução vai ser.


Eu nunca tentei esconder meu viés para times de produto verdadeiramente empoderados. Mas eu acredito que agora eu preciso ir além do que apenas advogar a favor de times empoderados, eu preciso alertar sobre times de funcionalidades, os problemas que eles causam e os péssimos resultados que eles entregam.


Incontáveis empresas hoje percebem a futilidade do modelo de equipe de delivery e sabem que precisam se transformar em uma verdadeira empresa de produtos movidos a tecnologia, mas pensam que podem "riscar esse item" fazendo as mudanças superficiais para passar para essas equipes de funcionalidades.


Ao encerrar aqui, quero enfatizar a diferença entre ser um gerente de produto de uma equipe de funcionalidades e uma equipe de produto empoderada. É um trabalho completamente diferente, exigindo um conjunto de habilidades muito diferente. Provavelmente não deveria ser o mesmo cargo.


É triste para mim que tantos designers e engenheiros nunca tenham sido expostos a um verdadeiro gerente de produto e nunca tenham sido capazes de trabalhar em uma equipe verdadeiramente capacitada. É por isso que argumento que há tantos talentos subutilizados por aí e continuo tentando persuadir as pessoas a tentarem trabalhar como as melhores empresas fazem.


Uma coisa que você pode fazer imediatamente é: da próxima vez que ler um artigo ou tweet relacionado a um produto, participar de uma palestra em uma conferência ou de algum treinamento de produto, considere se o autor, palestrante ou treinador está falando sobre o modelo de equipe de produto empoderado ou de equipe de funcionalidades?


ATUALIZAÇÃO: Eu postei um artigo respondendo muitas das perguntas que recebi sobre esta postagem.

Artigo originial: https://bit.ly/3uMBrtz