Primeiramente vale dizer que, na verdade, a ideia de uma funcionalidade flopada depende muito do contexto e cultura de produto na qual você está.
Se você está em uma cultura que preza muito pelas entregas (os famigerados outputs), aí não tem flop. Se você lançou, independente de qualquer coisa, já é um sucesso. A não ser que a funcionalidade flopada em questão tenha ido para produção toda bugada. Porém, o objetivo aqui é falar de proposta de valor e não de qualidade e capacidade de desenvolvimento técnico.
Por outro lado, se você está em uma cultura que preza pelos resultados (mais conhecidos como outcomes), o mínimo de resultado que você tem que ter é uma boa adoção da sua funcionalidade pelos usuários para os quais essa funcionalidade foi construída.
Todas as outras métricas de produto, como retenção, satisfação e monetização derivam dessa adoção inicial. Afinal, se os seus usuários não usam pelo menos uma vez a sua funcionalidade é impossível medir qualquer outra métrica.
Afinal, o que é a adoção?
É muito importante aqui definirmos de antemão o que é adoção de funcionalidade. De um modo bem simplista ela pode ser definida da seguinte maneira:
Porcentagem de usuários do seu target que utilizaram a funcionalidade ao menos uma vez.
Não são todos os usuários do seu produto! É a porcentagem do seu target. Afinal, geralmente, funcionalidades não são construídas para todo mundo.
Quando usuários adotam a funcionalidade significa que eles viram o potencial que de alguma forma a nova funcionalidade vai resolver o problema deles. Ou seja, adoção é um indicador do quão bem você apresenta a funcionalidade dentro do seu produto e comunica a sua proposta de valor.
Por exemplo:
Para a funcionalidade de passar os vídeos das séries automaticamente dentro da Netflix, a adoção pode ser deixar passar automaticamente pela primeira vez. Para a NuConta, pode ser depositar pela primeira vez uma quantia de dinheiro. Para a sessão de podcast do Spotify, pode ser ouvir mais de um minuto de qualquer podcast.
Eu considero que uma adoção baixa é abaixo dos 40%, uma adoção média é entre 40 e 60%; e uma adoção alta tem que ser acima de 80% do seu target populacional.
Entendendo o contexto
Antes de entrarmos nos detalhes, me acompanhe em uma breve história.
Você, jovem Product Manager, está pronto para lançar a funcionalidade queridinha da sua liderança. É o seu primeiro lançamento.
Entre trancos e barrancos você fez o Discovery mais rápido possível para poder entregar a funcionalidade dentro da “expectativa de lançamento” da diretoria. O desenvolvimento técnico correu surpreendentemente bem, afinal realocaram os desenvolvedores mais seniores da equipe de engenharia.
O time de Marketing já fez o press release e já tem o evento de lançamento com data marcada. Inclusive, o time de Atendimento e Customer Success já tem as FAQs fechadas, treinamentos prontos e o canal de feedback do cliente no aguardo.
Você seguiu o playbook inteiro da sua organização, nenhuma ponta ficou solta, a ansiedade da empresa está a milhão, todos estão aguardando o lançamento que vai insurgir o mercado. Uma vez aprovado o merge request, a sua funcionalidade finalmente está em produção.
Após um tempo da funcionalidade em produção e todos os ritos de go-to-market cumpridos, você vai olhar os resultados:
E de 100% do target de adoção previsto da funcionalidade lançada, ela atingiu inesperados 2,3%.
A sua funcionalidade infelizmente flopou.
Sabemos como a banda toca nesse casos: quando as coisas dão certo é glórias do time e da empresa, quando as coisas dão errado é culpa da pessoa de produto. Aqui eu vou atacar qual é o papel da pessoa de Produto nessa confusão toda e como ela consegue se organizar sobre a pressão por respostas.
As 4 possíveis razões de baixa adoção
Normalmente, existem 4 razões pelas quais a adoção de funcionalidades não atinge o resultado esperado:
- Falta de conscientização;
- Problemas de descoberta;
- Alto atrito;
- Proposta de baixo valor.
Falta de conscientização
A falta de conscientização geralmente é um problema de go-to-market que pode ser resolvido por meio de otimizações, como comunicar a funcionalidade aos usuários por meio de esforços de marketing ou notificações no aplicativo.
Então não é culpa do time de Produto? Calma lá, jovem. Sempre sobra para o gerente de produto. Primeiro, você tem que provar que é a falta de conscientização, depois a gente conversa de quem é a culpa. Mas daqui a pouco eu falo como a gente prova.
Problemas de descoberta
O próximo problema que pode ter deixado sua funcionalidade flopada está na descoberta. Aqui os usuários não encontram a funcionalidade na interface do produto. Inclusive, muito comum em produtos mais robustos e complexos.
Geralmente, é um problema de hierarquia da informação e usabilidade como um todo. Sabe aquele menu hambúrguer que tem dezenas de funcionalidades com hierarquia baseada no gosto da diretoria? Pode ser um dos problemas.
Para resolver esse problema basta otimizar a capacidade de descoberta através de ações como:
- Mover a funcionalidade para um local mais visível e intuitivo na interface;
- Fornecer mais tutoriais, construir um passo a passo mostrando onde a funcionalidade está;
- Simplificar a interface.
Alto atrito
Outro problema é a fricção, com isso geralmente se faz essa pergunta: existem barreiras que impedem o usuário de usar a funcionalidade?
Para isso existem dois tipos de barreiras, a física e a cognitiva. As quais podem ser passos extremamente longos, algum bug, alguma palavra mal utilizada, uma configuração necessária, informação não facilmente acessível, entre outras.
Existem 3 otimizações principais para reduzir esse atrito:
- Simplificar e facilitar a conclusão da tarefa;
- Educar os usuários sobre os benefícios, para ajudá-los a superar o atrito;
- Criar tutoriais de configuração.
Proposta de valor baixa
É aqui que o filho chora e a mãe não vê. Porque no fim, o verdadeiro trabalho do gerente de produto é entregar valor para o negócio ao entregar valor para o cliente.
E aí fica a grande pergunta: nossos clientes acreditam que estamos resolvendo um problema significativo para eles?
É possível que parte do público-alvo que definimos não tenha o problema de que falamos, levando a taxas de adoção para patamares ainda mais baixo. Aqui, primeiro consideraríamos de saber se o público-alvo foi definido de forma muito ampla, ou seja, você foi muito guloso e otimista na definição. Em seguida, otimizaríamos a funcionalidade para atender um público-alvo mais restrito.
Se isso não mudar significativamente a adoção, talvez tenhamos que revisitar a oportunidade da funcionalidade como um todo e redesenhar ou até mesmo reverter a funcionalidade.
Qual dos problemas estou enfrentando?
Talvez só um. Mas possívelmente todos, em aspectos e impactos diferentes.
A grande questão aqui é formar um plano de ação para que você ataque as oportunidades mais latentes. Para entender quais dessas forças potenciais está gerando uma baixa taxa de adoção, podemos realizar análises quantitativas e pesquisas qualitativas.
Vou focar na quantitativa. As ferramentas de análise quantitativa incluem:
- Avaliar os painéis de desempenho e relatórios de bugs. Isso nos ajudará a identificar se há algum problema técnico ou bug que esteja criando atrito e impedindo os usuários de usar a funcionalidade;
- Analisar erros, tempos de carregamento e outras métricas de desempenho como possíveis sinais de atrito;
- E o mais legal e impactante de todos: pesquisas com usuários para entender porque os usuários não estão adotando a funcionalidade. Uma abordagem comum é usar uma pesquisa de múltipla escolha ramificada.
Vamos ao exemplo novamente:
Digamos que você seja PM da Netflix e foi responsável pelo lançamento da funcionalidade de ver vídeos em grupos de pessoas ao mesmo tempo e em locais diferentes, a chamada sessão em grupo.
Você fez o lançamento e ela naturalmente flopou. Após verificar todos os passos que escrevi anteriormente você vai lançar a seguinte pesquisa quantitativa para quem não adotou dos seus usuários target:
- Você sabia que pode criar uma sessão em grupo?
- Não → Falta de conscientização
- Sim → Próxima pergunta
- Você sabe como iniciar uma sessão em grupo?
- Não → Problema de descoberta
- Sim → Próxima pergunta
- Você já tentou utilizar uma sessão em grupo?
- Não → Problema de fricção ou proposta de valor
- Sim → Próxima pergunta
- Quais são as suas dificuldades ao iniciar uma sessão em grupo?
- Forneça um campo aberto para feedback qualitativo
Formulário simples, direto e rico de informações para você tirar todas as conclusões necessárias para o seu plano de iteração da funcionalidade.
Como gerar aprendizados no lançamento da funcionalidade
Vamos dar um passo atrás e avaliar primeiro o que poderia ter sido feito antes do lançamento para geral.
Ao lançar novas funcionalidade, você pretende aprender sobre 2 coisas, principalmente:
- A funcionalidade realmente criou valor para os negócios e os usuários?
- Alguma coisa está impedindo-a de atingir seus objetivos?
Para responder essas perguntas o quanto antes você pode se valer de uma estratégia importante: lançar parcialmente.
Estágios de lançamentos
Os aprendizados que você pode gerar a partir do lançamento da funcionalidade dependerão de o que você lançar e para quem você a lançará. Joca Torres, em seu livro “Gestão de Produto”, comenta sobre como diminuir os riscos de lançamento através de um lançamento faseado (alfa, beta e go-live).
Alfa
Com uma versão alfa, uma funcionalidae é colocada nas mãos de usuários com os quais você, sua equipe ou sua empresa têm relacionamentos amigáveis preexistentes. Com isso você responde 2 principais perguntas:
- O produto está quebrado ou com bug?
- Os fluxos principais funcionam?
No entanto, essa população de usuários não é boa para falar sobre o valor da funcionalidade (se realmente resolve ou não o problema do usuário pretendido) ou sobre a adoção dela, por 2 razões:
- Esse grupo mais amigável não contribui com um feedback honesto e brutal, no fim eles querem ver o sucesso disso tudo, ou seja, o feedback sobre o valor dessa funcionalidade é extremamente enviesado;
- Esses usuários não refletem fielmente o seu target. Por consequência, eles não são uma aproximação do interesse que um lançamento por completo vai ter.
Beta
Com uma versão beta, a funcionalidade é colocada nas mãos de usuários que se propuseram a participar do processo, seja através de uma lista de espera, um teste em produção anteriormente realizado, ou uma prospecção do time de Customer Success.
Esses usuários estão dispostos a tolerar algum nível de falhas e fornecer feedback de qualidade para orientar melhorias em troca de acesso antecipado a novas funcionalidades e produtos.
Você usará versões beta quando quiser testar a utilidade da sua funcionalidade. Essa população de usuários pode responder perguntas importantes sobre utilidade, como:
- Quão bem resolve os problemas do usuário?
- Existe algumas consequências não intencionais que não foram consideradas anteriormente?
Como esses usuários optam por participar, eles tendem a se inclinar mais para “power users”. Isso significa que eles tendem a ser mais ligeiros, digamos assim, e mais familiarizados com seu produto do que o usuário médio, o que torna o feedback deles não representativo da população em geral.
Go-live
O fato é: quanto maior a base que você lançar, maior o risco que você está tomando. Aí depende da tolerância ao risco que a sua empresa tem frente a lançamentos.
Porém, a única maneira de você lançar uma funcionalidade e testar se ela é usável, possui valor e atinge a adoção programada é através de um lançamento completo.
- Se sua tolerância ao risco for baixa, considere os estágios de lançamento alfa ou beta, porque se as coisas não correrem bem, é relativamente fácil retroceder uma funcionalidade em usuários alfa ou beta;
- Se sua tolerância ao risco for média ou alta, você deverá considerar os estágios de liberação parcial ou go-live. Isso porque é mais difícil reverter as funcionaliades depois de liberá-las para usuários-alvo.
Aí sempre vem essa pergunta: quando eu posso passar de um estágio para o outro?
Acredito que de alfa para beta fica bem óbvio: quando problemas de usabilidade forem resolvidos. Mas e de beta para go-live? Somente quando a funcionalidade atingir o resultado esperado dentro da população esperada.
O resultado pode ser retenção, satisfação, conversão, monetização, indicação, entre vários outros. Quem vai decidir e programar isso o quanto antes é você em conjunto com a sua liderança.
Conclusão
Quando os usuários adotam uma funcionalidade, eles o fazem porque entendem que pode ser valioso para eles. No entanto, eles nem sempre descobrem se funciona corretamente ou se realmente agrega valor até após a adoção. Ou seja, a retenção na funcionalidade e a sua satisfação são tão (ou até mais) importantes quanto a adoção dela.
Em segundo lugar, ter mais adoção nem sempre é o objetivo. As funcionalidades nem sempre são projetados para todos, e fazer com que mais pessoas adotem uma funcionalidade pode tirar o foco do problema que você estava enfrentando.
Por último, as métricas de adoção podem ser infladas artificialmente, forçando os usuários a usar uma funcionalidade por meio de esforços de marketing, como um outdoor no meio da Avenida Paulista, CTAs ou outros fluxos de usuários. Uma funcionalidade ruim pode ter alta adoção se for promovida em excesso e, da mesma forma, uma funcionalidade boa pode não ser adotada se for pouco promovida.
Sendo assim, identificar os motivos de uma funcionalidade flopada e encontrar todo esse equilíbrio no processo é seu trabalho, em conjunto com o time de Product Marketing.
Domine Product Growth
Quer dominar a estratégia na hora de identificar oportunidades de crescimento e alavancar o seu produto? O Curso de Product Growth reúne as melhores práticas da área ao longo de mais de 30 horas de conteúdo aprofundado e com cases reais, compartilhados por instrutores renomados e com vasta experiência em empresas como RD Station, Instagram, OLX e muito mais! Confira agora mesmo a ementa completa!
Leia também:
