O que é impacto?
Neste segundo post, resolvi aprofundar em um tema que, na minha opinião, é essencial para qualquer time de produto: impacto.
Tenho visto uma movimentação bastante grande no mercado pela orientação do trabalho de times de produto a outcomes (resultados) ao invés de outputs (features). Da mesma maneira, tem sido pauta de muitas discussões a vontade de designers de entrarem mais no processo de decisão de produto e negócio (o que muita gente chama de "sentar na mesa dos meninos grandes" (o machismo estrutural da frase fica para um post futuro). Vejo algo parecido ocorrendo também em times de engenharia de algumas empresas.
Tudo isso pra mim se traduz numa busca por aumentar o impacto que essas disciplinas possuem.
Mas o que de fato é impacto? E por que é importante entende o que significa?
Antes de explicar, deixa eu resumir de um jeito simples pra você em três pontos:
Outcome e impacto não são a mesma coisa
A avaliação de impacto não tem que ser binária
Impacto sem responsabilidade não existe.
Outcome e impacto não são a mesma coisa
Times que confundem outcomes com impacto, ou acham que por trabalharem com resultados ao invés de features estão automaticamente entregando maior impacto, estão provavelmente praticando o autoengano.
Produtos e features entregam resultados, mas estes podem estar mais ou menos próximos de algum impacto no negócio. Por exemplo:
uma mudança num signup de um produto SaaS [feature] pode aumentar a conversão [métrica de produto], que pode aumentar o número de planos online vendidos [outcome] e por consequência a receita da empresa [impacto]. Essa mesma melhoria na conversão poderia não gerar impacto, se por exemplo o aumento de venda de planos online canibalizasse as vendas offline.
é comum times de produto olharem para NPS como métrica principal. A tese de que clientes satisfeitos compram mais é válida, mas raramente se comprova na prática. O NPS é uma métrica que oscila conforme safra de clientes e ela é tem um ciclo relativamente longo de coleta pra fazer algum sentido. Enquanto isso, a empresa pode estar perdendo receita e isso passar totalmente despercebido ao time de produto. Outro efeito de times que pautam suas decisões em NPS é a ênfase total na adição de features — um jeito fácil de fazer parecer que as necessidades do cliente estão sendo endereçadas (e fácil também de esconder que o time não entende qual deveria ser a proposta de valor core do produto).
Times de produto precisam entender como a empresa funciona. A vida real não é feita de NPSs, MAUs e taxas de conversão. Ela é feita de transações, GMVs e receita.
Sem entender como a empresa funciona e entender como os outcomes se relacionam aos resultados do negócio, é impossível gerar impacto.
A avaliação de impacto não tem que ser binária
Ao orientar times por impacto, é essencial deixar essa expectativa absolutamente clara — seja numa ladder de carreira, num manifesto ou qualquer outro documento/artefato que as pessoas possam consultar e usar como guia.
Acho que meu grande desafio nesse processo sempre foi como dar clareza sobre impacto num cenário em que as pessoas trabalham com altos níveis de incerteza. Como estimular que as pessoas mirem alto e apostem em coisas que podem mudar o jogo, mas que ao mesmo tempo têm maior chance de dar errado? Como recompensar impacto e aprendizado na mesma medida? Sem pensar nisso, se cria uma cultura de trabalho que força as pessoas a lidar com objetivos impossíveis e sensação de fracasso constante, na qual dificilmente algum ser humano sobrevive por muito tempo.
Uma abordagem que pra mim tem funcionado é a avaliação da ambição do impacto, e não apenas do impacto em si. A ambição define onde a pessoa resolveu mirar com suas ideias e apostas — se em pequenos incrementos nas métricas de produto ou grandes impactos no negócio. Mirar em coisas grandes exige muito mais coragem, preparo e capacidade de articulação — por isso esse comportamento precisa ser recompensado na mesma medida. Falo um pouco sobre isso neste texto.
Ter grandes ambições não garante que vai haver impacto, isso é óbvio. Isso depende de um processo robusto e preciso de planejamento, execução e aprendizado ao longo do caminho. Mas se o mindset do time está orientado nessa direção, as chances de que o time entregue, no médio prazo, impacto significativo é muito, mas muito maior.
Gosto muito de um pedaço da carta para investidores do Alphabet (Google), que fala exatamente sobre isso:
"We will not shy away from high-risk, high-reward projects because of short term earnings pressure. Some of our past bets have gone extraordinarily well, and others have not. Because we recognize the pursuit of such projects as the key to our long term success, we will continue to seek them out."
Impacto sem responsabilidade não existe
Times que estão orientados a impacto precisam trabalhar com um nível de responsabilidade e coesão bem acima do normal.
Pra garantir impacto, nenhum time pode atuar por tarefas — as pessoas precisam atuar por processos. Eles precisam estar atentos a gargalos no processo inteiro e não apenas até onde passam o bastão. Precisam monitorar fatores externos e potenciais mudanças de contextos. E é essencial entender a fundo — mais do que ninguém na empresa — clientes e usuários.
Na ladder de carreira de engenharia do Netflix, eles chamam isso de "full-cycle". Full-cycle developers são pessoas que (na minha tradução livre e resumida):
acompanham todo o processo, desde o primeiro contato com usuários até a entrega total de uma feature
avaliam problemas e oportunidades na mesma medida em que pensam em soluções
pensam de um jeito "anti-pattern", pensando duas vezes antes de aplicar fórmulas prontas, sem entendimento do contexto da empresa e da iniciativa
atuam tomando decisões desde o início evitando o viés de "não é minha culpa". Todas as pessoas são responsáveis pelo resultado final.
Nos times com os quais trabalho, responsabilidade também se traduz — além do que já comentei — no seguinte:
ao buscar resultados para o negócio e não apenas para o produto, o espaço de atuação do time de produto aumenta bastante. Times comerciais, de branding/growth, atendimento ao cliente e inúmeros outros times de operação precisam estar integrados ao time de verdade. Não basta alinhamento 1 vez por semana, não basta chamar de squad.
os times precisam ser realmente orientados a dados. Não dá pra buscar correlações absurdas em dados pra escolher uma aposta que se quer fazer nem embasar decisões em testes a/b malfeitos. PMs vão precisar estar muito mais embasados pra argumentar sobre investir em um novo público, por exemplo.
métodos e processo de trabalho precisam ser robustos pra aumentar as chances de que o impacto esperado seja realmente alcançado. Uma das minhas atribuições como líder de produto é garantir que o time tem acesso às ferramentas corretas e as usa da melhor maneira. Fórmulas prontas ou que estão na moda passam longe do time por aqui.
quando se atua no nível que estamos falando, o processo de comunicação também muda. PMs e time todo precisam estar seguros e preparados para serem questionados a qualquer momento sobre processo e resultados. E a comunicação sobre o progresso precisa ser proativa, frequente e concisa.
A busca por impacto é legítima e todo time de produto deveria, em algum ponto, iniciar essa trajetória. Entender o que é e como começar a entender o que é preciso pra entrar nessa discussão já é um bom caminho.