Gestão eficaz de produtos! Entenda o TARS Framework e aplique métricas de features SaaS para otimizar seu produto e roadmap.
Tempo de Leitura: 10 minutos
No ecossistema de produtos SaaS (Software as a Service), entender e aplicar as métricas corretas é crucial para o sucesso e a sustentabilidade de qualquer produto. Saber trabalhar de forma estruturada métricas de produto separadas de métricas de features SaaS pode parecer sutil, mas tem implicações profundas na maneira como os gestores de produto interpretam dados e tomam decisões estratégicas em relação ao seu roadmap. Neste contexto, vamos falar sobre a complexidade e a necessidade de um olhar refinado sobre as features SaaS de um produto a partir de métricas específicas, explorando como elas podem oferecer insights valiosos e direcionar o desenvolvimento do produto de maneira mais eficaz.
Revelando os "Detratores Ocultos" e Priorizando Estrategicamente
Eventualmente, ao mergulharmos mais profundamente nessa análise, encontramos uma abordagem mais granular e detalhada, que pode revelar o que chamamos de "detratores ocultos": clientes ou usuários do produto que, apesar de não estarem afetando significativamente as métricas gerais do produto com apontamento de insatisfações, podem se tornar um cancelamento ou desuso a longo prazo. Esses insights são vitais para uma gestão eficaz do produto, onde o objetivo é não apenas atender, mas exceder as expectativas dos usuários.
Podemos construir assim uma análise de roadmap e priorização orientada por dados. Abordaremos um modelo de avaliação chamado TARS Framework e como ele pode ser utilizado para avaliar e priorizar as features do produto que ganharão espaço na estratégia do Gerente de Produto. Eventualmente, garantindo que cada feature contribua positivamente para a experiência geral do usuário e para o sucesso do produto no mercado.
Conteúdo
MostrarOcultar- Revelando os "Detratores Ocultos" e Priorizando Estrategicamente
- Métricas de Produto x Métricas de Features
- Necessidade de Análise Detalhada das Features
- Identificação dos Detratores Ocultos
- Medir desempenho de features: utilizando o TARS Framework
- Definição do Público-Alvo e Mensuração da Adoção
- Avaliando a Retenção dos Usuários
- Customer Effort Score (CES)
- Priorização de features no roadmap de produto
- Conclusão
Métricas de Produto x Métricas de Features
Basear-se em métricas de produto para avaliar o desempenho de cada parte de um SaaS pode ser como dirigir um carro em uma estrada com neblina forte. Nós podemos enxergar um pouco a frente, se colocamos uma luz forte para tentar ver mais longe, a neblina ofusca um pouco mais de alguns metros a nossa frente.
Assim, para exemplificar, falaremos sobre o NPS - Net Promoter Score, que é uma clássica métrica de produto. Se você ainda não conhece esse indicador, eu convido você a acessar esse artigo aqui.
Ao aplicar o NPS nos clientes, perguntamos para ele “Qual a probabilidade de você indicar o produto X a um amigo?”. Ao responder essa pergunta, a informação que está sendo coletada é percepção do todo. Isso geralmente em um SaaS engloba uma percepção completa do produto e do serviço, que pode incluir o suporte, a venda, a implantação ou uma consultoria, por exemplo. Desse modo, para um Gerente de Produto, essa composição na percepção do cliente impacta na métrica para dizer pouco sobre a satisfação do cliente com cada parte do produto. Geralmente, no NPS irão aparecer apenas as maiores insatisfações de forma gritante, quando realmente o problema é mais grave.
Necessidade de Análise Detalhada das Features
Para uma apuração mais precisa do desempenho das features do produto, precisamos descer a nossa análise para o nível mais abaixo do produto. Isso significa coletar o feedback do cliente sobre cada parte da sua solução. Por exemplo, se estamos falando de uma solução para emissão de Boletos, como a da Tecnospeed, estamos falando de um produto que possui várias features, como, por exemplo: o registro do título, a transmissão dele ao banco, a impressão em PDF e a régua notificações de cobrança.
Por exemplo, supondo que o cliente esteja com a percepção de que o desempenho da API de registro de títulos é ruim porque ele encontra alguns momentos pontuais de lentidão, mas ele continua utilizando porque é tolerável e o suporte o tem atendido de forma muito satisfatória. Ele faz isso, porque naquele momento é a única alternativa disponível para a sua empresa, e dificilmente ele irá se lembrar desse detalhe na hora de responder o NPS. Ele muito provavelmente só irá expor a sua opinião sobre a API de registros se alguém perguntá-lo sobre ela.
Identificação dos Detratores Ocultos
Do mesmo modo, é por esse motivo que as métricas de produto - como o NPS - podem esconder o que é chamado no Gerenciamento de Produtos como os detratores ocultos. São usuários que possuem notas positivas ou neutras sobre a percepção da solução no geral, mas que possuem pequenas insatisfações e atritos na sua experiência que não ficam visíveis para a gestão, porque são alguns detalhes ou continuam em um nível de “não incomodar tanto assim” na sua percepção do todo.
Portanto, é por isso que na hora de gerenciar e priorizar onde vamos alocar os esforços no trabalho com as features do produto, devemos descer o nível de análise para as partes do produto que compõem a percepção do cliente, de forma mais específica. É preciso olhar para o produto como um composto, de pequenas partes que constroem a experiência do cliente.
Com essa separação, é possível avançar para o modelo do TARS Framework. Possibilitando de gerar métricas e indicadores de satisfação de forma segregada, para uma avaliação mais profunda da percepção dos clientes com o produto.
Medir desempenho de features: utilizando o TARS Framework
Legenda: Analisar métricas de produto é como dirigir em neblina. O NPS pode ocultar insatisfações sutis. É necessário descer ao nível das features para uma visão mais clara da experiência do cliente. TARS Framework oferece essa profundidade.. | Imagem: Freepik
O TARS Framework é uma metodologia desenvolvida pela Reforge à partir de aplicações práticas de grandes empresas no Gerenciamento de Produto (empresas de tecnologia como Slack, Microsoft, Evenbrite, entre outras) para avaliar e priorizar features. A palavra TARS é a abreviação dos termos Target (Público Alvo), Adoption (Adoção), Retention (Retenção) e Satisfaction (Satisfação). Traduzindo para um português literal, ficaria Modelo PARS.
Abaixo, uma breve explicação do que significa cada um dos termos:
Target (Público Alvo): É o público alvo, composto pelos usuários ativos da feature que estamos avaliando ou que pretendemos lançar
Adoption (Adoção): O percentual de usuários do público alvo da feature, que iniciaram o uso da feature em algum momento ou em seu lançamento
Retention (Retenção): É o percentual dos usuários que iniciaram o uso da feature, mas que se mantiveram utilizando ela por um longo período e desenvolveram o hábito de utilizá-la
Satisfaction (Satisfação): É o percentual dos usuários de retenção daquela feature, que enxergam que a feature está dentro da sua expectativa, ou seja, que ficaram satisfeitos com ela
Assim, o TARS Framework se utiliza do composto de três métricas (Adoção, Retenção e Satisfação) a partir do público alvo, para se certificar de que estamos fazendo uma análise precisa e completa da experiência do cliente. Quando utilizamos apenas uma delas, como a adoção, por exemplo, isso pode significar pouco sobre o comportamento do usuário. É por isso que cada uma delas possui o seu papel dentro do framework e pode dizer muito sobre a percepção dos clientes em relação à experiência que ele está tendo com aquela parte do Produto.
Legenda: O público alvo é definido a partir dos usuários ativos de uma feature. Define-se um número que representa a expectativa do Gerente de Produto em relação a quantos usuários do produto irão utilizar aquela feature a ser avaliada em específico. | Imagem: TecnoSpeed
Definição do Público-Alvo e Mensuração da Adoção
O público alvo é definido a partir dos usuários ativos de uma feature. Define-se um número que representa a expectativa do Gerente de Produto em relação a quantos usuários do produto irão utilizar aquela feature a ser avaliada em específico. Com esse número, vamos mensurar a adoção. Que representa quantos usuários iniciaram uma feature. Pode ser um cadastro, uma criação e configuração, uma reprodução.
Então, para ficar mais claro como trabalhar com o TARS Framewrk, vamos ao longo desse tópico utilizar um exemplo: podemos dizer que de uma base de 200 usuários, 50 iniciaram o uso da feature. Nesse caso, a taxa de adoção é de 25%.
A adoção de uma feature pode ser a abertura de um cadastro, uma reprodução de um conteúdo, a criação e configuração de um artefato. Por exemplo, na feature de canais compartilhados do Slack, o ato de criar um canal e enviar uma mensagem é um indicador de adoção.
Uma alta taxa de adoção mostra o quanto você conseguiu comunicar bem a proposta de valor da feature, porque o usuário se interessou e se motivou a utilizá-la. Ele gostou da ideia e aderiu, dando início a sua experiência com aquela funcionalidade me específico. Porém, medir a adoção não diz nada, além disso. Por isso, O próximo passo é medir a retenção.
Avaliando a Retenção dos Usuários
Legenda: Antes de medir a retenção, precisamos entender quanto tempo levaria para o cliente criar um hábito de utilizar a feature. | Imagem: Freepik
Antes de medir a retenção, precisamos entender quanto tempo levaria para o cliente criar um hábito de utilizar a feature: isso é chamado de uso natural da feature, e mapeamos isso entendendo qual a periodicidade que o cliente deve usar aquela feature partindo do pressuposto que ele tem um hábito estabelecido corretamente de consumi-la.
Supondo que o cliente utilize essa feature semanalmente, nós podemos dizer que um cliente pode ser considerado retido se ele manteve o seu uso semanal durante 9 semanas ou mais. As 9 semanas é a periodicidade de referência da metodologia. Caso o uso seja mensal, poderíamos estabelecer 9 meses, ou se for diário, 9 dias.
No nosso exemplo, supomos que 25 clientes permaneceram utilizando a feature semanalmente após 9 semanas. Isso significa que a taxa de retenção foi de 50% dos usuários que adotaram.
Dessa forma, as altas taxas de retenção mostram que você conseguiu com aquela feature resolver o problema do cliente, pois ela agregou valor a ponto de ele continuar utilizando. Porém, isso não significa que aqueles usuários ficaram satisfeitos com a experiência que tiveram. Após as 9 semanas, então, é o momento de aplicarmos uma pesquisa de satisfação com os clientes retidos. Utilizamos para essa finalidade a métrica CES (Customer Effort Score). Porém, utilizamos o que chamamos de CES adaptado.
Customer Effort Score (CES)
CES (tradicional)
De forma geral, quão fácil foi resolver (problema) hoje?
A) Muito difícil
B) Difícil
C) Nem fácil, nem difícil
D) Fácil
E) Muito fácil
CES (Adaptado)
De forma geral, quão fácil foi resolver (problema) após usar (feature) hoje?
A) Muito mais difícil do que esperado
B) Mais difícil do que esperado
C) Dentro da expectativa
D) Mais Fácil do que esperado
E) Muito mais fácil do que esperado
As respostas A e B são insatisfações, enquanto as C, D e E são clientes satisfeitos.
Portanto, seguindo no exemplo, supomos que dos 25 clientes retidos, apenas 5 responderam C, D ou E. Os 20 demais responderam entre A e B. Isso significa uma taxa de satisfação de apenas 20%.
Legenda: Uma alta taxa de satisfação demonstra que a feature atendeu as expectativas que o cliente tinha e como você conseguiu solucionar o problema dele. | Imagem: Freepik
Uma alta taxa de satisfação demonstra que a feature atendeu as expectativas que o cliente tinha e como você conseguiu solucionar o problema dele. Mas, no caso acima, a satisfação dos clientes foi baixa e valeria uma conversa com esses 20 clientes, para entender o que está abaixo de suas expectativas.
Quando alcançamos o indicador de Satisfação, chegamos ao resultado da aplicaçãol do TARS Framewok.
Cada indicador encontrado pode servir de base para análise do Gerente de Produto, porém, o mais importante é calcular a partir dos resultados um indicador chamado S/T Score. Que é o percentual de usuários alvo da feature (Target) estão satisfeitos com a mesma. Nesse caso, o nosso S/T Score é 5%.
S/T Score = Usuários Satisfeitos / Usuários Target
O indicador de S/T Score será utilizado para priorização no roadmap do produto, que iremos tratar no próximo tópico.
Priorização de features no roadmap de produto
Com o S/T Score em mãos, o próximo passo é fazer uma avaliação das features para entender como está o composto de features do nosso produto e a percepção do cliente. Para fazer isso, utiliza-se a Matriz de Features, que compara o S/T Score de uma feature com a sua importância estratégica para o produto.
Afinal, a Importância Estratégica é alta quando a feature se encaixa em pelo menos uma das seguintes características: o público alvo da feature é muito grande no universo do produto, ou se em caso de um problema nela haveria grande impacto na experiência do cliente com o produto. Caso ela se encaixe em um desses critérios, ela é considerada de importância estratégica Alta, caso contrário é Baixa.
Na matriz, as features são classificadas em 4 posições:
Legenda: Matriz de Features, que compara o S/T Score de uma feature com a sua importância estratégica para o produto. | Imagem: TecnoSpeed
Overperforming Features
São as funcionalidades que possuem uma alta satisfação dos clientes, mas que não possuem muita importância estratégica para o produto. Por ter essa baixa importância, elas possuem um desempenho acima da expectativa, então só olhamos para ela em caso de explorarmos novos públicos que poderão dar mais relevância a ela.
Core Features
São as features que te levaram até onde você está agora. Elas têm alta relevância estratégica e os usuários estão satisfeitos com ela, possivelmente o motivo pelos quais os clientes permanecem utilizando o produto.
Features Core não precisam de atenção no momento, mas elas podem ser utilizadas m casos de se expandir mercado.
Project Features
São as features mais problemáticas do seu produto. Mas, o nosso esforço maior não deve ser colocado nelas porque há baixa importância estratégica para o cliente. Essas features devem receber uma avaliação mais severa e estratégica, com foco em transformar ou descontinuar.
Liability Features
Essas são as features que precisam ter a maior prioridade do Gerente de Produto, porque elas têm alta importância estratégica, mas a satisfação dos clientes com ela é baixa. É possível que o cliente esteja utilizando insatisfeito, porque as alternativas disponíveis no mercado não o agrada, a composição de valor é maior, ou ele pode estar preso ao seu produto contra a sua vontade por um vendor lock in muito alto. O trabalho deve ser focado aqui, visando melhorar e otimizar para que elas se tornem Core Features.
Classificando as features com o S/T Score e a sua importância estratégica, chegamos a uma matriz e com isso, conseguimos priorizar o roadmap do produto. Primeiro, sempre trabalhando nas features que se encaixaram no quadrante Liability Features.
Portanto, devemos levar também em consideração a estratégia da empresa para a priorização, porque podemos ter variáveis de mercado que podem afetar o nosso produto. Além disso, nos dois quadrantes superiores encontram-se as features que podem apresentar oportunidades, acelerar novos públicos e expandir o seu público alvo. Em um caso onde há forte pressão por expansão da base de clientes, priorizar esses quadrantes pode ser uma estratégia a ser seguida pelo Gerente de Produto.
Conclusão
O modelo apresentado cria uma forma de gerenciar features orientada por dados, onde o gerente de produtos pode priorizar seu roadmap com base em métricas mais precisas.
Logo, as métricas de features se diferem das métricas de produto fornecendo uma visão mais específica de cada parte do mesmo, utilizando-se de adoção, retenção e satisfação para identificar como cada parte do produto contribui para a experiência geral do usuário. A priorização eficaz no roadmap do produto, fundamentada no S/T Score e na análise de importância estratégica, é a chave para a gestão eficiente do roadmap e para garantir que cada feature desempenhe seu papel na construção de um produto robusto e bem-sucedido.
Por fim, vale destacar que o processo de coletar e analisar métricas de features não são um projeto simples para quem ainda não aplica modelos de coleta de dados de produto e geralmente, tais frameworks de trabalho são implementados por equipes de Gerentes de Produto com Gerentes de Produtos Associados, que trabalham diariamente com coleta, organização e análise desses dados.
A Gestão de Produto é uma metodologia de trabalho que requer evolução contínua para que cada passo da empresa, aumente o nível de maturidade da coleta e análise de dados, possibilitando cada vez mais insights que permitam a tomada de decisões baseada em informações inteligentes.
