Construir mais rápido não significa decidir melhor

Quando construir ficou fácil e barato, a skill que sobra é outra: **saber o que vale a pena fazer e quando parar.** [](https://youtu.be/YFdFy3pJm-g) ## Defensável, mas será que é bom? O ponto de partida desta conversa foi o texto [*Defensible, but not Good*](https://newsletter.weskao.com/p/defensible-but-not-good), de Wes Kao — coach executiva, cofundadora e professora na Maven. O argumento dela: > Muito do trabalho de produto parece a coisa certa de fazer. É defensável. Mas a gente deveria se perguntar se aquilo é de fato bom, se deveria estar sendo feito. Os exemplos dela são óbvios demais para quem viveu produto: - Esperar o pico de abandono para melhorar um fluxo. - Esperar o cancelamento de e-mail explodir para reescrever o e-mail. O trigger do trabalho vira o momento em que já deu errado. Em times por onde passei, a gente tinha um bloco nas reuniões chamado **"obviedades não óbvias"**: coisas que você não precisa esperar todos os indícios para agir. O avião não cai só por mau tempo ou só por erro do piloto. Tem sinais antes. O piloto não descobre que o avião está caindo só quando ele embica para baixo. > Folks, we can use our eyes here. Você passou pelo fluxo. Viu que está ruim. Precisa mesmo de mil tickets no atendimento para mudar? ## Ser "analítico" não é esperar dado para tudo O mercado valorizou demais o perfil analítico. Todo mundo olhou para a Booking e quis resolver tudo com teste A/B. Aí veio o 8 ou 80: se pedem pessoas analíticas, o time decide que toda decisão precisa de dado quantitativo. Instrumentaliza tudo. Roda teste para tudo. Mas ser analítico também é ser crítico. As duas coisas andam juntas. O Aíquis gosta mais do termo **data-informed** do que de data-driven. E vai além: > Teste A/B deveria ser exceção, não regra. Startup B2B, principalmente, quase nunca tem coeficiente estatístico no prazo que o negócio precisa. Na InstaCarro a gente fazia teste atrás de teste, mas o princípio era **velocidade de aprendizado**. A gente não esperava significância estatística para saber se a versão estava certa. Em uma semana corrigia uma etapa, na seguinte já era outra. O resultado: **+60% de conversão**. Tem um ponto histórico aí. Cinco anos atrás, dizer isso numa entrevista era risco — a job description pedia "experiência com A/B". Dá para contar nos dedos quem de fato rodou A/B em escala, do jeito Booking. Muita gente fazia freestyle tentando replicar o que via de fora. E hoje o resultado é gente que trava na decisão porque por anos ouviu que decisão sem A/B não conta. ## Tomada de decisão é skill básica — e precisa de ownership Conversando com uma mentorada, diretora de uma grande empresa, sobre a dificuldade que PMs e GPMs ainda têm de decidir, cheguei a esta conclusão: tomada de decisão está no **checklist básico de pessoa de produto**, junto com comunicação e priorização. Só que ownership não se ensina fácil. E o mercado, por muito tempo, valorizou outras coisas: a camada de cima decidia, o PM executava. Repertório importa. Na Yellow, quando lançamos os patinetes, o fluxo de bloqueio e desbloqueio era o oposto do da bicicleta. Não deu tempo de fazer todos os testes que a gente queria. Antes de ir ao ar, mapeamos os sinais do que poderia dar errado: - Funil de finalizar viagem - Chamados novos no atendimento Qualquer desvio pequeno tinha forte chance de vir daquela mudança. A pessoa de produto precisa conhecer produto, cliente, mercado e as consequências. **Feeling sem bagagem é chute. Feeling com repertório é julgamento.** Outro ponto do Aíquis: em time bom, não faltam ideias boas. O difícil não é validar *se* a ideia é boa — é o timing. Entre várias ideias boas, com a meta do quarter na mesa, você escolhe se quer tiro no pé ou na mão. E por muito tempo o PM foi treinado a falar não de cara, para proteger o backlog. Em geral, o que as pessoas trazem faz sentido. **A pergunta é se é para agora.** ## Revisitar o roadmap durante o quarter Depois que a estratégia passa pela cúpula do trovão, o automático é executar. Quantas vezes você revisita o roadmap **durante** o quarter, e não só no fim? Se você monta um sistema para revisitar uma vez por semana, no fim do quarter terá feito isso 12 vezes. Se revisita só no fim do mês, cai para 3. Quatro vezes menos. > "Fui lá, preparei a estratégia, desdobrei no roadmap, aprovei com a diretoria. Agora vamos tacar pau na execução." Altamente defensável. Mas no meio do caminho a premissa pode ter mudado. O Facebook copia a feature. A Apple atualiza o iOS. O mundo que você planejou não é o mesmo em que você executa. Um bom exemplo é o caso da **Centeni**. Eles fecharam a empresa, devolveram parte do dinheiro aos investidores e publicaram um [post mortem bem detalhado](https://www.leitedecabra.com/p/startup-post-mortem-centeni). Perderam convicção na tese. O host do Aura e investidor comentou que o memo da tese ainda fazia sentido — investiria de novo na ideia. Na práti