No último texto, falamos sobre o quanto é importante ter a tranquilidade de errar, desde que seja da forma correta. E começamos a mostrar alguns estudos de casos de testes feitos pelo pessoal da TelTech, uma empresa de apps inovadores para celulares, demonstrando alguns tipos de erros para que vocês vejam como aprender com os erros dos outros empreendedores.
Como vimos, alguns erros podem ser evitados se entendemos as histórias dos outros empreendedores e temos uma visão crítica dos erros, para melhorar nosso processo como startups e empreendedores.
Vamos ver mais alguns casos, então?
Estudo de Caso 2: Uma falha de comunicação
Nome do teste: Promoção de upgrade automático para TrapCall (TrapCall desbloqueia números privados e protege contra ligações indesejadas)
Hipótese: Ao atualizar automaticamente os usuários do Basic para o Premium por uma semana, aumentaremos a retenção em 5 a 10% e levaremos de 3 a 5% a mais de upgrades pagos.
O que estávamos tentando fazer
Um dos dilemas interessantes do SaaS é que muitas vezes seus melhores recursos de retenção são destinados a seus planos mais altos, mesmo que a maioria dos consumidores selecione seu plano mais baixo para ver se o produto é valioso para eles. Embora os modelos freemium lidem com isso expondo você ao conjunto completo de recursos desde o início, eles nem sempre são práticos.
Para nós, isso significou que muitos de nossos assinantes de plano básico cancelariam suas assinaturas antes de sua primeira renovação. Estávamos relativamente otimistas de que, se pudéssemos encantar nossos usuários com recursos de retenção mais atraentes no momento certo, poderíamos mudar essa dinâmica.
Foi fundamental para a experiência que a atualização gratuita que damos a nossos usuários fosse iniciada antes e depois da data de renovação mensal do usuário. Para conseguir isso, teríamos que invadir nosso processo de faturamento para faturar um usuário no nível de assinatura escolhido, e não no nível de assinatura promocional artificial.
Onde tudo deu muito errado
O DEV do projeto não entendeu as nuances do teste e, quando se deparou com a complexidade do sistema de faturamento, tomou a decisão de mudar a data de início da promoção para 10 dias antes da renovação do usuário. Ele nunca comunicou essa decisão ao dono do teste, que teria explicado que isso interromperia o experimento.
Os resultados do teste foram terríveis. Assistimos a um pequeno aumento nos upgrades, mas aceleramos significativamente os cancelamentos. Apenas algumas semanas depois, enquanto analisávamos alguns dados, descobrimos o que realmente aconteceu.
O que você pode aprender com isso?
A mentalidade de crescimento é construída em velocidade e agilidade, mas a eficácia do processo depende da boa comunicação da equipe. Na época, nossa equipe de desenvolvimento era um recurso compartilhado em todo o nosso portfólio. Por isso, o DEV não estava incorporado à equipe de crescimento da TrapCall. Ele não tinha propriedade direta do sucesso do experimento.
Ensinar a todos em sua organização seu papel no crescimento é a melhor maneira de facilitar boa comunicação através do processo de experimentação. O trabalho de um DEV não é apenas escrever código, é escrever código que garanta que a hipótese de um experimento possa ser medida.
Além disso, você pode ver que até mesmo uma pequena falta de comunicação pode inviabilizar completamente um teste. Você precisa ser capaz de confiar nas pessoas para tomar boas decisões sobre a melhor forma de atingir as metas, mas você precisa facilitar as discussões da reunião de time para garantir que essas decisões não sejam tomadas sem nenhum cabimento.
Estudo de Caso 3: Uma falha de processo
Nome do teste: Teste Grátis da TrapCall
Hipótese: adicionando um teste gratuito de uma semana ao TrapCall, aumentaremos as inscrições em 4X, convertendo 50% dos testes em assinaturas pagas, dobrando assim as novas inscrições de usuários, mantendo nosso LTV médio.
Por que pensamos que isso seria uma boa ideia
Ficamos entusiasmados com este teste porque ele já estava dando certo para o RoboKiller, nosso aplicativo que interrompe as chamadas de telemarketing no iPhone. Assim, com um MVP muito simples e um mínimo de recursos, lançamos rapidamente o que achamos que seria um ganho infalível.
Quase imediatamente, vimos alguns resultados encorajadores em termos de inscrições e valor médio do pedido, mas sabíamos que não poderíamos medir as conversões de usuários pagos com uma semana de teste grátis.
Quando percebemos o erro
Depois de uma semana, vimos que nossas conversões eram zero, mas não porque as pessoas não queriam o TrapCall. Descobrimos que nunca nos demos a chance de converter usuários de teste porque não estávamos salvando as informações de cartão de crédito que precisaríamos para cobrar os usuários no final do teste. Nós estragamos tudo e isso nos custou um pouco de receita.
Nossa cultura não é sobre culpa, que é uma das coisas que realmente amo na TelTech, mas estamos muito focados em aprender com nossos erros. Então começamos a olhar para o colapso. Obviamente, o código de backend deve ter apoiado a compra, mas nossos desenvolvedores também contam com o controle de qualidade para garantir que tudo funcione corretamente.
O departamento de controle de qualidade achava que eles só podiam testar as interações de inscrição iniciais devido ao atraso de uma semana entre a inscrição e a conversão. O pagamento atrasado nunca foi testado. Por fim, percebemos que nosso processo tinha falhas e aprendemos que precisávamos fazer ajustes. Agora, a partir dos nossos documentos de visão, sabemos exatamente o que é a “Definição de Feito” para cada stakeholder e nos certificamos de que podemos testar cada elemento antes de começarmos.
O que você pode aprender com isso
Nem todo teste será simples. Até um MVP pode ter muitas partes móveis. Com cada camada de complexidade, você provavelmente adicionará mais interessados. Enquanto isso acontece, é muito importante que seus processos tenham um grande foco em garantir que a boa comunicação flua entre a equipe e a organização. É fácil ficar complacente e simplesmente fazer testes para ver o que acontece, mas essa é uma abordagem perigosa quando tempo e dinheiro estão em jogo.
No fim das contas…
Obter um alto impacto é o objetivo real do teste de alta velocidade. Você pode executar muitos testes ruins e chamar testes de alta velocidade ou você pode executar muitos testes bons e obter o impacto de crescimento que é seu objetivo final.
Estar errado sobre a sua hipótese não é um erro, é o resultado provável da maioria dos testes. Falhar na sua abordagem de experimentação, no entanto, é definitivamente um erro… e muitas vezes custoso.
De hipóteses falhas e desenvolvimento ruim a supercomplicação e má comunicação, mostramos algumas das maneiras que o pessoal da TelTech arruinaram algumas de suas experiências. Você pode aprender com cada um desses erros para aumentar a probabilidade de seus próprios testes serem bem-sucedidos.
Com um pouco de sorte, você cometerá erros diferentes, mas, no final das contas, se o seu processo for eficaz, você verá essas falhas como parte do crescimento da sua empresa.
Texto adaptado de Here’s how you ruin an experiment
