Seu time de produto não é ágil, mesmo usando agile

Published in

Ship It!

7 min readJul 10, 2018

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:

Segundo Marty Cagan, “existe uma diferença enorme e indesculpável entre os melhores times de produto e a média dos times”. E essa diferença começa em ser de fato ágil. Nesse momento imagino que você esteja dizendo “mas nós somos ágeis, nós usamos a metodologia XYZ, nosso throughput é ABC..” e por aí vai. Eu não culpo você, eu também achava isso. Mas o workshop do Marty mudou um pouco a minha percepção e elevou a barra do que é ser um time de produto ágil.

A diferença indesculpável

Essa grande diferença que ele menciona é o time de produto ser missionário ao invés de mercenário. Times missionários são aqueles centrados em um objetivo de negócio, enquanto times mercenários fazem as funcionalidades que o PM ou o time executivo manda. No post OKRs versus roadmaps em times de produto falo em como os times devem focar em outcome ao invés de output. E output é justamente onde a maioria dos times ditos “ágeis” concentram sua atenção. O resultado disso geralmente é entregas mais rápidas, porém que não entregam valor suficiente para o cliente e para o negócio. Quem aqui nunca lançou uma feature que foi pouco usada que atire a primeira pedra.

“Grandes times fazem 40 iterações por semana”

É bem comum que o foco em agilidade no time de produto se concentre apenas no quadradinho vermelho da imagem acima, ou seja, só nas fases de desenvolvimento, teste e deploy. Enquanto o resto do processo de discovery muitas vezes acaba sendo bastante cascateado, com hand-offs de uma pessoa pra outra (i.e. PM entrega o estudo do problema para o UX designer criar a solução, este por sua vez faz hand-off da solução para o time de dev). Para Marty Cagan um bom time de produto deve fazer +40 iterações por semana — até porque quantidade sempre vence qualidade — e fazendo agile só no desenvolvimento do software não vai permitir tantas iterações nessa velocidade.

“Um MVP de 3 meses não é um MVP”

A chave pra fazer +40 iterações por semana é obviamente diminuir o tamanho das iterações. Marty dá um ótimo exemplo que aconteceu com o Google Glass: Tom Chi, então PM do Google Glass, ao chegar no projeto viu que a equipe tinha a ideia de fazer a iteração do usuário com o Google Glass via gestos, mais ou menos como Tom Cruise no Minority Report:

Para testar essa hipótese, o time queria fazer um protótipo do Glass que ia levar 2 meses para ser feito. Tom Chi disse que não era uma boa ideia fazer um protótipo tão grande assim e desafiou o time dizendo “como podemos testar isso hoje?” Hoje? O time ficou espantado, era impossível, o protótipo levaria um dia só pra vir da fábrica quando estivesse pronto. Mas ele não arredou pé, continuou insistindo que era preciso testar aquela hipótese naquele dia.

Como o time resolveu o problema de testar aquela hipótese de interação em um dia? Eles conectaram um computador a um projetor e, para simular a interação com as mãos, fizeram uma espécie de luva com elásticos que estava ligada a uma caneta e um passador de slides. Assim era possível ter a sensação de passar as imagens projetadas na parede com o movimento das mãos. O resultado foi bem claro: todos que testaram o protótipo reclamaram de dor nos braços. A hipótese da interação estilo Minority Report estava invalidada, imagine se o time tivesse levado 2 meses para descobrir isso ao invés de 1 dia? Vale lembrar que esse ainda era um produto de hardware, que é bem mais difícil de prototipar, qual é a sua desculpa para não estar iterando mais rápido?

Note que não foram só PM e UX que participaram do discovery do Google Glass. Segundo Cagan as melhores ideias costumam vir dos engenheiros, pois eles têm mais noção do que é possível hoje.

Os 4 tipos de risco que você deve endereçar em discovery

Não adianta fazer +40 iterações se você não sabe o que está testando. Cagan recomenda olhar especificamente para 4 tipos de risco e mitigá-los na fase de discovery:

Risco de valor: as pessoas vão usar/comprar? Esse é um dos riscos principais, pois nada mais importa se a solução não resolve o problema do usuário. Surpreendentemente é um dos riscos mais negligenciados, visto a quantidade de vezes que é lançado um produto ou funcionalidade que tem baixíssima adoção.
Risco de usabilidade: as pessoas conseguirão usar? Esse aqui foi o risco que estava sendo avaliado pelo protótipo Minority Report do Google Glass e que de fato foi provado que a solução não tinha boa usabilidade.
Risco de viabilidade: conseguimos construir isso? Temos os recursos e conhecimentos necessários? De nada adianta você fazer um produto fantástico de teletransporte se não é possível construir um teletransporte.
Risco de negócio: nossos stakeholders vão apoiar isso? Quando alterações afetem o negócio como um todo ou outras áreas (i.e. o Adwords, o maior negócio do Google, quase foi vetado pelo time de vendas e o time de engenharia) é preciso ganhar o buy-in ou enfrentar uma revolta dentro da própria empresa.

Um bom exemplo de como esses riscos foram mitigados é o caso das recomendações da Amazon:

O MVP das recomendações de compra da Amazon

O time responsável pelo carrinho de compras da Amazon tinha o objetivo de aumentar a média de valor das compras realizadas. Observando alguns usuários, eles notaram que, por exemplo, ao comprar um laptop o usuário demorava bastante para escolher o computador ideal, mas logo depois ele usava mais tempo para comprar acessórios pra ele, como uma capa e uma bateria extra para aquele modelo. Então eles tiveram a hipótese de que poderiam melhorar a vida do usuário oferecendo recomendações de produtos comprados com frequência em conjunto e também aumentar o ticket médio de cada carrinho ao oferecer essas sugestões.

Porém um motor de recomendação demoraria meses para ser feito. Como eles poderiam testar suas hipóteses rapidamente? Ao invés de construir um motor de recomendações, o time escolheu 3 laptops aleatoriamente e olharam manualmente no banco de dados o que os clientes mais compravam com cada um dos 3 computadores. Então eles inseriram as sugestões hard-coded só naqueles 3 produtos. Então fizeram um teste A/B, onde a versão com as sugestões era mostrada para cerca de 1% dos clientes.

Na época recomendações não era um padrão de mercado, então havia muitos riscos envolvidos. Com esse pequeno MVP eles mitigaram o risco de valor (o cliente vai usar a funcionalidade?), o risco de usabilidade (o cliente vai conseguir comprar? Esse “passo extra” vai gerar fricção no processo de compra?), o risco de viabilidade (conseguimos realmente construir uma formula que apresente itens relevantes para o cliente?) e o risco de negócio (vai gerar mais vendas e aumentar o ticket médio pra Amazon, logo ninguém dentro da empresa vai nos crucificar por isso?)

Depois de tudo isso provado, ficou bem fácil decidir construir a funcionalidade de recomendações, mesmo que levasse 4 meses pra ficar pronta. Será que nós temos tantas provas de que uma nova feature vai funcionar quanto o time deste exemplo teve?

Curtiu? Clica no ícone das palmas e acompanhe o que eu escrevo aqui.