“Perguntando qualquer coisa” ao Marty Cagan na RD!

Esse post faz parte de uma série de artigos sobre o que nós da Resultados Digitais aprendemos com o lendário Marty Cagan, seja participando do workshop ministrado por ele em SP ou na visita que ele fez à RD em Floripa para participar de uma sessão de Ask Me Anything.

Outros posts da série, escritos pelo @SergioJota — que participou do workshop:

• OKRs versus roadmaps em times de produto
• Seu time de produto não é ágil, mesmo usando agile
• Como fazer um bom processo de definição de OKRs em times de produto

__

Marty Cagan é uma das maiores referências mundiais de Gestão de Produtos. Ele trabalha com software desde a década de 80 e pegou toda a evolução dos produtos digitais. Passou por HP, Netscape e eBay. Fundou o SVPG — Silicon Valley Product Group e escreveu talvez o livro mais completo da área, Inspired, que serve de inspiração (rá!) para muitas coisas que fazemos aqui na Resultados Digitais.

Se você chegou até hoje sem conhecê-lo, já passou da hora! Mas se está por dentro das novidades, provavelmente já sabe que ele passou pelo Brasil, deu workshop, fez live streaming e movimentou o chapter de produto de algumas empresas do País.

Nessa turnê, ele separou um tempo para visitar a gente aqui na Resultados Digitais. Fizemos 2 horas de “Ask Me Anything” com Marty Cagan e aproveitamos para aprofundar vários assuntos que vinham povoando nossas reuniões internas de Produto, Design e Engenharia.

Vou dividir este post em 4 partes, procurando ser o mais aberto possível, mas vocês vão ter que me desculpar por não abrir tanto as perguntas e respostas mais focadas em nossos desafios e estratégias. (Em outras palavras, “quem não estava, perdeu!”)

1. Preparativos e alguns detalhes da visita
2. O que a gente “sabia que sabia”
3. O que a gente sabia mas faltava alguém reforçar
4. O que foi novidade

1. Como o Marty Cagan veio parar aqui?

Quando anunciaram o workshop do Marty Cagan em São Paulo, o chapter se animou de participar, mas naturalmente era difícil mandar todo mundo, então o grande Sérgio Schuler foi nos representar, com a promessa de voltar e fazer um bom resumo para toda a área e, claro, propor novidades.

Nesse processo, por causa de um problema no pagamento, rolaram umas trocas de email entre a RD e o Marty. Uns dias depois, descobrimos que ele ia passar por Florianópolis, então o Spengler retomou aquela thread e perguntou se ele não queria entrar para tomar um café.

O resto é história — e esta mensagem que o Spengler recebeu no slack:

Claro que entre ele aceitar e chegar aqui, fizemos alguns preparativos.

Primeiro, rodamos internamente um documento onde cada pessoa poderia incluir quantas perguntas quisesse fazer ao Marty.

Depois, fizemos uma curadoria das perguntas que surgiram, mesclando algumas parecidas, priorizando outras e deixando todas bem definidas e claras, para garantir que as respostas endereçariam o que de fato queríamos extrair dela.

Quando o documento ficou pronto, o Spengler compartilhou com o Marty, para que ele já tivesse uma noção do que viria pela frente — mas na reunião, fizemos as perguntas em voz alta, para deixar mais dinâmico.

Disparamos o convite para toda a área de Produto, Design e Engenharia. Quem não coube na sala, acompanhou em live streaming; quem estava ocupado na hora, pôde assistir à gravação (para uso interno, desculpa aí!).

Também abrimos um canal no slack para coordenar perguntas e réplicas que poderiam surgir na hora.

All set, vamos à reunião…

2. O que a gente “sabia que sabia”

Um dos primeiros tópicos abordados foi de times multi-funcionais, o que já aplicamos aqui na RD há quase 3 anos, com vários benefícios. Cada time tem pelo menos uma pessoa responsável por Produto, uma por Design e uma por Engenharia.

They seat together and solve problems together. (Marty Cagan)

Porém, desde o início do ano passado, temos investido forte em uma cultura de trabalho remoto, e como no Inspired o Marty diz que o time “senta junto e resolve junto os problemas”, queríamos entender melhor do que estamos abrindo mão, na visão dele, para ter um time mais remoto.

Ele trouxe alguns pontos que já imaginávamos, em relação à formação do time, alinhamento e afinidade. Na prática, já sabíamos, e continuamos procurando maneiras de minimizar esses problemas para nossos remotos.

Outro ponto que foi reforçado para o time foi uma eventual mudança de missão do time, para assumir algo mais importante e estratégico para o momento. Nunca tivemos um time que mudou totalmente de responsabilidade, mas como criamos novos times de produto em um ritmo acelerado, é frequente precisarmos “inflar e dividir” um time, em pessoas e em responsabilidade. Ele trouxe um pouco mais sobre o que está no Inspired a respeito dos times terem uma missão clara, e bem definidos os problemas que estão sob sua responsabilidade.

Também exploramos com ele a cultura de benchmarks e a diferença disso para analisar (e copiar) competidores. No dia a dia, é muito fácil confundir e acabar “se inspirando além da conta” no que outros produtos estão fazendo. Nosso objetivo era pegar dicas de como encontrar o ponto médio entre inspirar-se e meramente replicar. As respostas foram praticamente na linha daquilo que PMs e Designers já se esforçam para realizar: apaixonar-se pelo problema, não pela solução.

Por último, uma coisa que confirmamos que estava no caminho certo é a posição de Group Product Manager. Atualmente, temos um GPM responsável por uma área maior do produto, ao mesmo tempo que lidera outros Product Managers, cada um com suas responsabilidades específicas. Esse papel tem sido bem importante para garantir coesão e alinhamento desses times.

3. O que a gente sabia mas faltava alguém reforçar

O primeiro ponto que foi bom reforçar surgiu logo no início da conversa: se você tem bons profissionais, você vai ter resultados muito melhores dando a eles um problema para resolver, não algo para construir. É o tipo de obviedade que você poderia pensar “claro, nem precisava dizer”, mas é surpreendente o quanto podemos nos esquecer disso no dia a dia.

Isso vale não só para a liderança executiva em relação a PMs, mas também para PMs em relação ao time, o que reforça a importância de envolver o time de engenharia no processo de descoberta do problema e definição da solução.

Um desses ditados modernos do mundo corporativo diz que “sozinho vou mais rápido, junto vou mais longe”. A gente precisa sempre tomar cuidado para não viciar em andar rápido e, com isso, não envolver o resto do time. E como eu disse, vale o mesmo para a relação liderança executiva / de produto com o chapter de PMs!

Outra coisa legal que ele falou foi sobre OKRs:

Quarter should be plenty of time for what you do. (Marty Cagan)

Mesmo que tenha métricas que demoram para se mexer, escolha um proxy indicator — geralmente uma correlação confiável: quando esse indicador muda, a métrica principal muda com ele. Foi importante lembrar disso, principalmente para não viciar em longos processos de discovery que não colocam nada para os clientes usarem. Em muitos casos, cada dia a mais que você demora nesse processo é um dia que você não está aprendendo.

Também falamos sobre treinamento de Vendas e Marketing sobre as novidades do produto. Hoje temos uma reunião mensal para apresentar melhorias recentes e o que está planejado para as próximas semanas, mas frequentemente é necessário aprofundar, principalmente com times de Vendas, Suporte e Customer Success, explicando em detalhes a melhoria e como orientar clientes a extrair o máximo dela. Hoje, a responsabilidade de ajudar as outras áreas a compreender plenamente o produto é de Product Marketing, o que segundo o Marty, é a melhor opção mesmo!

Por último, passamos bastante tempo falando sobre OKRs e Roadmaps, e eu recomendo fortemente que você leia o artigo específico sobre esse tema que o Sérgio Schüler escreveu.

4. O que foi novidade

É claro que nem tudo a gente faz certo, e teve alguns pontos muito bons que o Marty trouxe na conversa e que nos ajudaram a entender melhor o papel do chapter de produto.

O primeiro deles é sobre cultura de produto e o quanto isso é diferente da cultura de como fazer produto. Uma coisa é ser uma organização voltada a resolver problemas de clientes de forma escalável (ou seja, via produto / tecnologia), outra coisa é esperar que todas as áreas vão saber fazer produto.

You should not go to other areas before you are totally awesome here. (Marty)

É claro que é importante que todas as áreas estejam alinhadas antes de você colocar qualquer novidade no mercado, mas isso é mais treinamento do que cultura.

Em paralelo, qualquer pessoa que esteja de frente para o cliente no dia a dia deve saber que quando o cliente tem um problema, ela deve reportar para produto. Se ela não faz isso, ela está errada. E se PMs não endereçam adequadamente, eles estão errados. (Sim, o Marty é bem direto nos feedbacks!)

Por último, falamos um pouco sobre backlog de débitos técnicos e algo que ele reforçou foi que PMs não deveriam tocar nessa priorização. Aliás, é a única coisa que não deve ser priorizada por PMs, e sim pelo Head de Engenharia ou papel equivalente na organização. O ideal é reservar um % do tempo de cada time ou um % de pessoas da área para resolver esses débitos, e não precisa ter um PM nesses momentos.

Vale lembrar que bugs e débitos técnicos são coisas diferentes. Bugs afetam a experiência do cliente hoje, enquanto débitos técnicos atrasam a evolução do produto, são questões mais internas. Uma vez que o chapter de engenharia esteja ciente da visão e estratégia do produto (o que é obrigatório!), eles são capazes de definir quais débitos são prioritários de serem resolvidos para permitir que o produto evolua naquela direção.

O que mudou e o que está mudando

Já faz quase 20 dias que tivemos o papo com o Marty e, de propósito, esperamos um pouco para publicar esses aprendizados. O chapter se reuniu para refletir e discutir cada ponto: o que aprendemos, o que podemos colocar em prática desde já e o que podemos puxar como melhoria em nossa forma de entregar sucesso em escala para milhares de clientes no mundo inteiro.

Uma coisa que certamente já mudou, além da injeção de “brilho nos olhos”, foi que reforçamos pontos importantes do processo de discovery e ficamos mais críticos a respeito de duas perguntas chave da gestão de produto:

1. O que queremos aprender com isso?
2. Que problemas queremos resolver com isso?

Sabemos que algumas mudanças ainda vão levar tempo, mas tudo que está apenas em nossas mãos, já nos comprometemos internamente a fazer melhor.