Como priorizar o que será analisado em testes A/B?

Como priorizar o que será analisado em testes A/B?

Teste A/B é um tema super quente. E nós aqui da DiTi temos um vídeo ensinando como você pode publicar um teste A/B usando Google Optimize. Porém, neste artigo vamos falar de algo que vem um pouco antes da publicação do teste A/B em qualquer ferramenta.

Vamos falar sobre como priorizar o que iremos testar. Saber priorizar é crucial para squads/equipes hoje em dia, e o motivo é simples: ainda não podemos manipular o tempo. Então, o que nos resta é organizar como iremos utilizar este tempo para realizar ações que devem nos dar duas das coisas mais importantes para uma organização atualmente: resultados e aprendizado.

Atualmente, muitas empresas funcionam nos extremos. Ou tem que testar TUDO, ou não se testa NADA. E muitas vezes isso causa um impacto negativo nas entregas, reduzindo a velocidade da empresa em incrementar o produto ou serviço disponível para os clientes.

Frequência dos testes A/B

Tiago, mas… o que é mais saudável? Testar TUDO?

A resposta sempre é “depende”. Qual a capacidade que você tem para testar hoje? Se a equipe está 100% do tempo testando, quem está implementando as variantes vencedoras?

Equilíbrio é o que queremos encontrar. Da mesma forma que pessoas que fazem dieta não podem simplesmente parar de comer para perder peso, começar a testar 100% das coisas pode ter o efeito contrário e ao invés de tornar testes parte do processo natural nas squads/equipes, você pode causar um efeito reverso e ter pessoas rejeitando a prática.

Frequência dos testes A/B

O equilíbrio é importante também para a saúde financeira da empresa, algumas ferramentas gratuitas, como Google Optimize, tem um limite de testes que podem ser publicados em paralelo. E caso queira passar para a versão paga, a brincadeira fica séria.

  • VWO começa com estimados 200$ por mês, porém no próprio site eles já removeram o pricing fixo para um pricing que vai variar de acordo com a audiência e os objetivos da sua empresa na internet.
  • Google Optimize é gratuito. Já a versão 360 faz parte do Google Marketing Cloud, um contrato muito maior (leia-se mais caro) que apenas a ferramenta de teste A/B.
  • Optimizely, a líder no segmento, começa a conversa com, pelo menos, 3 zeros em dólar ou euro.

Então, uma dica para criar um ciclo eficaz de descobertas é avançar de forma progressiva. Comece com 1 teste por semana, depois de algum tempo, aumente para dois e assim sucessivamente até, de forma saudável, ter uma cultura de testes.

Frequência dos testes A/B

Algumas empresas como Booking.com, Amazon.com, Airbnb e Netflix são super reconhecidas pela sua capacidade de realizar testes. A Booking tem, inclusive, um motor de teste A/B próprio, que é o ingrediente secreto da empresa. Tudo é testado, e o mais importante: a cultura da empresa já gira em torno disso.

Então, para as empresas que ainda não estão neste nível, tentar testar tudo pode ter o efeito inverso do esperado e tornar a empresa mais lenta. Porém, temos uma ferramenta para ajudá-los a priorizar o que testar.

Canvas de priorização de hipóteses

Canvas de priorização de hipóteses

Criada por Jeff Gothelf, a matriz é dividida em 4 quadrantes:

1) Testar

Neste quadrante, as hipóteses podem ter um alto retorno positivo, porém também apresentam riscos significativos. Estas hipóteses merecem um experimento para aprendermos mais sobre e descobrirmos se estamos no caminho certo.

2) Entregar e medir

Temos um nível alto de confiança de que estas hipóteses irão entregar valor para o negócio e para o cliente. Vamos construir, lançar e mensurar, sem gastar esforços do ciclo de descobertas.

3) Não testamos. Normalmente não desenvolvemos

Estas hipóteses não adicionam valor e têm um baixo risco, não necessitando de esforços do ciclo de descobertas. Porém, às vezes, ideias que caem aqui são necessárias para a operação do negócio. Não são um diferencial, mas precisamos delas para estar no jogo. Por exemplo: sistema de pagamento, políticas e privacidade, entre outras.

4) Descartar

Estas hipóteses têm pouco valor percebido e trazem um risco potencial parao negócio ou produto. Não investiremos mais tempo nelas.

E dois eixos, sendo eles:

Nível de valor percebido

Qual o impacto desta hipótese na experiência com o produto/serviço? E para o negócio, qual o impacto?

Algumas perguntas para ajudar a definir se tem alto ou baixo valor percebido:

  • Quais métricas/resultados esta hipótese pode impactar?
  • Qual ou quais evidências mostram este potencial alto valor?
  • Por que acreditamos que tem alto valor?
  • Este tema apareceu em alguma pesquisa com clientes?
  • Faz parte da estratégia da empresa? Como?

Nível de risco

Qual o risco desta hipótese para a experiência e para o negócio?

Algumas perguntas para ajudar a definir nível de risco:

  • Quão sensível é o perímetro desta hipótese e por quê?
  • Caso dê errado, quanto isso afetará a experiência para os clientes?
  • Caso dê errado, quanto isso afetará nos negócios?

Este canvas pode ser preenchido em um workshop interativo de uma hora, para aproveitar a inteligência coletiva, onde a soma das partes é maior que o todo. Entre os possíveis participantes, podem estar:

  • Product Owner/Manager ou a pessoa que toma decisões de produto, estratégia;
  • Equipe que trabalha diretamente no produto ou serviço (UX, developers, QA, etc).

Este canvas também pode ser preenchido em uma sessão apenas com o Product Owner, sem problemas.

O mais importante aqui são os argumentos que definem se uma hipótese é percebida com alto ou baixo valor percebido e alto ou baixo risco!

Uma vez definida a hipótese, podemos alimentar nosso backlog seguindo os devidos critérios de qualidade e aceitação para itens que serão entregues ou testados.

Uma dica importante

O que vamos entregar

Ou seja, uma hipótese que tem alto valor percebido e baixo risco. Deve passar pelo crivo de qualidade de coisas que esperamos ser estáveis. Ou seja: código limpo, design consistente, tom e voz adequado, testes de qualidade/usabilidade.

O que vamos testar

Ou seja, uma hipótese que tem alto valor percebido e alto risco. Deve ter um crivo de qualidade mais leve. O objetivo aqui não é ter o melhor código do mundo, o melhor design do mundo. O objetivo aqui é aprender a melhor forma de realizar esta hipótese no menor tempo possível para aprendermos com mais velocidade. Este é o maior desafio para as equipes, normalmente vemos empresas construindo testes com o mesmo critério usado para construção de funcionalidades e melhorias. Por ser um teste, o objetivo é termos mais variações que resolvem a mesma hipótese e desenvolver da forma mais simples possível para funcionar. No caso de uma das variantes se provar vencedora, a hipótese deve ganhar prioridade para receber todos os finos tratos necessários para se tornar estável.

No caso onde a hipótese é inconclusiva ou carrega resultados negativos, o fardo de ter desperdiçado tempo e energia em algo que se provou inútil não existe. Pois foi investido pouco tempo lapidando a hipótese e suas variações.

Dica de ouro

Conforme testes vão acontecendo e resultados aparecendo, você pode dar um zoom out no seu ciclo de descoberta e medir algumas coisas como:

  • Tempo para publicar um novo teste;
  • Número de testes publicados por mês;
  • Taxa de testes com uma variante vencedora (win rate).

As duas primeiras métricas vão te ajudar a melhorar o processo de descoberta e aplicação de testes de forma organizacional. Ou seja, qual a eficiência para o processo de descoberta?

Já a última métrica vai te dar uma ideia de eficácia no processo de descoberta, e é onde você vai ser capaz de definir o retorno que o investimento de tempo e energia em um ciclo de descoberta guiado por testes traz para a organização. Esta última métrica deve ser lida da seguinte forma:

Nosso win rate é de 25%, ou seja, a cada 4 testes, 1 traz resultados significativos para a experiência ou o negócio. A cada 4 testes, 3 nos ajudam a não perder tempo à toa ou a evitar inserir funcionalidades que prejudicam a experiência ou o negócio.

Respeitando estas premissas, não tem como dar errado. Inserir um ciclo de descobertas para apoiar o processo de evolução de um produto/serviço é mais simples do que parece e os seus resultados são impressionantes: ou ganhamos ou evitamos desperdiçar.

Curtiu este conteúdo? Conta aqui nos comentários!

Ah, nós da DiTi podemos te ajudar a inserir em sua empresa, de forma saudável, um ciclo de descobertas. Caso queira seguir por conta própria, nós traduzimos para o português o canvas de priorização criado por Jeff Gothelf. :)

Leia também: