Como medir o sucesso de uma funcionalidade

A maioria das funcionalidades recebe muito mais atenção antes do lançamento do que depois. Existe discovery, priorização, design, desenvolvimento, QA, release. No dia seguinte, já existe a próxima demanda disputando o backlog. E aquela funcionalidade que consumiu semanas de trabalho entra numa situação estranha: está em produção, mas ninguém combinou o que precisaria acontecer para considerá-la bem-sucedida.

Meses depois, continua sendo mantida, continua aparecendo na interface, continua sendo testada, continua gerando estados, documentação e suporte. Só não sabemos se deveria existir. O problema não é falta de dashboard. É que a pergunta sobre sucesso chegou tarde demais.

Sucesso precisa ser definido antes de existir o número

Imagine que o time lança uma nova área de relatórios. Trinta dias depois alguém pergunta:

Foi boa?

A equipe abre o analytics. 2.400 pessoas visualizaram. Ótimo? Talvez. Foram 2.400 de 3.000 pessoas elegíveis ou de 300 mil? Não sabemos. 600 exportaram. Bom? Talvez. O objetivo era exportar mais ou eliminar a necessidade de exportação? Também não sabemos. Uso aumentou 20%. Excelente. Mas aumentar uso era o que queríamos?

Quando o objetivo só é discutido depois que o resultado apareceu, qualquer número consegue virar uma história favorável. Por isso medir uma funcionalidade começa antes do lançamento com uma frase: o que esperamos que mude se isso funcionar?

Instrumentação também faz parte da funcionalidade

Existe um problema ainda mais básico. O time decide depois que quer medir:

quantas pessoas chegaram até aqui?

Só que o evento nunca foi registrado. Ou existe um evento chamado button_clicked sem informação sobre qual botão. Ou o dado registra abertura da tela, mas não conclusão da tarefa. Agora o produto está no ar e a pergunta não pode ser respondida retroativamente.

Se uma métrica será necessária para decidir o futuro da funcionalidade, a capacidade de medi-la faz parte da entrega. Isso não significa transformar toda feature em projeto de analytics. Pode ser apenas:

• quem recebeu acesso;

• quem encontrou;

• quem iniciou;

• quem concluiu;

• qual resultado ocorreu;

• qual erro aconteceu.

Mas essa conversa precisa acontecer antes do deploy.

Comece pelo objetivo, não pelo evento disponível no analytics

O framework HEART, desenvolvido por Kerry Rodden, Hilary Hutchinson e Xin Fu no Google, propõe cinco categorias de métricas de experiência: Happiness (como as pessoas percebem a experiência), Engagement (qual é o nível de envolvimento com o produto), Adoption (quantas pessoas começam a utilizar), Retention (quantas continuam utilizando ao longo do tempo) e Task Success (se conseguem concluir aquilo que precisam com eficácia e eficiência).

A contribuição mais útil para este problema talvez nem seja a sigla HEART. É o processo que os autores apresentam junto dela: Goals → Signals → Metrics. Primeiro, qual é o objetivo. Depois, que comportamento ou percepção indicaria que estamos chegando nele. Só então, qual número consegue representar esse sinal. Essa ordem evita um dos vícios mais comuns de produto: medir aquilo que a ferramenta já mostra em vez daquilo que a decisão precisa saber.

Nem toda funcionalidade precisa das cinco métricas

Imagine que você criou edição em lote para operadores financeiros. O objetivo é:

reduzir o esforço necessário para revisar centenas de transações.

Você não precisa necessariamente acompanhar NPS daquela feature. Talvez as métricas relevantes sejam tempo necessário para concluir a tarefa, quantidade de operações individuais evitadas, taxa de conclusão, erros e uso recorrente por quem possui volume suficiente para se beneficiar. Agora imagine uma nova funcionalidade de onboarding: Adoption e Task Success ganham outra importância.

HEART é um menu de perguntas. Não uma checklist que exige cinco gráficos para cada botão novo. O próprio trabalho original ressalta que nem todas as categorias são apropriadas em todos os contextos.

Em B2B, mais uso nem sempre significa produto melhor

Esse cuidado é especialmente importante. Imagine um sistema de conciliação. Antes, o usuário resolve tudo em dez minutos. Depois de uma mudança, ele precisa abrir a funcionalidade cinco vezes durante o dia. Engagement subiu. A experiência piorou.

Frequência de uso pode significar valor, dependência, retrabalho, confusão ou obrigação. No paper original do HEART, os próprios autores observam que Engagement pode não ser particularmente útil em alguns produtos enterprise quando o uso faz parte do trabalho da pessoa. Por isso “usuários abriram mais vezes” não deveria ser automaticamente interpretado como “a funcionalidade ficou melhor”. A métrica só ganha significado quando conectada ao objetivo.

Uma funcionalidade precisa atravessar algumas perguntas diferentes

Eu pensaria a avaliação em camadas. Não como uma fórmula universal, mas como um diagnóstico.

As pessoas elegíveis tiveram acesso?

Antes de falar em adoção, você precisa saber qual era a população possível. Se uma feature estava habilitada para 300 contas, comparar uso com 10 mil clientes distorce tudo. Em rollout gradual, registre quando cada pessoa ou organização ficou elegível. Isso permite medir desde o momento correto.

As pessoas descobriram que ela existe?

Talvez tenham acesso, mas nunca encontrem. Aqui podem entrar visualização, exposição do entry point, descoberta do recurso, entrada no fluxo. Uma adoção baixa pode começar como problema de descoberta. Mas cuidado: descoberta alta também não prova interesse. A pessoa pode ter visto e simplesmente não precisar.

Quem tentou conseguiu concluir?

Agora entramos em Task Success. Quantas pessoas começaram? Quantas concluíram? Onde houve abandono? Quanto tempo levou? Quais erros apareceram? Isso ajuda a separar “ninguém quer usar” de “as pessoas tentam, mas não conseguem”. São problemas completamente diferentes.

O comportamento se repetiu quando deveria se repetir?

Para uma funcionalidade recorrente, vale observar se quem experimentou voltou a utilizá-la em ciclos seguintes. Esse é um sinal importante. Mas eu evitaria dizer que repetição “mede valor de verdade”. Existem funcionalidades extremamente valiosas usadas uma única vez: configuração inicial, exportação anual, recuperação de desastre, contestação específica, mudança de plano. Retention só faz sentido quando a tarefa também é recorrente.

O resultado que justificou o investimento mudou?

Esse é o nível mais importante. Talvez a funcionalidade exista para reduzir abandono, aumentar ativação, diminuir tempo operacional, reduzir erros, aumentar aprovação, reduzir chamados, melhorar retenção ou permitir expansão de contrato. Agora conseguimos perguntar: o comportamento que justificou construir isso mudou? Uso é evidência intermediária. Resultado é a razão pela qual a empresa investiu.

Adoption e Retention respondem perguntas diferentes

O HEART faz uma distinção útil. Adoption acompanha novos usuários começando a utilizar um produto ou feature em determinado período. Retention acompanha quantos permanecem presentes ou ativos num período posterior. Aplicando isso a uma funcionalidade:

Adoption baixa, Retention alta

Poucas pessoas começam a usar, mas quem começa continua. Uma hipótese possível é descoberta: talvez a feature esteja escondida, talvez a proposta não esteja clara, talvez o onboarding não apresente o recurso. Mas também existem outras explicações. Talvez ela só seja relevante para uma parte pequena da base, talvez o problema que resolve seja raro, talvez o público elegível tenha sido definido errado. O diagnóstico não deveria ser automaticamente “precisamos divulgar mais”. Primeiro descubra quem deveria adotar.

Adoption alta, Retention baixa

Muita gente experimenta. Pouca gente continua, apesar de a tarefa exigir recorrência. Agora vale investigar: a primeira experiência criou expectativa errada? O valor não apareceu? O fluxo é trabalhoso? Existe alternativa melhor? A funcionalidade resolve uma situação pouco frequente? Divulgar mais sem responder essas perguntas pode apenas aumentar o número de pessoas experimentando algo que ainda não gera retorno.

“Uso baixo” é um sintoma, não um diagnóstico

Essa frase aparece muito:

a feature não pegou.

O que exatamente aconteceu? Pode significar que ninguém encontrou, ninguém entendeu, ninguém precisava, as pessoas tentaram e falharam, funcionou mas a tarefa ocorre uma vez ao ano, só cinco clientes precisam e esses cinco usam intensamente, existe uma alternativa melhor, o segmento errado recebeu a funcionalidade. Todos produzem um gráfico de uso baixo. Exigem decisões diferentes. Por isso analytics aponta onde investigar. Nem sempre explica por quê.

Defina primeiro quem deveria usar

O denominador muda tudo. Imagine:

8% dos clientes usaram conciliação automática.

Parece baixo. Mas a funcionalidade só faz sentido para empresas com mais de cem cobranças mensais. Esse grupo representa 10% da base. Agora descobrimos que praticamente toda a população relevante adotou. Compare:

usuários da feature / todos os usuários

com:

usuários da feature / usuários elegíveis que possuem aquele problema

A segunda medida normalmente conta uma história muito melhor. Em B2B, segmentação é especialmente importante. Uma funcionalidade pode ser destinada a administradores, operadores, empresas enterprise, clientes com determinada integração, usuários com determinado volume ou um setor específico. “Todos os clientes” raramente é um denominador útil.

A janela de avaliação precisa respeitar o ciclo da tarefa

Outra fonte de leitura errada é medir cedo demais. Imagine uma funcionalidade usada no fechamento financeiro mensal. Ela entra em produção no dia 5. No dia 20 alguém abre o analytics:

quase ninguém usou.

Boa parte dos clientes ainda nem chegou ao próximo fechamento. Não existe necessariamente um problema de adoção. Existe uma janela ruim.

O período de avaliação deveria conversar com o ciclo natural da tarefa. Uma ação diária pode produzir evidência rapidamente. Uma tarefa mensal precisa atravessar ciclos mensais. Uma renovação anual exige outro tipo de acompanhamento. Não existe “esperar 30 dias” como regra universal. A pergunta é: quantas oportunidades reais de uso cada pessoa teve desde que recebeu acesso?

Meça por coorte quando a liberação não acontece para todos ao mesmo tempo

Isso fica ainda mais importante em rollout gradual. Cliente A recebeu a funcionalidade há 60 dias. Cliente B, há 30. Cliente C, ontem. Olhar todos juntos produz uma média difícil de interpretar. Organize por data de acesso, data de ativação, perfil, volume, plano ou outra característica relevante. Assim você consegue comparar pessoas que tiveram oportunidades parecidas.

Também vale separar, quando necessário, clientes existentes de clientes que começaram a usar o produto depois que a feature já fazia parte dele. O primeiro grupo precisa modificar um comportamento aprendido. O segundo conhece o produto já com a nova opção disponível. Não assuma que um necessariamente adotará mais que o outro. A razão para separar é justamente descobrir se existe diferença.

Escreva o sucesso antes do lançamento

Uma boa definição precisa ser concreta o suficiente para falhar. Por exemplo:

Para empresas que processam mais de 100 cobranças por mês, queremos aumentar a proporção que conclui a conciliação sem exportação manual durante os dois próximos ciclos de fechamento.

Isso já é muito melhor que:

aumentar adoção da conciliação.

Depois entram os sinais. Se a experiência melhorou, talvez observemos menos exportações, mais conclusões dentro do produto, menos tempo, menos chamados relacionados ao processo. Então escolhemos métricas. Esse caminho é mais robusto que começar arbitrariamente com:

queremos 40% de adoção.

Meta não deveria nascer apenas de uma aposta confortável

Às vezes é necessário estabelecer um alvo numérico. Mas ele deveria ter algum fundamento. Pode vir de baseline atual, benchmark interno, tamanho da oportunidade, experimento anterior, capacidade operacional, economia esperada, hipótese comercial ou resultado necessário para justificar o investimento. Se não existe nenhum desses, uma estimativa explícita ainda pode ser útil. Só deve ser tratada como hipótese.

Um exercício interessante é pedir para diferentes pessoas do time estimarem separadamente:

que resultado consideraríamos bom?

Se Product acredita em 60%, engenharia em 20% e liderança em 80%, a divergência já revelou algo. O time não possui uma expectativa compartilhada sobre aquela iniciativa. Melhor descobrir antes do lançamento.

Defina também o que não pode piorar

Esse ponto é especialmente importante em fintech. Imagine que a funcionalidade tenta aumentar conclusão de KYC. O time mede apenas o percentual que concluiu. Uma mudança reduz etapas e aumenta a conclusão. Sucesso? Talvez também tenha aumentado fraude ou reduzido qualidade da verificação. Toda métrica de sucesso importante pode precisar de um guardrail. Por exemplo:

aumentar conclusão sem elevar fraude acima de X;

reduzir tempo de conciliação sem aumentar erro;

aumentar aprovação sem aumentar chargeback além do limite;

reduzir chamados sem aumentar abandono.

O objetivo não é maximizar um número isoladamente. É produzir uma melhora aceitável no sistema inteiro.

Atribuição fica mais difícil conforme você sobe para o resultado de negócio

Imagine que retenção aumentou depois do lançamento. Foi a feature? Talvez. Também houve mudança de preço, nova equipe de CS, melhoria de performance, sazonalidade, outro lançamento. Quanto mais distante a métrica está da interação, mais difícil provar causalidade. Isso não significa ignorar resultado de negócio. Significa usar linguagem correta. Em vez de:

a feature aumentou retenção em 8%.

talvez:

clientes que adotaram a feature apresentaram retenção 8 pontos maior no período.

Ainda não prova causalidade. Experimentos controlados ajudam quando são possíveis. Em outros contextos, você trabalha com coortes, antes e depois, segmentação, pesquisa, evidência qualitativa e dados operacionais. Decisão de produto quase sempre é feita com um conjunto de evidências, não uma linha perfeita de causalidade.

O resultado deveria produzir uma decisão

Essa é a etapa que transforma medição em trabalho de produto. Imagine que o número ficou abaixo do esperado. O que acontece agora? Sem uma consequência previamente combinada, costuma acontecer isto:

Hmm, interessante.

Próximo assunto da reunião. Eu gosto de reduzir o resultado a algumas possíveis decisões.

Manter

A funcionalidade está produzindo o resultado esperado. Talvez não precise de novo investimento agora. Essa também é uma decisão.

Corrigir

Existe evidência de valor, mas algum atrito está impedindo o resultado. Pode ser descoberta, fluxo, erro, performance, compreensão. Agora existe uma razão concreta para iterar.

Investigar

O resultado ficou estranho e ainda não sabemos por quê. Antes de redesenhar, pode fazer sentido entrevistar, observar, segmentar dados, rodar teste de usabilidade, investigar coortes.

Expandir

O resultado inicial é bom e existe oportunidade maior. Talvez seja hora de aumentar rollout, investir na próxima etapa ou levar para outro segmento.

Reposicionar

A funcionalidade gera valor, mas não para quem imaginávamos ou não no momento previsto. Mude público, entrada, momento ou comunicação.

Remover

Existe pouco valor e manter custa mais que retirar. Essa opção deveria existir de verdade. Caso contrário, toda medição possui apenas uma direção: continuar mantendo.

Aceitar uso baixo

Algumas funcionalidades precisam existir mesmo com adoção pequena: contrato, regulação, compliance, operação excepcional, risco. Nesse caso, registre: baixo uso é esperado e não representa fracasso. Isso evita rediscutir a mesma métrica daqui a seis meses.

Antes de remover, descubra quem está dentro da média

Essa é uma armadilha importante em SaaS B2B.

Apenas 2% dos clientes usam.

Parece candidata óbvia à remoção. Até descobrir que os 2% são os quatro maiores contratos da empresa. Média agrega. Decisão precisa de contexto. Antes de retirar uma feature, olhe quem utiliza, com que frequência, para qual tarefa, qual receita está associada, qual alternativa existe e o que quebraria sem ela. Baixo alcance pode continuar acompanhado de alto valor estratégico.

Funcionalidade sem uso não é gratuita

Existe uma ideia implícita de que:

já construímos, então deixa aí.

Só que software continua custando depois do lançamento. Uma feature adiciona código, interface, estados, testes, documentação, suporte, complexidade de design system, dependências, casos de borda e carga cognitiva. Toda decisão futura precisa considerar mais uma coisa. Isso cria um tipo de juros. Nenhuma funcionalidade isolada parece cara de manter. Cem funcionalidades sem dono produzem um produto difícil de compreender e caro de evoluir.

Por isso medir sucesso não serve apenas para saber onde investir mais. Serve para descobrir onde parar de investir.

“Pronto” deveria incluir aprendizado

Se o processo termina em:

deployed.

medição sempre parecerá trabalho adicional. Uma definição mais útil seria:

lançado, instrumentado e com data definida para revisão.

Não é necessário segurar o ticket aberto durante dois meses. A questão é existir responsabilidade explícita. Por exemplo:

• Lançamento: 15 de setembro

• Primeira leitura: depois de dois ciclos de uso

• Objetivo: reduzir fechamento fora do produto

• Métricas: conclusão, exportação e tempo

• Guardrail: erros de conciliação

• Decisão possível: manter, corrigir, investigar, expandir ou remover

Agora a avaliação não depende de alguém lembrar espontaneamente no futuro.

Não precisa criar mais uma cerimônia trimestral

Eu evitaria transformar isso em:

toda feature será revisada trimestralmente por 30 minutos.

Pode funcionar. Também pode virar outra reunião automática. O melhor momento de revisão depende do ciclo da funcionalidade. Registre no lançamento: quando teremos evidência suficiente para voltar a essa decisão? Talvez sejam 14 dias, dois fechamentos mensais, 1.000 operações, 100 organizações expostas, um ciclo de renovação. Isso é muito mais informativo que uma cadência arbitrária.

Nem todo sucesso cabe no analytics

Às vezes o objetivo é:

operadores confiarem na recomendação.

Você pode observar aceitação, reversão, abandono, tempo. Mas talvez ainda precise perguntar por que alguém rejeitou. Outra funcionalidade reduz uso. Ótimo ou péssimo? Talvez ela automatize justamente o trabalho que antes exigia dez acessos.

O paper original do HEART já fazia essa ressalva: métricas não deveriam existir isoladamente e precisam ser combinadas com outras formas de evidência. Analytics responde muitas perguntas. Pesquisa responde outras. Operação outras. Negócio outras. Medição boa não é escolher uma fonte favorita. É juntar o suficiente para tomar uma decisão melhor.

A pergunta final não é “quantas pessoas usaram?”

É: o problema que justificou construir isso ficou menor?

Para responder, talvez você precise saber quem teve acesso, quem descobriu, quem tentou, quem conseguiu, quem voltou, quanto tempo economizou, que erro deixou de acontecer, que comportamento mudou, que resultado apareceu. Mas não acompanhe tudo por obrigação. Volte ao objetivo. Escolha os sinais que realmente distinguem sucesso de fracasso. Instrumente antes. Defina quando olhar. E combine o que fará com cada resultado possível.

Uma funcionalidade só deixa de ser uma aposta quando o time olha para o que aconteceu e usa essa evidência na próxima decisão. Até lá, ela não é exatamente um sucesso. É apenas algo que foi lançado.

Para definir quais números fazem sentido acompanhar no produto como um todo, vale continuar por Métricas de produto para time pequeno: o que olhar primeiro.

Fontes

Rodden, Kerry; Hutchinson, Hilary; Fu, Xin. Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications. Proceedings of CHI 2010, ACM. Trabalho que apresenta o framework HEART, composto por Happiness, Engagement, Adoption, Retention e Task Success, e o processo Goals-Signals-Metrics.

O paper define Adoption como métricas relacionadas a novos usuários começando a utilizar um produto em determinado período e Retention como métricas que acompanham quantos usuários de um período continuam presentes em um período posterior. Os autores ressaltam que o que conta como “uso” depende da natureza e dos objetivos do produto.

O trabalho também observa que nem todas as categorias HEART são apropriadas para todos os produtos. Em contextos enterprise, por exemplo, Engagement pode ter significado limitado quando o uso do sistema é parte obrigatória do trabalho.

Por fim, os autores defendem que métricas sejam relacionadas explicitamente a objetivos e trianguladas com outras fontes, como estudos de usabilidade e pesquisa de campo, em vez de serem utilizadas isoladamente.