Este artigo faz parte de uma série de 3 artigos:
- Medindo o sucesso das funcionalidades por meio da adoção
- Medir a satisfação de funcionalidades é diferente da satisfação de produtos
- Quando e como tirar uma funcionalidade do ar
Eu acredito que os melhores produtos têm uma coisa em comum: eles são simples e possuem uma quantidade bem específica de features.
Vamos pegar 2 exemplos de produtos físicos:
De um lado temos o canivete suíço, que é difícil de explicar, de vender, de aderir e não faz nada bem. Do outro lado temos a tesourinha de cortar unhas, que é fácil de explicar, de vender, fácil de manusear, faz 1 coisa de útil com excelência.
Quantas pessoas você conhece que possuem um canivete suíço? Se conhecer 2, você é uma exceção à regra.
Agora vamos pegar um exemplo de produtos digitais:
De um lado temos o Notes, aplicativo de notas da Apple. Simples e fácil de usar. Do outro lado, temos o Evernote, um aplicativo de notas que costumava ser simples, mas hoje está recheado de funcionalidades (tags, pastas, anexos, visualizações diferentes etc) e apresenta alta complexidade de uso.
Assim como a adoção de uma tesourinha de cortar unhas é maior que a de um canivete suíço, eu não duvidaria que a adoção do Notes da Apple seja maior que a do Evernote.
Meu objetivo com esse artigo é ajudar você a pensar em mensurar as funcionalidades que está criando, para saber se está na direção certa ou se está criando um canivete suíço de baixa adesão.
É muito comum nós pensarmos nos seguintes tipos de métricas quando falamos sobre medir um produto: aquisição, retenção e monetização. O problema é que essas métricas acabam sendo de negócio e se misturam com algumas outras de produto. Portanto, esse acaba sendo um jeito macro de ver as coisas.
Eu acho até curioso, porque as funcionalidades que passamos semanas e meses desenvolvendo acabam não sendo medidas corretamente. Na tabela abaixo fica mais claro a diferença entre medir um produto e medir funcionalidades.
| Medindo produto/negócios | Medindo funcionalidades |
|---|---|
| Aquisição | Adoção |
| Retenção | Retenção |
| Monetização | Satisfação |
| Alta importância de necessidade | +80% |
Note que, na hora de medir funcionalidades, a diferença fica em adoção e satisfação. Neste artigo vamos focar na adoção.
Como medir a adoção de uma funcionalidade
Para medir a funcionalidade, você sempre precisa levar em consideração o público-alvo dela, como ilustrado na imagem a seguir:
Ao definir os usuários-alvo para a funcionalidade, você pode calcular o percentual de adoção com a seguinte equação:
Adoção de funcionalidade = Usuários ativos que adotaram a funcionalidade / Usuários alvo para a funcionalidade
Mesmo assim você deve estar se perguntando: “ok, mas qual é um bom percentual de adoção?”
Isso varia muito de negócio para negócio, principalmente se estivermos num cenário B2B (mais sobre isso ao longo do artigo). De qualquer forma, é possível ter um baseline que segue mais ou menos esse padrão:
| Importância | % de adoção |
|---|---|
| Baixa ou nenhuma importância de necessidade | ~0%-10% |
| Baixa importância de necessidade | ~20%-40% |
| Média importância de necessidade | ~50%-60% |
| Alta importância de necessidade | +80% |
Exemplo de adoção Easy Taxi
Para ilustrar, vou trazer um exemplo que vivenciei no Easy Taxi.
Quando trabalhei lá, iniciei no produto B2B e haviam diversos pedidos de empresas querendo uma funcionalidade de agendamento de corrida. Naquela época (meados de 2015-2016), ainda existiam muitas pessoas em transição do hábito de pedir um táxi por um aplicativo versus ligar para uma cooperativa de táxi. Então dava para compreender o motivo por trás dos pedidos – principalmente nas grandes empresas, nas quais havia uma secretária acostumada a agendar táxis quando os executivos tinham reuniões externas.
Mesmo sabendo que o hábito da sociedade ainda estava em transição, nós sabíamos que dava mais trabalho pro usuário marcar um agendamento em relação a simplesmente apertar um botão e esperar o táxi chegar (naquela época, o táxi chegava mais rápido que o Uber hoje).
A demanda vinha com muita recorrência da área comercial, às vezes com aquele clássico argumento: “Eu não consegui vender porque não tinha agendamento. Se tivesse, eu venderia.” Mesmo assim, como área de Produto, nós fomos relutantes durante muitos meses, afirmando que ainda “não era uma prioridade”
Até que chegou a hora que cedemos.
Nossa expectativa era que essa funcionalidade tivesse uma adoção muito baixa, afinal, os usuários iam notar que dava mais trabalho agendar do que só apertar o botão e pedir o táxi na hora que precisasse. Pensando nisso, e com uma ótica de validação, a gente resolveu desenvolver a feature de maneira incompleta.
Fizemos isso de uma maneira simples, afinal, toda a lógica de agendamento teria um fluxo mais ou menos assim:
- Avisar o motorista dias ou horas antes do agendamento;
- Aguardar por uma confirmação dele;
- Mandar um lembrete para o motorista para garantir sua presença;
- Confirmar com o motorista e confirmar com o passageiro.
Muitas etapas e muitas atualizações de back-end, front-end, app, etc. Seria complexo fazer tudo isso só pra testar.
Então resolvemos fazer um agendamento bem simples, no qual o usuário agendava, mas ele estava agendando apenas um trigger que solicitava o táxi aproximadamente 5 minutos antes. Ou seja, era um trigger que agendava o “apertar” do botão. Isso era uma ótima maneira de validar se teríamos adoção da feature.
E o que aconteceu? Tivemos menos de cerca de 1% de adoção no segmento B2B e menos que isso no segmento B2C. Seguindo a tabela acima, a necessidade era baixa ou de nenhuma importância.
Aqui é importante ponderar o seguinte: se 1% da sua base usa uma funcionalidade, mas ela consegue gerar milhões em receita, pode ser que seja algo significativo. Depende de como você está olhando e priorizando as suas métricas – sempre leve isso em consideração. Esse tipo de situação é bem mais comum no B2B para modelos enterprise. Entretanto não era o caso do Easy Taxi, pois ter agendamentos não ia aumentar nossa receita.
Exemplo de teste Fakedoor para estimar adoção XP
Uma outra forma muito eficiente de validar a adoção de uma funcionalidade antes de desenvolvê-la é fazer um teste Fakedoor.
Nesse exemplo abaixo, a XP fez um ótimo trabalho. Eu era usuário beta do Cartão de Crédito da XP e ainda não havia a funcionalidade de Débito Automático. Então eles colocaram o botão lá e, ao clicar nele, recebi um aviso de que a feature não estava disponível.
Dessa maneira a equipe de Produto da XP conseguiu ter uma estimativa de quantos usuários poderiam aderir ao débito automático e isso com certeza facilitou a priorização da funcionalidade.
Conclusão
Espero que este artigo tenha mostrado a você 2 coisas:
- É de extrema importância estarmos sempre calculando a adoção de novas funcionalidades. Afinal, uma funcionalidade lançada que não é usada só aumentará a complexidade do seu produto;
- É possível validar a adoção sem precisar desenvolver a funcionalidade por completo. Espero que isso tenha ficado claro com os exemplos acima.
A principal mensagem que quero deixar aqui é:
Celebre o uso, não a entrega!
Lembrando que este artigo faz parte de uma série com outros 2 artigos que estarão no ar nas próximas semanas:
- Medindo o sucesso das funcionalidades por meio da adoção
- Medir a satisfação de funcionalidades é diferente da satisfação de produtos
- Quando e como tirar uma funcionalidade do ar
