Ciclo de produto: como criar cadência e aumentar o poder de execução do time

O grande diferencial de qualquer empresa é o **poder de execução**. E para executar, a chave está em ter um ciclo de produto azeitado. Sem isso, o time cai no discovery infinito, no desenvolvimento infinito e na insatisfação generalizada. Ou naquele outro clássico: o ciclo do "copia porque o concorrente está fazendo", que raramente dá certo.  Uma frase que sempre volta quando falo sobre isso é de Dave Girouard, ex-PM da Apple e ex-presidente do Google Enterprise Apps: > A good plan violently executed now is better than a perfect plan next week. Vale o disclaimer: o que está escrito abaixo é a forma como eu enxergo o problema, com base em mais de dez anos construindo produtos. Não é regra. ## O que é o ciclo de produto O ciclo de produto nada mais é do que um PDCA (Plan → Do → Check → Act) remasterizado. Trazendo para o nosso mundo, ele fica mais ou menos assim:  - **Análise**: identificar uma oportunidade de negócio, uma evolução de produto ou a correção de um bug. Pode ser no nível da squad ou da empresa inteira — no planejamento do quarter, por exemplo. - **Discovery**: o processo para descobrir mais sobre o que foi analisado. E, por favor, não precisa demorar uma eternidade. - **Priorização**: dentre todas essas coisas, o que faz mais sentido [in]validar primeiro. - **Implementação**: desenvolvimento. E, de novo, não precisa demorar uma eternidade. - **Lançamento**: se você está pensando em fazer deploy numa sexta-feira, consulte antes o [shouldideploy.today](https://shouldideploy.today). O grande ponto é: quanto melhor essa engrenagem gira, mais o time aprende, mais repertório acumula e mais o produto evolui. Uma provocação que adoro fazer: > O que você prefere: errar 10 vezes em 3 meses e aprender 10 coisas, ou nesses mesmos 3 meses errar 100 vezes e aprender 100 coisas? Sempre existem exceções. Apesar de não gostar muito do jargão, o que está em jogo aqui é o princípio da coisa. "Errar" não significa que tudo vai dar errado — significa vivenciar o ciclo e repetir, ganhando repertório no caminho. Na Loft, tive a responsabilidade de criar um dos princípios do capítulo de produto e o chamei de **"Fast and Furious"**. O que ele significava? Que era mais produtivo testar, errar e aprender do que ficar discutindo o sexo dos anjos em discoveries intermináveis. Reforçando: isso não era escrito em pedra nem aplicado a tudo. Existiam contextos e contextos. ## O ciclo não nasce azeitado Eu gosto de separar o ciclo nessas etapas justamente para conseguir identificar onde estão os gaps. Os problemas mais comuns por etapa: **Análise** - Dificuldade em fazer análises porque não há dados estruturados. - Dificuldade em gerar hipóteses porque falta conhecimento do produto e do negócio. **Discovery** - Discovery lento porque foi 100% terceirizado para o time de product design — sintoma de que a dupla PM + PD, ou a própria estrutura da companhia, não está bem conectada. - Não explorar maneiras alternativas de fazer discoveries mais rápidos. - Falta de insumos para saber por onde caminhar. **Priorização** - Descolamento de estratégia entre engenharia, produto e design. - Falta de visibilidade sobre por que algo foi despriorizado. - Dar mais importância à pergunta "qual framework usar?" do que à decisão em si. **Implementação** - Queda de braço entre a versão perfeita e a gambiarra. - Time que não entendeu (ou não se interessa pela) estratégia e, por consequência, não tem senso de urgência. - Desenvolver sem saber qual é o objetivo. - Excesso de débito técnico acumulado sem refactories que o enderecem. - Mudanças de escopo dentro da mesma sprint. - PM sem influência dentro do time. - Cobrança e pressão diferentes vindas da liderança para cada disciplina (PM, devs e design). **Lançamento** - Não ser possível fasear o lançamento. - Deploy sempre doloroso, causando problemas em todo lançamento. - Falta de métricas mapeadas para analisar o resultado. - Prazos e datas que nem todo mundo conhece. - Deploys que quebram outras partes do produto. - Falta de informação para os times de suporte, que muitas vezes nem sabem que algo foi lançado. Tudo isso varia conforme o contexto da empresa, a estrutura dos times e a cultura. E um fator pesa sempre: a maturidade dos times e dos stakeholders. ## Qual é um "tempo bom" para cada ciclo A resposta é aquela que você está cansado de ouvir: depende. Mas eis outra provocação que gosto de fazer: > Sabendo que uma squad custa mais ou menos R$ 200 mil por mês, quanto de valor o seu time está gerando por semana? E por mês? A conta usa como base uma squad de 1 PM, 4 devs e 1 product designer. A ideia não é colocar uma faca no pescoço de ninguém — é mostrar a ordem de grandeza e o quanto um ciclo azeitado po