Time de Produto vs Time de Feature - Vida de Produto
Por Henrique Carvalho 26/09/2019 15 mins read
Este artigo vai irrita-los (sinto muito por isso), mas o grau de ruído e confusão em torno do papel do "produto" nas empresas de tecnologia está apenas piorando. Tenho visto esses problemas e comportamentos problemáticos se institucionalizando em palestras, programas de treinamento e certificações para pessoas de que trabalham com produto. Você deve estar se perguntado "Qual é a confusão que esta acarretando tanto problema?". Indo direto ao ponto: é a diferença entre time de produto vs time de feature.
Já falei sobre essa diferença várias vezes no passado, especificamente no post sobre como empoderar seu time de produto, no entanto, muitas pessoas (muitas delas com grande autoridade no mercado) ouvem apenas o que querem, e ficou claro para mim que eu preciso ser mais explícito.
Portanto, embora este artigo possa ser doloroso de ler, se você ficou frustrado com as mensagens contraditórias e confusas de pessoas no mundo dos produtos, se você concorda comigo aqui, espero que isso forneça alguma clareza necessária.
A diferença entre time de produto e time de feature
1. 'Time de entrega' ("Times de engenharia' / 'Times de dev')
2. Time de feature
3. Times de produto empoderado
Diferenças entre um time de feature e um time de produtos
• Papel do gerente de produto
• Designer de produto (e como rete-los)
• Frustação dos engenheiros
Como saber qual é o tipo do meu time de produtos?
Antes de prosseguirmos, um lembrete importante para as próximas seções – os quatro riscos do produto:
Risco de valor (Value risk) :as pessoas vão comprá-lo ou optar por usá-lo?
Risco de usabilidade (Usability risk) :os usuários podem descobrir como usá-lo?
Risco de viabilidade técnica (Feasibility risk) :podemos construí-lo com o tempo, as habilidades e a tecnologia que temos?
Risco de viabilidade do negocio. (Business Viability risk) :esta solução funcionará para as várias dimensões de nossos negócios?
Esses riscos, precisam estar alinhados constantemente pelo time de produto e em suas entregas. Mas no no mundo da tecnologia, existem realmente três tipos distintos de "time de produtos". Vamos descobrir o que são e como eles lidam com esses riscos e desafios
O mais comum em termos de números absolutos não são realmente times de produtos, são times de entrega. Também chamadas de "times de desenvolvimento" ou "times do scrum" ou "equipe de engenharia" e, se sua empresa está executando algo como o SAFe, infelizmente esse é você.
Nessa situação, há um número x de desenvolvedores e um dono do produto (PO). O dono do produto nesse modelo é o que me refiro como um "administrador de backlog". Alguém precisa fazer esse trabalho administrativo, mas nesse caso o seu unico objetivo é garantir a entrega final, e tem muito pouco a ver com o que me preocupa em termos da necessidade de inovação consistente e verdadeira em nome de nossos clientes.
Esse modelo é realmente apenas o modelo cascata re-empacotada e não é usado em verdadeiras empresas de produtos de tecnologia. Então, vamos tirar isso do caminho.
Nota: Não estou caracterizando o time de desenvolvimento de forma pejorativa na seção acima. Utilizo essa nomenclatura para facilitar o entendimento. Os engenheiros e o time de desenvolvimento são cruciais para qualquer empresa, e manter o alinhamento entre todos é a chave para o sucesso.
Escrevi um artigo recente sobre como você pode entender o que os desenvolvedores querem dizer em algumas situações comuns.
Aviso: estou prestes a introduzir uma nomenclatura que não é padrão e certamente não está de acordo. Mas preciso fazer isso porque hoje, como indústria, nos referimos a ambos os outros tipos de times como "times de produtos" ou "squads". Mas, como você verá, embora pareçam semelhantes em um nível superficial, são dramaticamente diferente, especialmente quando falamos sobre o papel do gerente de produto.
No time de feature, você ainda (espero) tem um designer para garantir a usabilidade, e engenheiros para garantir a viabilidade técnica, mas isso é fundamental de se entender: o valor e a viabilidade do negócio são de responsabilidade do stakeholder ou executivo que solicitou a feature no roadmap
Se eles disserem que precisam que você crie a feature x, então eles acreditam que ela trará uma certa quantidade de valor e acreditam que a feature x é algo viável para o negocio.
Vale ressaltar que, embora o stakeholder seja implicitamente responsável pelo valor e pela viabilidade de negocio, eles ainda encontrarão uma maneira de culpar você e seu time se os resultados esperados não forem alcançados. "Demorou muito", "o design estava ruim", "as features críticos foram cortados para marcar a data", etc. Já escrevi muito sobre como as pessoas sempre encontram maneiras de culpar outras.
Estou alterando um pouco a definição mais estabelecida de time de feature aqui, mas estou usando o termo porque ajuda a destacar que esses times têm tudo a ver com entrega/resultado final – features e, ocasionalmente, projetos. Geralmente é fornecido ao time na forma de uma lista priorizada chamada de roadmap.
Muito frequentemente, os times não têm poder algum. Em contraste, eles estão lá para servir o negócio.
Quando escrevi sobre as virtudes em empoderar os times de produto, estava me referindo ao que continuarei chamando aqui de times de produtos. Especificamente, eles são multifuncionais (produto, design e engenharia); eles são focados e medidos pelos resultados (e não pelo produto); e eles têm o poder de descobrir a melhor maneira de resolver os problemas que foram solicitados a resolver.
Em uma time de produto empoderada (times de produto), o gerente de produtos é explicitamente responsável por garantir valor e viabilidade do negocio; o designer é responsável por garantir a usabilidade; e o líder técnico é responsável por garantir a viabilidade técnica. O time faz isso colaborando de forma intensa, dando e recebendo, a fim de descobrir uma solução que funcione para todos.
O objetivo de um time de produtos nesse sentido é resolver os problemas da maneira que nossos clientes amam, e ainda assim trabalhar para os nossos negócios. Por mais que eu queira, sei que apenas uma pequena porcentagem de times exsitentes são empoderados.
Quando falo e escrevo sobre o quão difícil é ser um verdadeiro gerente de produtos de um time de produtos empoderado, é precisamente porque é muito difícil garantir valor e viabilidade técnica. Se você acha que é fácil fazer isso, leia isto.
Bonus: Entenda qual o papel do gerente de produto em um time multidisciplinar.
Superficialmente, um time de features e os times de produtos são ambos "squads". Então, eles parecem semelhantes, mas as diferenças são profundas.
Em um time de produtos empoderada, em que o gerente de produtos precisa garantir valor e viabilidade de negocio, profundo conhecimento do cliente, dos dados, do setor e principalmente do seu negócio (vendas, marketing, finanças, suporte, jurídico, etc.) é essencial e não-negociável. (Dica: entenda como o time de vendas e marketing ajudam a criar o roadmap do produto).
Em um time de features, esse conhecimento é (na melhor das hipóteses) disperso entre as partes interessadas. De qualquer forma, espero que fique claro que as responsabilidades do gerente de produto neste modelo são muito diferentes para uma time de features.
O trabalho do gerente de produto em um time de features é mais comumente descrito como uma forma de facilitador (reunir os gatos) para obter o design e entrega da features, ou alguma forma nebulosa e fraca de líder multifuncional que não é realmente responsável para qualquer coisa específica. Esses times de features geralmente pensam que estão realizando a etapa de "descobrimento", mas na verdade é apenas design e talvez um pouco de teste de usabilidade.
Mas há outras consequências do time de features na função de gerente de produto.
Como o time NÃO está empoderado – para ser claro, quando você recebe resultados para entregar, você não está empoderado em nenhum sentido significativo – é muito difícil atrair e manter verdadeiros designers de produtos (alguém especializado em design de serviços, design de interação, visual design e pesquisa de usuários).
Na grande maioria dos casos em que você possui um time de features, o designer (se houver) é um designer gráfico. Não é que o design gráfico ou visual não seja importante, mas o que é relevante aqui é que agora existe uma grande lacuna – alguém precisa descobrir pelo menos o design de interação e, com sorte, fazer alguma pesquisa com o usuário. Por isso, é muito comum ver pressão no gerente de produtos desse modelo para tentar preencher essas lacunas.
Existem conseqüências negativas adicionais dessa situação, pois não é difícil aprender as ferramentas que os designers usam, mas é difícil aprender como fazer um bom design e pesquisa de usuários. Infelizmente, muitos gerentes de produto nunca tiveram a oportunidade de trabalhar com um verdadeiro designer de produtos profissional, por isso, eles nem sabem o que estão perdendo.
Se você tiver a sorte de ter um verdadeiro designer de produtos em seu time (pelo menos até que eles se mudem para uma empresa onde suas habilidades possam ser totalmente utilizadas), então eles geralmente (e com razão) questionam qual é o objetivo do gerente de produto, pois não é difícil para eles assumir as responsabilidades adicionais do gerente de produto de time de features, pois eles estão fazendo a maior parte do trabalho.
Nos times de features, a função de gerente de produto é principalmente gerente de projeto e parcialmente designer (não qualificado).
Muitas vezes há uma frustração semelhante com os engenheiros. O gerente de produto (que é realmente um gerente de projetos), geralmente está em desacordo com a maneira como os engenheiros acreditam que precisam estar trabalhando. Sem mencionar que, neste modelo, os engenheiros são relegados à entrega e, como eu já disse muitas vezes, se for esse o caso, estamos apenas obtendo metade do seu valor real (então, novamente, os bons vão querer sair e junte-se a um time de produtos empoderadas, onde eles possam realmente praticar suas habilidades).
Então, apenas para encerrar esse ponto, quando escrevo que o gerente de produto precisa "estar entre os talentos mais fortes da empresa" e "o CEO deve ver os gerentes de produto como potenciais futuros líderes da empresa" e "o gerente de produto forte é o CEO do produto ", definitivamente não estou falando de um gerente de produto em time de features.
Espero que, neste momento, você saiba se está trabalhando em um modelo de time de feature ou em um modelo de times de produtos empoderada, mas aprendi que as pessoas geralmente relutam em admitir quando estão no modelo de times de features.
Então, aqui estão alguns testes que você pode aplicar à seu(s) time(s):
Você fornece roadmaps com features e datas priorizados ou recebeu problemas para resolver com resultados para o negócio?
Existe confusão de papéis entre você e seu designer?
Existe confusão de função entre você e seu gerente de entrega?
Você passa a maior parte do dia gerenciando projetos?
Você tentou usar o OKR e foi uma bagunça ou acabou sendo rejeitado ou algum mashup artificial de resultados e recursos fornecidos?
Você tem um time de missionários ou mercenários?
Qual é o nível de responsabilidade?
Embora os times de features e os times de produtos pareçam muito semelhantes na superfície, elas são dramaticamente diferentes na maneira como operam, no nível de poder e prestação de contas e, principalmente, nas responsabilidades do gerente de produtos.
Posso afirmar, com poucas exceções, que os melhores times de produtos, das melhores empresas (como da Apple, Google, Intercom), seguem o modelo de times de produtos empoderada. No entanto, admito que, mesmo no que considero as melhores empresas de produtos, nem todo time de produtos é empoderada.
Na verdade, alguns possuem um time de feature. Geralmente, isso ocorre porque a liderança ainda não confia nesse time em particular. Às vezes, essa confiança precisa ser conquistada primeiro. E às vezes o problema é com o líder querendo ditar soluções.
Nunca tentei esconder meu forte viés em relação a times de produtos verdadeiramente empoderadas. Mas acredito que agora preciso ir além do que apenas defende-los; Preciso mostrar os problemas que os times de features causam e os maus resultados que eles oferecem.
Hoje, inúmeras empresas percebem a futilidade do modelo de time de entrega (time de devs) e sabem que precisam se transformar em uma verdadeira empresa de produtos com tecnologia, mas acham que podem conquistar isso fazendo alterações superficiais para acabar mudando para esses times de features. .
Ao me aproximar do fim desse artigo, quero enfatizar a diferença entre ser gerente de produto de um time de feature e um time de produtos empoderada. É um trabalho completamente diferente, exigindo um conjunto de habilidades muito diferentes. Provavelmente nem deveria ser o mesmo cargo. (Conheça em detalhes o papel do gerente de produto em um time multidisciplinar aqui)
É triste para mim que tantos designers e engenheiros nunca tenham sido expostos a um verdadeiro gerente de produtos e nunca tenham sido capazes de trabalhar em um time verdadeiramente empoderada. É por isso que afirmo que há tanto talento subutilizado por aí e por que continuo tentando convencer as pessoas a tentar trabalhar como as melhores empresas.
Uma coisa que você pode fazer imediatamente é que, na próxima vez em que ler um artigo ou tweet relacionado a um produto, participar de uma conferência ou participar de algum treinamento de produto, considere se o autor, palestrante ou treinador está falando sobre o modelo de time de produto empoderado ou o modelo da times de features?
Aproveitando o tópico sobre times de produto, eu escrevi um outro artigo onde eu falo sobre 3 estruturas comuns de um time de produto. Se quiser saber basta clicar no link! É um ótimo complemento desse artigo