Pequenos passos, grandes produtos #1

Sprint Review: A cerimônia esquecida que pode mudar tudo

Não vou falar por todo mundo, mas quase nenhum dos lugares por onde passei que aplicavam Scrum faziam a Sprint Review. Alguns até tinham uma reunião com esse nome mas na prática discutia outras coisas e não servia ao propósito da Review.

Que propósito seria esse? De acordo com o Scrum Guide “O objetivo da Sprint Review é inspecionar o resultado da Sprint e determinar os próximos passos pro futuro. O time apresenta o trabalho que foi feito e se discute o progresso rumo à meta do Produto”

O trecho chave aqui é “Apresenta o trabalho feito”. Não é discutir o que deu errado, não é dizer que tá tudo pronto e só falta a revisão de código pra subir, é mostrar o que tá pronto. A regra que gosto de usar: É proibido mostrar Figma, Miro, PPT, ou ambiente de teste. O time abre o site/produto mostrando cada história do board no ar, visível pros usuários - e de preferência enviando eventos de medição pros dashboards de produto, afinal o resultado de um produto é medido pela resposta do público. Sem medir essa resposta, entregar o código pode não surtir efeito algum.

E por que ter uma cerimônia só pra oficializar o que já tá acontecendo? Realmente a Review não faz diferença nenhuma na Sprint entregue. Mas fará nas Sprints futuras.

Muito se fala em autonomia e como é algo desejado nos grupos de trabalho. Isso não acontece simplesmente falando no assunto, mas sim fomentando práticas que estimulam esta autonomia, dando segurança e senso de responsabilidade aos times. É por isso que não adianta falar. Quando alguém manda você trabalhar, mesmo que a ordem seja “Tenha autonomia”, o efeito é o contrário. As pessoas vão tentar fazer algo pra agradar quem tem poder. A consequência de longo prazo de ter um time focado em agradar stakeholder é que o foco fica em agradar e não na entrega. As duas coisas no início estão de mãos dadas, mas vão se afastando. Se o time descobrir que dizer ou esconder algo agrada mais do que a entrega em si, pode ter certeza de que farão isso. E isso não será traço de um time ruim, pelo contrário. Será um time fazendo muito bem exatamente o que se incentiva neles.

O que funciona então? Fazer o time se responsabilizar pela entrega. Aqui entra o real objetivo da Sprint Review. Quando o time mostra algo combinado no ar eles têm a chance de se orgulhar do que foi feito, ou também sentir o peso de não ter ainda conseguido botar no ar o que se comprometeu. Não há discussão, há apenas fatos sobre o andamento do trabalho na mesa. O único interesse é saber na prática o que realmente pode ser removido do backlog pra se decidir os próximos passos sem subjetividades. A política é removida do processo.

É por isso que botar placares eletrônicos mostrando a velocidade atual dos carros que passam tem eficácia comprovada em fazer os motoristas dirigirem na velocidade limite, mesmo quando é claro que não há ali multa automática. O próprio motorista, quando é obrigado a se deparar com um fato sobre o que está fazendo, tem a oportunidade de se corrigir pra fazer melhor. O ganho é a sensação de fazer a coisa certa e ser um bom motorista. Esse é um incentivo mais poderoso a longo prazo que instalar punições que podem fazer o motorista diminuir a velocidade apenas onde ele sabe que existem radares e acelerar no resto do percurso.

O que eu vi toda vez que implementei a Review: A cada Sprint o time ia se responsabilizando mais pela entrega, ficando mais proativo, se mexendo pra resolver problemas, avisando rapidamente quando encontrava obstáculos. Ao entender que a entrega depende unicamente do que foi combinado na planning e não de explicações, o planejamento fica mais maduro e assertivo. Ao saber que não existe avaliação externa além de aferir se as tasks foram pro ar, o time fica mais seguro em botar 100% do foco nisso.

Então repassando as dicas pra uma Review que exorciza a política e aumenta o senso de dono dos times:

1. O formato da reunião é olhar os cards que estão em “Done” e o time mostra aquela história funcionando em produção

2. O PM aprova a entrega - ou mostra de acordo com o card porque não está de acordo - e pode tomar 3 ações:

   1. Dá o card como entregue

   2. Caso nada no escopo tenha mudado, só não deu tempo de terminar: Volta o card para o backlog com observações do que falta a serem inseridas na planning

   3. Caso tenham surgido novos escopos não previstos: Cria um novo card com tarefas de apoio e põe no backlog de acordo com a severidade/prioridade adequada

3. Não usar a Review pra reclamar, olhar feio, pedir justificativas em detalhes. Quanto mais objetiva for a reunião, mais tranquilo e seguro o time fica pra se autoavaliar.

O lugar para debater o que deu certo ou errado nos processos é na Retrospectiva. Confundir com a Review na minha vivência invariavelmente faz com que a Review se perca em discussões e explicações. Separar as duas passa a mensagem clara pro time: Uma coisa são as entregas, outra são os processos.

Nunca se esqueça: O time quer entregar. Times seguros e autônomos entregam mais.

Te convido a experimentar.

Diário de Produto - Dia 8

Esta é uma série onde documento a jornada de fazer um produto dar lucro - ou falhar miseravelmente. Em todo caso, nos divertiremos juntos

No diário anterior eu mostrei várias mudanças muito expressivas em alguns números absolutos. O gráfico abaixo mostra o efeito drástico que ocorreu no número de usuários que experimentam utilizar o produto por semana:

O patamar anterior estava ente 100 e 200 usuários/semana, na mudança passou de 1.000, despencou pro feriado de Natal e Ano Novo mas ainda assim ficando ali pelos 400 e agora está flutuando perto dos 1.300.

Só relembrando que o principal fator aqui foi a criação de um uso anônimo e grátis para qualquer pessoa que chegue no produto. Então a subida era esperada, e o patamar está dentro do previsto, uma vez que quase todo o tráfego vem do blog que apoia o produto e eu já sabia quantas pessoas clicam nos posts do blog para abrir o produto. Até fizemos alguns ajustes cosméticos na UX do blog pra tentar subir mais esse número, o efeito foi o do gráfico abaixo:

Pode não ser uma mudança tão visível, mas tirando um pico no meio de setembro e um buraco em novembro dá pra distinguir uma tendência por volta de 12.5% de CTR (click-through rate) do link no blog que leva ao produto, e desde as mudanças em dezembro esse número flutuando mais perto de 14%. Uma variação de ~12%, que se seguir se confirmando é expressiva (e já me deu algumas ideias pra tentar puxar mais pra cima).

Então estamos conseguindo jogar muito mais tráfego pro produto, a grande e óbvia pergunta agora é: Como isso refletiu nas vendas?

Pois é, não refletiu.

Como a taxa de conversão é historicamente baixa, o gráfico é meio “nervoso” semana a semana, então mudanças sutis não são perceptíveis. O que podemos afirmar é que mudança brusca não houve. Com esse dado debaixo do braço parti pra uma estratégia que precisou de um exercício político: Testar um outro meio de pagamento que me permitiria um processo mais padrão, com um form pedindo dados de cartão de crédito e pronto.

No diário do dia 4 eu expliquei que isso geraria um problema complicado na contabilidade, a princípio tinha abandonado a ideia pra perseguir outras coisas, mas me muni do argumento mais simples possível: “Sabendo que isso te atrapalha, o que podemos combinar pra gente poder testar um pagamento novo por 1 ou 2 meses só pra vermos o resultado?”

Um dos fatores era a dificuldade de devolução. Isso eu consigo resolver no nível de produto: O usuário já tinha trial grátis de tudo que o produto oferece por 7 dias, não havia mais argumento válido pra pedir devolução de dinheiro. Então não faríamos mais devoluções e é isso. Também perguntei quantas devoluções fazemos por mês, a resposta foi algo como “A última foi em outubro”… Era coisa de 2 ou 3 por ano. Risco baixo. Checamos com o jurídico, tudo certo, o pessoal do financeiro ficou mais tranquilo. O trabalho manual deles aumentaria mas era algo navegável.

Implementamos então um sistema global de pagamento via cartão de crédito. Redesenhei a página de pagamento pra incluir um discurso de venda explicando melhor o que o produto oferece e o formulário já com o preço único de assinatura aparecendo.

Uma boa trabalheira, o resultado foi esse (preciso ocultar os números aqui):

Como instalei o mixpanel em setembro só tenho os números a partir daí. Tem lá um pico, depois um viés de queda, e a partir das mudanças em janeiro vemos o mesmo patamar de outubro, com uma levíssima tendência de crescimento. Veremos como fecha fevereiro.

Quando comparamos assinaturas e cancelamentos, o cenário é este:

No último trimestre de 2024 as linhas de cancelamento e de compras estavam entrelaçadas, com o churn até ganhando de novos usuários em alguns pontos. A partir de janeiro vemos um afastamento, mas que se deve mais a uma queda do churn do que ao aumento das vendas. Como só agora em fevereiro estamos trabalhando mudanças na UX para melhorar o produto, o churn pode voltar a subir a qualquer momento encostando de novo nas assinaturas.

Porém fica pior: Com o aumento do uso nossa fatura de infra veio inflacionada em 100%, o que causou uma sala de emergência pra ver há opções pra não derreter nosso caixa.

Conseguiremos salvar esse produto antes dos donos do dinheiro desistirem de ficar no prejuízo? Aguardem os próximos capítulos.

Links da semana

"Ágil flácido"

Uncle Bob, o autor de “Clean Code”, toca uma real sobre projetos de software e os pré-requisitos pra agilidade dar certo que ninguém utiliza - e depois reclamam que não deu certo. É tudo do ponto de vista de engenharia, o que dá uma perspectiva muito útil. Tem mais de uma hora, mas o cara é ótimo contador de histórias e passa voando: https://www.youtube.com/watch?v=l-gF0vDhJVI

PM precisa saber tecnologia?

Ainda na ótica de engenharia sobre Produto, tá na moda discutir se Produteiros precisam ou não saber codar. O Ben Erez no ótimo SupraInsider conversou com a Irene Yu, ex-engenheira da Amazon que fundou sua própria startup de educação de tecnologia para PMs. Ela explica quais os motivos errados pra alguém achar que precisa aprender a ser mais tech, e o que os engenheiros realmente precisam e esperam que a pessoa de Produto faça: https://suprainsider.substack.com/p/43-how-ai-is-impacting-the-pm-engineer

Brasil brilhando na IA

Após a Fernanda no Oscar e o João no Tênis, outros brasileiros estão surgindo como potências também no mundo da IA.

Webcrumbs é um engine que constrói todo o código de frontend a partir de prompts, eu pra testar botei lá simplesmente “CRUD Screen”, talvez o pior prompt do mundo, e ele me devolveu algo no nível do Retool, com uma visão de tabela todas as funcionalidades para editar bancos de dados. 10/10. Acessem aqui: https://www.webcrumbs.ai/

Webdraw é do pessoal da Deco.cx, trabalhamos juntos na VTEX e atesto que os caras são absurdos. A abordagem deles: Um quadro tipo Miro onde você rabisca o que quiser, escreve aqui e ali textos explicando interações e comportamentos, e ele cria o código na tecnologia que você escolher. Quer editar? Ou mexa no quadro ou vá pedindo melhorias via chat. O negócio é mágico e estranhamente viciante: https://webdraw.com/

Me ache

Próximos eventos onde estarei palestrando

Conexão PM3 - 27 de Fevereiro 18:30 - FIAP Paulista

No primeiro evento presencial da PM3 em 2025 estarei falando sobre “Pessoas de Produto que geram Impacto”. Uma hora de palestra, 30 minutos de perguntas, e uma bela chance de fazer networking. Inscrição no link: https://lu.ma/fq98eov0

Achou esta news útil? Poste, compartilhe, vamos vencer os algoritmos 😎 

Quer mentoria, palestras ou contar comigo na sua liderança? Veja como trabalho aqui: https://produtoopentalent.com

Ou responda este e-mail

Até o próximo número!