Todos achamos que temos uma grande ideia, até que o mercado diga o contrário.
Confira trechos retirados do artigo escrito por Stefan Scerri, da equipe do aplicativo Hotjar.
Scerri apresenta os 4 erros que considerou como cruciais para o fracasso do aplicativo e os seis passos que devem ser adotados para evitar que os erros tornem a repetir.
Essas são as 10 lições aprendidas com o episódio:
1. O nascimento de um aplicativo móvel
O Hotjar, lançado em 2014, caiu nas graças dos clientes, que podiam usar funcionalidades como mapas de calor, gravações, funis de conversão e pesquisas de feedback para obter informações sobre seus sites e aplicativos da web.
Foram esses mesmos usuários que pediram por uma versão SDK com as mesmas funções para aplicativos móveis.
Problema: desenvolvimento de sites e aplicativos móveis são dois mundos diferentes. A empresa não tinha desenvolvedores de produtos SDK (Software Development Kit).
Solução da equipe: criar a própria versão do aplicativo do Hotjar, ignorando a sugestão dos clientes de criar um SDK.
Foi esse, para o autor, o primeiro erro da empresa:
Erro nº 1: Não validar a ideia antes de desenvolver
Como havíamos escrito acima: os clientes queriam um SDK e não um aplicativo móvel e ninguém havia solicitado um aplicativo do Hotjar. Também não houve nenhum tipo de pesquisa básica perguntando se os usuários gostariam de um aplicativo e quais as funcionalidades que eram imprescindíveis para esses usuários. Se essa pergunta fosse feita, possivelmente o retorno seria que os usuários gostariam de ver as gravações no celular. Sem esse feedback, o que a equipe fez: descartou as gravações e focou no resto.
Resultado: no lançamento do aplicativo, em 2017, as reações foram mornas e retenção despencou.
Erro nº 2: Subestimamos os recursos necessários para criar dispositivos móveis
Aqui, os erros também se sucederam: primeiro que a equipe subestimou a complexidade de criar um aplicativo e também não considerou os recursos necessários para o suporte que um aplicativo exige. Além da falta de experiência, seria necessário um gerente de produto, equipe de desenvolvimento, atendimento e marketing. Nada disso havia sido planejado.
Erro nº 3: Não focar no que teria maior impacto
Foi durante o processo de desenvolvimento do aplicativo que Scerri assumiu como gerente de produto — até então, a empresa não possuía ninguém nessa função. Pergunta que deveria, mas não foi feita: fazer um aplicativo era mesmo uma coisa importante? A falta de foco em solucionar problemas que eram prioridade para os usuários e não ter pensado em todos os detalhes de produto e execução foram fatores que levaram a equipe ao erro 4.
Erro nº 4 — Não fazer o MVP e perder de vista a meta inicial
Sem o feedback dos usuários, a equipe optou por incluir todos os recursos do Hotjar na versão móvel — menos, como citado, as gravações. O tempo de desenvolvimento também foi mal calculado: em vez de poucas semanas, como previsto, o projeto levou meses para ser realizado.
Pergunta que deveria ter sido feita: que tipo de MVP ajudaria a equipe a aprender sobre aplicativos para passar a próxima fase: o SDK? A obsessão pelo desenvolvimento foi tão grande que a equipe não conseguiu enxergar o que estava acontecendo. Nesse período seria difícil recuar: o aplicativo estava quase pronto.
A morte do aplicativo
O aplicativo foi lançado em novembro de 2017 e não obteve tração. Um e-mail foi enviado para 1000 usuários interessados em testar a versão beta. Eles brincaram por um breve período de tempo e não voltaram mais. No início de 2018, esse número era de 100 usuários ativos. O aplicativo havia se transformado em um fardo para a empresa. Em Abril, o aplicativo foi removido das lojas. Em junho, o aplicativo estava morto.
Lições aprendidas:
“Se tivéssemos feito as perguntas certas no início, envolvido nossos clientes no processo de desenvolvimento mais cedo e ouvido o que eles disseram a cada passo, o resultado provavelmente teria sido diferente”. Scirre.
O autor diz que deveria ter seguido 6 passos:
Etapa 1: Descobrir se é isso o que clientes desejam.
Ouvir o que os clientes têm a dizer deveria ser o passo 1 para o desenvolvimento de projetos. Usar ferramentas como pesquisas, feedback de clientes, NPS e validação quantitativa de uma ideia. Só depois da resposta de um número considerável de usuários, é possível partir para o próximo passo:
Etapa 2: Validar a ideia diretamente com os clientes — entendendo se é ou não uma prioridade.
Momento de obter uma validação qualitativa. Com freqüência, os clientes podem achar que querem determinada solução, mas, acabam por não usá-la. Perguntar o quanto essa solução é importante para ele, portanto, também é imprescindível. Isso pode ser feito através da comparação e priorização dos recursos que foram pensados. É necessário, também, entender o real problema que essas pessoas estão enfrentando para ter certeza que a solução proposta seja a primeira opção deles.
Etapa 3: validar a experiência do usuário
A última coisa que deve ser feita é criar algo que não resolve o problema dos clientes — que foi exatamente o que eles fizeram com o aplicativo.
Para economizar recursos e desenvolver o produto que as pessoas desejam usar, o ideal é criar um protótipo e testar com os clientes o mais rápido possível. Na empresa de Scirrer, essa etapa não envolve a programação, apenas a interface. O processo envolve sessões de teste de usabilidade do protótipo com cinco ou seis clientes e a obtenção de feedbacks individuais. Esses testes de usuários sano são concluídos com perguntas como:
Qual é a sua opinião sobre isso?
Isso resolve o seu problema?
Você está feliz com isso?
Algo que você gostaria de adicionar?
Esse é um processo iterativo, por isso, geralmente, são realizadas de 3 rodadas de conversas com cada cliente, seguidas por melhorias com base nos feedbacks coletados.
O objetivo é chegar ao ponto em que o sentimento geral seja positivo e em uma pontuação alta na avaliação dos clientes.
Etapa 4: considerar o custo total
Antes de desenvolver o produto é necessário saber o que é essencial para lançá-lo. Não são apenas as horas de desenvolvimento, mas, também de recursos como a necessidade de um gerente de produto, pessoas de apoio, marketing, engenheiros etc. Será necessário ter essas pessoas? Será necessário treiná-las ou contratá-las?
Etapa 5: Definir o MVP
Nesse momento é necessário fazer a distinção entre o que é agradável e o que é necessário e esse não é um processo fácil. O importante nesta fase é cortar qualquer gordura extra e iniciar, o quanto antes, o ciclo de feedback do cliente — quanto mais rápido o feedback for coletado, mais rápido será o processo de melhorias do produto. A partir disso será possível criar e lançar uma versão beta do produto. Nota do autor: ter um gerente de produto dedicado a fazer perguntas difíceis em todas as etapas ajuda a garantir um processo muito mais eficiente.
Etapa 6: Colocar o MVP nas mãos dos clientes
Depois de pronto, é necessário testar o produto com uma pequena porcentagem de clientes. Assim como na fase de validação da experiência, seria necessário fazer as consultas individuas com os usuários para ver como reagem ao novo recurso. Além disso, são enviadas pesquisas para avaliar a experiência do usuário. A regra geral na empresa é: assim que 10% dos clientes classificarem o recurso como 7 ou 8 em 10, ele será oferecido para toda a base de clientes. Como foram feitas as perguntas certas ao longo de todo o processo de validação, a pontuação nesta fase tende a ser próxima daquela obtida quando se entra no mercado.
Importante lembrar: o processo não termina com o lançamento do produto. Ele deve ser melhorado constantemente e, para que isso ocorra, é necessário estar atento ao feedback dos usuários.
Notas do autor:
“Nosso aplicativo morreu, mas deu origem a um novo processo. Falhamos e demorou muito tempo e muitos recursos. Mas nós definitivamente aprendemos o valor do nosso dinheiro”. Scirre
“Nosso processo de validação do cliente agora garante que não exista desperdício de tempo ou dinheiro buscando ideias que consideramos boas. Sabemos que eles são boas e só vão melhorar, porque vieram de nossos clientes”. Scirre
Renato “Minas” Buiatti é educador e cofounder da How.
