Batendo o bumbo: boas práticas para empoderar times de produto e design
Fui convidado abrir a Product Camp 2020 e trago aqui seu conteúdo em texto. (slides no final)
Times de Projuto
Acredito que alguns de vocês já ouviram falar do termo Projuto. Não, eu não escrevi errado. Estamos falando de produtos que são tocados como projetos.
Como saber se trabalhamos com Projuto?
1. Escopo vem top-down, liderança (ou cliente) falando o que o time deve entregar, no detalhe
2. Com isso, o time entra numa lógica de entrega, onde o único risco é atrasar
3. Time não decide nada. Se stakeholders mudam de ideia no meio do projeto, que assim seja.
⠀⠀
⠀⠀
Qual o impacto disso?
Basicamente times focados em features, não em resultados.
O Paulo Floriano (CPO) acabara de entrar, e me convidou para se juntar ao time. E esse era, sem dúvida, nosso maior desafio:
Como podemos empoderar os squads a pensar em resultados e não em features?
Minha ideia aqui é dividir com vocês o que nós fizemos. Resultados e desafios. Afinal, estamos falando de um processo de mudança de comportamento, em várias esferas, de vários atores.
Vou compartilhar 6 práticas para você levar para o seu time, com exemplos.
Lembrando que elas estão em ordem de importância. Ou seja, não adianta começar do final. Vamos das mais estratégicas, até as operacionais.
⠀⠀
⠀⠀
1. Deixe clara a estratégia da empresa, e onde cada squad se encaixa
Não adianta falar de experimentos, métricas e hipóteses se os times simplesmente não sabem como estão contribuindo pro negócio.
Essa tarefa é do C-level: definir onde estamos e onde queremos chegar, e revisada de 9 a 12 meses. Não precisa ser um documento muito extenso; um slide basta.
A estratégia deve ser comunicada até ficar claro para todos os times onde eles se encaixam. Um exemplo:
Por que isso é bom:
Isso dá contexto. Todo mundo sabe, em uma frase, qual é a missão do seu squad, deixando a priorização muito mais fácil lá na frente.
⠀⠀
⠀⠀
2. Trabalhar em trios
Quem já trabalhou em agência de publicidade lembra da famosa dupla de diretor de arte e redator. Eles faziam tudo juntos: bolavam o conceito e a arte visual da campanha.
O mercado consagrou muitas duplas, que ganharam prêmios e eram cobiçadas por outras agências.
Infelizmente, nas empresas de tecnologia isso é um pouco diferente.
Em muitas empresas, o time de produto e design “disputa” pela liderança do squad, gerando desgaste e rotatividade.
Trabalhar como dupla faz as duas pessoas serem responsáveis pelos mesmos resultados e aumenta o impacto que elas podem gerar. Na Revelo, essa dupla recentemente virou um trio, com a adição do time de growth nos squads.
Não precisamos definir no detalhe até onde vai cada papel: cada trio funciona de acordo com suas skills e responsabilidades.
Isso não quer dizer que não existam cerimônias de design, produto e growth separadas. Elas existem, mas são para tratar de assuntos mais operacionais de cada time.
Algumas práticas que fizemos para fomentar isso:
- Team building entre as áreas
- Canal no Slack
- Cerimônias
- Resultados
- Report semanal
⠀⠀
⠀⠀
3. Definir métrica e meta para todos os squads
Quando chegamos, os times acompanhavam métricas, mas não tinham clareza sobre quais delas tinham alavanca ou não.
Usamos o framework do Amplitude na redefinição das métricas de cada time
Métrica de negócio › métrica norte › inputs
Vamos ver um exemplo, como se trabalhássemos no time que cuida dos Stories no Instagram.
Elas são revisadas a cada trimestre, conforme o time aprende onde tem alavanca. As metas são definidas pelo próprio time, não é um processo top-down.
Temos uma planilha de acompanhamento das métricas de todos os squads, que dão visibilidade e transparência para todos.
⠀⠀
⠀⠀
4. Definir apostas pro trimestre
A partir das métricas, definimos quais são os grandes temas que vamos atacar no trimestre.
Vamos ver um exemplo do Instagram:
Pensamos de 3 a 5 apostas, priorizadas. São como se fossem épicos.
A partir disso, quebramos essas apostas em experimentos. Elas praticamente têm duas etapas: validar desejabilidade e valor.
Tudo bem esse backlog mudar ou ser repriorizado conforme o time aprende.
Vamos ver agora as duas dicas finais, mais operacionais.
⠀⠀
⠀⠀
5. Definir uma meta de aprendizado semanal
Times de alta performance rodam muitos experimentos por semana.
É comprovado que times que aprendem mais rápido, geram mais impacto nas métricas.
Caso clássico do Twitter, que depois de colocar uma meta semanal de aprendizados, fez com que o time tivesse muito mais impacto nas métricas.
Batemos o bumbo para que os times tragam um novo aprendizado por semana. Esse aprendizado pode vir de vários lugares: pesquisa, experimento, rollout.
E deve ser relevante o bastante pra ser compartilhado com outros times.
Como fazemos isso acontecer:
Temos uma reunião que acredito ser o pulmão do nosso time de produto, o Review de métricas e experimentos.
É uma reunião semanal onde olhamos as métricas de cada time, e cada dupla apresenta dois slides: o que aprendeu semana passada e o que quer aprender nessa semana.
Essa reunião começou entre o time de produto apenas, depois vimos que fazia sentido chamar alguns heads pra assistir e já ficarem alinhados.
⠀⠀
⠀⠀
6. Defina um framework de aprendizado
Adoro essa frase do Maslow:
“Se você tem um martelo, todo problema parece um prego.”
Isso significa que temos um grande viés de fazer apenas o que estamos confortáveis. Quem gosta de pesquisa, só faz pesquisa. Quem gosta de teste a/b, só a/b.
Como fazer os times usarem a abordagem certa para o tipo de aprendizado que querem ter?
O que fizemos foi definir uma linha de raciocínio, que é reforçada em cada Review de Experimento.
Começou assim, apenas definição de método e experimento.
Porém, vimos que alguns times começaram a usar o mesmo método pra tudo.
Iteramos. Hoje os times tem que escrever qual pergunta eles querem responder na semana.
A pergunta ajuda a definir o método, que define experimento, e esse o critério de sucesso.
Porém, você não pode só criar um framework e esperar que todo mundo utilize.
Ele precisa estar embedado em alguma cerimônia que o time já toda. Como reforçamos isso:
- Office hours, é um balcão de dúvidas onde eu oriento os times
- AMAs, encontros de produto e design pra tirar dúvidas e debater ideias
- Workshops, para treinar o time
⠀⠀
⠀⠀
Desafios (entre aspas)
Baseado nos lugares que eu já trabalhei, acho que temos um problema de primeiro mundo. O famoso white people problem.
Os times às vezes ficam muito focados em discovery, e o backlog de tech acaba ficando baixo.
Por que isso acontece: muitos experimentos não precisam de tecnologia pra rodar. Usamos ferramentas no-code, como Webflow, Appcues, Zapier, Google optimize para subir testes rapidamente.
Depois de validado, refinamos e passamos pra tech.
Porém se esse ciclo demorar muito, o time pode ficar com fome de features. E com razão!
Importante, junto aos tech leads, avaliar o volume de backlog de cada time e pensar em ações para populá-lo caso o discovery ainda não tenha gerado material pra delivery.
⠀⠀
⠀⠀
Resultados
Hoje temos times gerando impacto semanal nas métricas, que era a nossa meta.
Sistematicamente, tracionamos produtos, reduzimos custo de aquisição, aumentamos engajamento e retenção.
O mais bacana pra mim é ver outras áreas e iniciativas “importando” nosso jeito de trabalhar. O time de produto vem sendo convidado a participar de outros fóruns simplesmente pelo jeito diferente de trabalhar.
“A bad system will beat a good person every time.”
— W. Demmings
Não tente mudar as pessoas. Mude o sistema, e o sistema muda o comportamento das pessoas.
Veja os slides da apresentação abaixo.
