Ciclos de produto e o poder de execução.

Diferenças entre times que entregam e times que patinam

E ai! Esse é mais um post da Brilliant Basics, a newsletter sobre tópicos de produto "sem filtro”, onde semanalmente compartilho um pouco minhas experiências construindo produtos há +10 anos.

PS: antes de iniciar vou reforçar: o que está escrito abaixo é a maneira como eu enxergo e acredito, não é cagaç*# de regra.

Esse artigo tá dividido em:

1. O que é o ciclo de produto?

2. Quais problemas podem dificultar a cadência do ciclo?

3. O que é uma “boa cadência” do ciclo?

4. Exemplos (exclusivo para assinantes)

Eu acredito muito que o grande diferencial de qualquer empresa é o poder de execução.

E para conseguir executar, a chave tá em ter um ciclo de produto “azeitado”, porque se não, acaba caindo naquele ciclo de discovery infinito, desenvolvimento infinito… e todo mundo descontente. Ou, aquele famoso ciclo do “copia pq o concorrente tá fazendo”, que sabemos que não costuma dar muito certo.

The Product Death Cycle - Reforge

Uma frase que sempre me lembro quando falo sobre isso é a do Dave Girouard (que já foi PM na Apple e presidente do Google Enterprise Apps):

A good plan violently executed now is better than a perfect plan next week

Tá… mas o que é esse ciclo de produto?

O ciclo de produto nada mais é que um PDCA (Plan → Do → Check → Act) “remasterizado”. Trazendo um pouco para nosso mundo, fica mais ou menos assim:

Obs: fica aqui meu pedido de desculpas para quem tem problemas com coisas alinhadas 🤷🏽‍♂️

Análise: normalmente identificamos uma oportunidade de negócio, uma evolução de produto ou correção de algum bug. Isso pode ser a nível de squad ou a nível de empresa mesmo, como por exemplo, para o planejamento do quarter.

• Discovery: aquele processo para descobrir mais sobre o que foi analisado (e por favor, não precisa demorar eternamente)

• Priorização: Dentre essas coisas, qual faz mais sentido [in]validar primeiro.

• Implementação: Desenvolvimento (e por favor, não precisa demorar eternamente [2])

• Lançamento: favor checar esse site se você tiver pensando em fazer um deploy na sexta: https://shouldideploy.today

E o grande ponto aqui é: quanto mais essa engranagem do ciclo de produto tiver rodando bem, mais você aprende, mais adquire repertório, e consequentemente, mais evolui o produto.

Uma provocação que adoro fazer para todos times é:

O que você prefere: errar 10x em 3 meses e aprender 10 coisas ou nesses mesmos 3 meses, errar 100x e aprender 100 coisas?

Claro, sempre vão existir as exceções. Apesar de não gostar muito do jargão, o que está em questão aqui é muito mais o “mindset” ou o princípio da coisa. O errar ali também não significa que tudo que você fizer vai dar errado né, é mais o aspecto de vivenciar o ciclo e repetir (e consequentemente, aprender e ganhar repertório).

Por exemplo, na Loft, eu tive a responsa de criar um dos princípios do capítulo de produto, e chamei ele de “Fast and Furious”. E o que ele significava?

Que a gente preferia e era muito mais produtivo testar, errar e aprender do que ficar discutindo o “sexo dos anjos” (ou discoveries infinitos).

Obs: para reforçar mais uma vez, isso não era escrito em pedra e aplicado para tudo, existiam contextos e contextos.

Nem sempre é fácil

É bom deixar claro que o ciclo não nasce azeitado. E eu gosto de separar nessas etapas justamente para conseguir identificar os gaps e onde é necessário agir. Problemas que podem contribuir para a engrenagem não funcionar muito bem:

Análise

• Dificuldade em fazer análises porque não tem dados estruturados

• Dificuldade em fazer análises e gerar hipóteses porque não existe conhecimento do produto/negócio

Discovery

• Demora no discovery porque ele é 100% tercerizado para o time de product design (pode mostrar que a dupla PM + PD ou a estrutura da companhia não tá bem conectada)

• Não explorar maneiras alternativas para fazer discoveries mais rápidos

• Falta de insumos para saber por onde caminhar

Priorização

• Descolamento da estratégia entre engenharia, produto e design

• Falta de visibilidade do porque algo foi despriorizado

• Dar mais importância para “qual framework usar?”

Implementação

• Queda de braço entre versão perfeita vs. gambiarra

• Nem todos os membros do time entenderam ou tem interesse na estratégia e consequentemente, não tem senso de urgência

• Desenvolver sem saber qual é o objetivo

• Excesso de débitos técnicos que não exigem muitos refactories

• Contante mudanças de escopo na mesma sprint

• PM não conseguindo ser influente no time

• Cobrança/pressão da liderança diferente entre as disciplinas (PM, Devs e Design)

Lançamento

• Não é possível “fasear” o lançamento

• O processo de deploy é sempre doloroso e causa problemas em todo lançamento

• Não ter métricas mapeadas para analisar o lançamento

• Nem todos sabem ou tem o senso de urgência de prazos e datas

• Deploys que quebram outras partes do produto

• Falta de informação para times de suporte, que ocasiona em caos e muitas vezes nem sabem que algo foi lançado

Tudo isso sempre vai variar dependendo do contexto da empresa, estrutura de times, cultura e muito mais. Além disso, um fator que sempre influencia aqui sem sobra de dúvidas é a maturidade dos times e stakeholders.

Qual é um “tempo bom” para cada ciclo?

A resposta é aquela que você tá cansado de escutar: depende.

Mas outra provocação que gosto de fazer aos times é:

Sabendo que uma squad custa +- R$200k por mês, quanto de valor seu time tá gerando semanalmente? E mensalmente?

(usando como base 1 PM + 4 DEVS + 1 PD)

A ideia aqui não é colocar uma faca no pescoço do time, mas sim, mostrar a ordem de grandeza e o quanto um ciclo de produto azeitado pode trazer mais valor e aprendizados.

Outro comparativo é: imagine que vc tem sprints maiores que 2 semanas, nesse caso terá menos de 6 “ciclos” em um quarter. (Claro que tem coisas que não são entregues em 2 semanas, mas o ponto aqui é criar essa mentalidade de cadência, aprendizado e retorno)

Mas para não ficar só no “depende” e trazer um tempo médio entre entender/corrigir os gaps para criar uma cadência no ciclo de produto, acredito que pode variar entre 1 a 3 meses. Isso vai depender do tamanho/momento da empresa, cultura dos times e relação entre as áreas (principalmente entre engenharia/produto/design e alinhamento com stakeholders).

Já vivenciei em estruturas menores (3-4 squads), ciclos de produto que passaram a ter cadência depois de um mês de ajustes. E em estruturas maiores (+10 squads), alguns times demorarem cerca de um mês mas outros demorarem quase um quarter. Em caso de estruturas maiores, um ponto super importante é identificar quais são os times que precisam atingir essa “cadência” primeiro.

⚠️ATENÇÃO⚠️

Não conseguir enxergar mudanças/evoluções em até 3 meses é algo beeem preocupante, tanto para a evolução do produto quanto para os cofres da empresa.

(em tempos de layoffs e inverno das startups, é sempre bom relembrar)

Outro ponto também que vai interferir nisso é se é um time novo ou ajustar um já existente. Na minha experiência, times novos atacando produtos novos atingem essa cadência mais rápido. A não ser que os membros desse time novo são pessoas vindas de outros times (trazendo os problemas juntos).

Conclusões

• Quanto mais dias/semanas tem uma sprint, provavelmente menos ciclos e cadência o time terá

• O tempo médio entre identificar e corrigir problemas para ter uma cadência no ciclo de produto é de 1 a 3 meses

• Provocação 1: errar 10x em 3 meses e aprender 10 coisas ou nesses mesmos 3 meses, errar 100x e aprender 100 coisas?

• Provocação 2: quanto de valor seu time tá gerando semanalmente? E mensalmente?

• Calma! Nem sempre você precisa ter todos times na mesma cadência ao mesmo tempo

• Não conseguir enxergar mudanças/evoluções em até 3 meses é algo beeem preocupante.

• Se você é assinante, pode ver com mais detalhes os exemplos e cases reais sobre ajustes ao ciclo de produto e cadência.

Mais uma coisinha

Espero que você tenha curtido o conteúdo e formato desse post! Se curtiu, que tal:

1) Compartilhar esse post com outras pessoas? Assim mais pessoas podem ler e encontrar insights para dar cadência ao ciclo de produto

2) Se você curtiu, aperta ali no coraçãozinho? 😍

3) Me fala o que achou desse post? Seu feedback me ajuda a deixar a newsletter ainda melhor

4. Quem é assinante tem acesso a cases reais (do mercado brasileiro), materiais, templates e muito mais.

Muito obrigado, e até a próxima edição da Brilliant Basics!

Arthur Castro

Exemplos reais

• Empresa 1 (Pequeno porte, time de produto recém-formado)

Tínhamos diversos “verdades absolutas” dos stakholders, débitos técnicos, dificuldade em configurar as ferramentas para fazer testes A/B, além…