Essa semana está rolando o maravilhoso Digital Product Week 2020. Um curso gratuito incrível sobre Produtos Digitais e Tecnologia produzido pelo pessoal da Tera.
Esse ano eles chamaram o Marty Cagan, que fechou a primeira noite do curso com uma palestra chamada Product Management: the Good, The Bad and the Ugly.
Estas são anotações de partes dessa palestra. Quem já acompanhou eventos comigo, sabe que eu anoto palestras compulsivamente. Consigo absorver muito conteúdo assim e depois ainda serve para compartilhar, como estou fazendo agora. Por isso, por favor, não liguem se houver typos na escrita, além de algumas partes que podem ficar com sentido estranho, porque fui fazendo uma tradução simultânea de inglês para português enquanto o Cagan falava. ;-)
Sobre Tipos de Time de Produto
Os times que se focam no produto são importantes. Se uma empresa não tem times focados no produto, não há como ter produtos digitais fortes. Existem 3 tipos de times de produto que o Cagan enfatizou na palestra. Ele disse que esteve no Brasil várias vezes e encontrou esses três tipos de times aqui, mas também na Europa, na China, Índia e em todo o mundo.
A partir de uma visão muito macro, esses tipos são bem parecidos. Mas eles não são iguais quando vemos no detalhe e quando executamos o dia a dia. Os três tipos de times são:
- Delivery Teams (the bad);
- Feature Teams (the ugly);
- Empowered Product Teams (the good);
Existem os bons times de produto, os times de produtos feios e times de produtos ruins (The good, the ugly and the bad teams). Em grandes empresas, é muito dinheiro é gasto para obter apenas entregas. Os times são montados para entregar tarefas e/ou funcionalidades e só. Esses são os times “ruins”.
O Delivery Team
O delivery team (bad teams) tem um PO, que não é um gestor de produto, mas que se diz ser o dono do produto. O Job principal dessa pessoa é gerenciar o Jira. É um administrador de backlog. Geralmente esse time não tem um designer dedicado que pensa na experiência do usuário. Existe um time de Devs, que estão lá apenas para implementar o backlog definido pelo PO.
Tudo nesse time se trata de entregar código. Geralmente eles usam SAFe. SAFe não tem nada a ver com Ágil. É apenas um truque de marketing para que as pessoas que preferem trabalhar com waterfall pensem que estão fazendo ágil, mas não é ágil. Se você está em uma empresa assim, a sugestão do Cagan é que você se mude para outra empresa. Não existe espaço para você fazer produtos nesse modelo.
Contudo, essas empresas fazem muito dinheiro, eles são líderes do mercado, então não há muito o que fazer para ajudá-los, porque o negócio “parece” estar dando certo. Felizmente a maioria das empresas que “fazem produtos” raramente usam esse tipo de times.
Os Feature Teams
Já os feature team ainda não são os bons times (são os ugly teams). Essa é a parte que frustra: porque esses times deveriam ser os bons times, mas as empresas não entenderam a diferença sobre como ótimos times funcionam. Empresas assim estão no meio do caminho do processo de produtos. Netflix, Slack, Amazon, Google, Apple, AirBnB são exemplos de empresas que entendem como os BONS times funcionam.
Os feature teams se parecem com um time real de produto, pois ele têm um PMs, eles têm um Designer, eles têm um Time de Devs… Mas a diferença é muito fundamental: os feature teams eles estão lá para servir o negócio. O que significa é que stakeholders tem uma necessidade, e eles priorizam essas necessidades e dão como um roadmap para times de produtos desenvolvedores. O trabalho desse time é servir o negócio.
Nesses times, Product Managers são melhores descritos como Project Managers, pois o trabalho deles é mover as tarefas do designer, para o time de desenvolvimento e depois para os testers e assim por diante até fazer o deploy. O Cagan não sugere que você saia de empresas que tem feature teams (assim como ele sugere que você saia de empresas que tenham Delivery Teams) pois essas empresas estão tentando se transformar, e para que elas ultrapassem a fase de transformação, elas precisam da sua ajuda.
Esses times são direcionados por outputs, não outcomes. É muito difícil distinguir esses times de times de produto reais, porque eles ainda entregam coisas que se parecem com valor que os usuários precisam ou que atingem as necessidades de negócio.
Os Empowered Teams
Esse são os times que que criam uma grande empresa com grandes produtos. Google e Intel foram construídas nesse modelo. Empowered Teams existem para servir os clientes (os clientes reais, que pagam para ter o produto), de uma forma que encontrem as necessidades do negócio.
Nesse contexto a relação do PM e do Time, juntamente com o resto da empresa, é fundamentalmente diferente dos outros dois tipos de times: um empowered team não é um servidor dos stakeholders, mas eles trabalham para resolver problemas servindo o cliente final.
Nesse contexto, temos PMs realmente responsáveis por encontrar a solução para o usuário que saciem as necessidades do negócio. Essa soluções são viáveis, valiosas, possíveis e usáveis.
Times de produto empoderados são times que tentam resolver problemas do negócio e dos consumidores. Eles são empoderados para descobrir, desenhar e entregar soluções para esses problemas, além de serem responsáveis pelos resultados (bons ou ruins).
Nesse caso, Product Managers têm um trabalho que demandam muito do seu tempo. É um trabalho mais difícil e estressante. É um trabalho que impacta o negócio e as pessoas. Pensa que você é um PM que trabalha em produtos como Gmail, que impacta bilhões de pessoas. Você precisa entender que há uma responsabilidade muito ampla e com muitos riscos envolvidos.
Times Empoderados de Produto tem as seguintes características:
- São times multifuncionais, compostos por especialidades como Product Manager, Product Designer, Devs e outras especialidades como QA, Data, Researcher etc. Tudo o que é necessário para resolver um problema daquele produto;
- Eles são times pequenos. Apenas os suficiente para resolver os problemas;
- Times duráveis. Eles não são times temporários. Esses times precisam estar juntos o suficiente para aprender, ganhar respeito, autoridade sobre o assunto que estão resolvendo;
- Times com sentimento claro de ownership. Eles não são donos do produto inteiro, eles são donos de um pedaço, mas eles são realmente donos desse pedaço que eles cuidam;
- Times empoderados, que podem tomar decisões para resolver problemas claros. Eles sabem qual a melhor forma de resolver os problemas que estão enfrentando. Eles fazem isso testando várias ideias e hipóteses;
São direcionados por outcomes (resultados). Eles não são medidos pela quantidade de features ou tarefas que eles entregam, mas pelos resultados que eles criam, pelos impactos que eles causam nos ponteiros de negócio;
Como times de produtos empoderados resolvem problemas?
Eles fazem Discovery para descobrir qual a melhor hipótese eles precisam atacar. Eles precisam fazer produtos que são valorosos, usáveis, possíveis e viáveis. Para isso eles passam por uma fase de Discovery para entender e validar ideias.
Na fase de delivery eles trabalham para entregar uma solução que confiável, escalável, performática e de fácil manutenção.
Algumas pessoas chamam isso de Dual Track Agile, outras de Continuous Discovery e Delivery. Airbnb chama isso de “Build things don’t scale, then build things that do scale”. O Google chama de “Fake it, then make it”.
Esse é um teste que você pode fazer para entender se seu time é um Empowered Teams. O Canga disse que ficaria feliz se você me dissesse que trabalhasse em um time assim.
- Meu time é Cross Functional: O time é formado com competente pessoas que cobrem várias especialidades: Devs, design, produtos, qa, etc
- Meu time é empoderado: O time é alinhado para resolver problemas, e eles são capacitados para decidir as soluções desses problemas e tem o poder para decidir;
- Meu time é Accountable: O time que é responsável para resolver problemas de clientes e ou do negócio (outcome);
Como transformar seu time em um time empoderado de produto?
- Garanta que exista um líder sênior de produto. Se seus líderes não tem essa experiência e não conseguem Coach com pessoas competentes, isso se torna critico e a transformação falha;
- Aumente a base fundamental de conhecimento e experiência do time. Precisamos de Product Managers, não Project Managers, não Product Owners. Mas Product Managers. Eles também precisam de Coach. Se não há Coach para os PMs se tornarem melhores, também falharemos;
- Re-apresente os times para os times de negócio, executivos e stakeholders. Quando esse time existir, faça essa re-apresentação, para que haja uma cooperação de todas as partes;
Pontos chaves para uma transformação de sucesso:
- Senior Leadership Support;
- Embrace the role of technology;
- Understand impact beyond product;
- Strong Product Leaders;
- True strong product managers;
- Empowered engineers;
- Intentional product strategy;
- Business collaboration;
- Continuous evangelisation;
- Corporate courage;
O líder é responsável não apenas pela visão do produto, mas também pela estratégia do produto. A estratégia do Produto é necessária para que o time de produto faça a evangelização das outras áreas. É assim que podemos compartilhar as falhas e os sucessos do produto com os integrantes de outros times da empresa.
Algumas perguntas feitas no final da palestra
Quais os skills de um bom product managers ou um time empoderado?
São 4 pontos importantes:
- Precisam aprender sobre os clientes/usuários. Visite, fale com os clientes… Entenda seus problemas, seus problemas, seus objetivos;
- Aprenda sobre dados: entenda como os produtos são usados. Como o produto é comprado. Você precisa gastar um tempo perguntando com os analistas de dados. Mas você precisa ser um expert sobre como seu produto é usado;
- Entenda sobre a indústria: qual o ambiente competitivo? Como o mercado se comporta? Esteja sempre antenado nas novidades da indústria;
- Conhecimento profundo do seu negócio: como funciona os problemas financeiros? Quanto custa para manter a empresa? Quais os custos? Quais os competidores? Como a empresa ganha dinheiro? Como os competidores ganham dinheiro?
É possível um PM que não tem background técnico de atuar como um PM
Algumas empresas pedem esse background, outras não. Tudo o que um Product Manager precisa é coaching. Não encontre uma empresa que tenha só times de delivery. Procure empresas que tenham um ambiente que potencialize o papel do Product Manager.
O trabalho do PM é o pior trabalho se você quer chegar de manha, tomar um cafezinho e ir embora depois do expediente. Você precisa se preocupar com o seu produto. Precisa pensar como o dono, não como um empregado. Isso é essencial para PMs, mas também para Times de Produto.
Sobre KPIs e OKRs
Os KPIs são relacionados a OKR. OKR é apenas uma técnica, que primeiro há muita confusão e frustração sobre OKR exatamente porque as pessoas confundem o que o OKR é. Além disso as pessoas falham ao usar OKR, porque o OKR é feito para times empoderados (Empowered Teams), não para Feature Teams.
Minha (longa) conclusão
Tecnicamente o Cagan só reiterou seu discurso de anos sobre o papel do Product Manager, mas agora, o Cagan está discursando mais no ambiente de times de produto e não do papel do Product Manager. Embora ele já tenha falado bastante sobre o assunto de estruturação e como os times de produto deveriam ser, acho que faz sentido ele “reciclar” esse discurso para um tempo onde empresas acham que é só colocar o nome de SQUAD em grupos de duas ou mais pessoas que a coisa vai rolar magicamente.
Como sempre a palestra dele foi cheia de socos no estômago de quem acha que faz produto, e também encheu de alegria os papagaios que existem no mercado. Eu concordo com praticamente quase tudo do que o Cagan fala, exatamente porque é óbvio.
As palestras e as palavras do Cagan nos tocam tanto, porque nós não conseguimos fazer praticamente NADA do que ele fala/prega. Não por que não queremos, mas por que o ambiente atual das empresas e do mercado de tecnologia no Brasil é muito imaturo.
Não temos a cultura de tecnologia necessária (e se você estiver pensando só em Devs quando lê tecnologia, é uma prova do que estou falando), quando comparamos nosso mercado e o mercado lá de fora. Embora o Cagan fale que lá fora também existam problemas como aqui, com certeza não são problemas de um nível tão inicial quanto os daqui.
Existem sim empresas que chegam muito perto aqui, mas ainda assim, acho que a verdadeira mudança está por vir nos próximos anos, quando profissionais estarão mais maduros, empresas estarão mais acostumadas e espertas e consumidores mais disciplinados e preparados. Até lá, tente mudar o status quo e fuja de (ou ajude a mudar) empresas de produtos que se parecem com acampamentos hippie.
