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

Sérgio Schüler
Jul 10, 2018 · 7 min read

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

“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”

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.

Jabá: quer aprender a extrair insights de produto de entrevistas?

Aqui estão alguns dos reviews do curso Jobs-to-be-Done na prática:

Ship It!

Conteúdo, opinião, vivência e compartilhamento de ideias da…

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store