O gestor de produto lança uma funcionalidade. A funcionalidade deve resolver um problema dos clientes e promover a retenção.
Duas semanas depois do lançamento: a funcionalidade reduz os cancelamentos. Mais clientes usam a funcionalidade. Os clientes passam mais tempo na funcionalidade.
Sem um painel de produto, o gestor de produto espera seis semanas pelo relatório mensal para ver o impacto da funcionalidade. Nessa altura, o feedback dos clientes já arrefeceu. Não é possível iterar.
Com um painel de produto, o gestor de produto vê ao fim de duas semanas: a adoção da funcionalidade é de cinco por cento (o objetivo era vinte por cento até à semana dois). O problema fica logo visível. O gestor de produto investiga. Descobre que a funcionalidade é difícil de encontrar. Acrescenta uma mensagem de integração. A adoção sobe para quinze por cento até à semana quatro.
Painéis de produto: adoção e envolvimento com as funcionalidades
Taxa de adoção da funcionalidade
A funcionalidade foi lançada há duas semanas. Utilizadores elegíveis: dez mil. Utilizadores que usaram a funcionalidade: quinhentos. Taxa de adoção: cinco por cento. O objetivo era vinte por cento até à semana quatro. Neste momento está atrasada. É preciso investigar.
Envolvimento com a funcionalidade
Dos quinhentos utilizadores que experimentaram a funcionalidade, quantos a usam diariamente. Duzentos. Quantos a usam semanalmente. Trezentos. Quantos abandonaram a funcionalidade. Duzentos. Taxa de envolvimento: quarenta por cento diariamente, sessenta por cento semanalmente, quarenta por cento abandonaram. O abandono é demasiado alto. A funcionalidade não é viciante.
Tempo passado na funcionalidade
A sessão média na funcionalidade é de dois minutos. Antes da funcionalidade, o tempo médio de sessão no site era de dez minutos. A funcionalidade está a afastar os utilizadores de outras funcionalidades. É intencional. A funcionalidade substituiu uma funcionalidade mais antiga ou é um acréscimo.
Impacto na retenção
Clientes que adotaram a funcionalidade: oito por cento de cancelamentos mensais. Clientes que não adotaram a funcionalidade: doze por cento de cancelamentos mensais. A funcionalidade está a funcionar. Melhoria de quatro pontos percentuais nos cancelamentos. Para uma base de mil clientes, são quarenta clientes a menos por mês. Quarenta vezes cinquenta (valor médio por cliente) são dois mil de receita poupada por mês.
Painéis de operações: saúde e desempenho do sistema
Disponibilidade do sistema
O website esteve no ar durante 99.95 por cento do tempo na semana passada. O objetivo é 99.99 por cento. Estamos abaixo do objetivo. Duas falhas: uma de dez minutos, outra de quinze minutos. Juntas, vinte e cinco minutos de paragem. O que causou as falhas. Podem ser evitadas.
Tempo de resposta
O tempo médio de resposta da API é de duzentos milissegundos. O tempo de resposta P95 é de quinhentos milissegundos (95 por cento dos pedidos são mais rápidos, cinco por cento são mais lentos). O P99 é de um segundo. Tempos de resposta lentos acontecem ocasionalmente. São aceitáveis.
Taxa de erros
Um por cento dos pedidos à API devolveram erro. Subiu de zero vírgula cinco por cento na semana passada. A taxa de erros duplicou. O que mudou. Uma consulta à base de dados está mais lenta. Os tempos de resposta aumentaram. Os clientes estão a esgotar o tempo e a tentar de novo. É preciso investigar.
Conjunto de ligações à base de dados
O conjunto tem cem ligações. Neste momento há cem abertas (totalmente usadas). Não há mais ligações disponíveis. Se chegar mais um pedido, fica em fila. O utilizador sente espera. O conjunto está na capacidade máxima. É preciso aumentar o conjunto ou reduzir a utilização.
Taxa de acerto da cache
A cache acerta em cinquenta por cento das vezes. Cinquenta por cento do tráfego não precisa de consulta à base de dados. Uma taxa de falha da cache de cinquenta por cento é aceitável na maioria dos sites. Abaixo de quarenta por cento e a base de dados fica sobrecarregada. Acima de setenta por cento e estás a usar cache em excesso.
Exemplo real: painel de produto e operações de um SaaS
Métricas de produto
Nova funcionalidade de painéis: lançada no mês um. Utilizadores elegíveis: cinco mil (clientes com mais de dez pontos de dados). Utilizadores que criaram um painel: mil. Taxa de adoção: vinte por cento. No objetivo.
Dos mil que criaram um painel: Ativos diariamente: seiscentos. Bom envolvimento. Ativos semanalmente: novecentos. A maioria usa-o pelo menos semanalmente. Abandonaram: cem. Dez por cento de cancelamentos.
Impacto na retenção: os clientes com painéis ativos têm dois por cento de cancelamentos mensais. Os clientes sem painéis têm quatro por cento de cancelamentos mensais. O painel poupa dois pontos de cancelamentos. Para uma base de mil clientes, são vinte clientes. A cem dólares de valor mensal por cliente, são dois mil de receita poupada por mês. Vinte e quatro mil por ano.
Métricas de operações
Disponibilidade no mês passado: 99.92 por cento. Objetivo: 99.95 por cento. Falhámos o objetivo.
Falhas: Um incidente: dez minutos, processamento de pagamentos em baixo. Causa: a passagem para a base de dados de reserva demorou demasiado. Um incidente: quinze minutos, pico de tempos esgotados na API. Causa: pico de tráfego mais uma consulta lenta à base de dados.
Tempo de resposta: Média: cento e cinquenta milissegundos. Bom. P95: trezentos milissegundos. Aceitável. P99: um segundo. É demasiado alto. Um por cento dos clientes sente uma espera de um segundo. Precisa de otimização.
Taxa de erros: zero vírgula oito por cento. Subiu de zero vírgula quatro por cento há duas semanas. A investigação mostra: os erros no processamento de pagamentos subiram porque o fornecedor de pagamentos teve uma falha na semana passada (não é culpa nossa), os erros da API subiram porque publicámos uma alteração de código que estragou um ponto de acesso (é culpa nossa).
Base de dados: Tempo médio das consultas: trinta milissegundos. Utilização do conjunto de ligações: oitenta por cento. Saudável. Taxa de consultas lentas: zero vírgula dois por cento. Aceitável.
Taxa de acerto da cache: sessenta e cinco por cento. Saudável.
Ligar os painéis de produto e de operações
A adoção de funcionalidades depende do desempenho do sistema. Se o sistema é lento, a adoção de funcionalidades sofre. A nova funcionalidade de painéis tem baixa adoção. Vê o painel de operações. O tempo de resposta P99 é de um segundo. Os utilizadores sentem atraso ao abrir o painel. Acrescenta à investigação: o mau desempenho está a causar a baixa adoção. Se sim, otimiza primeiro o desempenho do sistema. Depois volta a medir a adoção.
O desempenho do sistema é medido pela disponibilidade, não pelo impacto das funcionalidades. Mas o impacto das funcionalidades depende da disponibilidade. Liga os dois painéis. Quando as métricas de operações pioram, as métricas de produto também pioram.
Perguntas frequentes
Com que frequência deve o gestor de produto consultar a adoção de funcionalidades?
Primeira semana: diariamente. A funcionalidade acabou de ser lançada, a curva de adoção é mais inclinada. É preciso apanhar os problemas cedo. Semanas dois a quatro: três vezes por semana. A curva de adoção está a achatar. Atualizações semanais chegam. Depois do primeiro mês: semanalmente. A adoção estabilizou ou está a crescer de forma regular. Uma consulta semanal chega. Exceção: se a funcionalidade é crítica ou se a adoção inicial está abaixo do objetivo, a monitorização diária continua até o problema ser resolvido. Com o criador de websites da WEMASY, podes configurar isto diretamente no teu website.
Que taxa de adoção de funcionalidades é aceitável por semana?
Semana um: cinco a quinze por cento (as pessoas estão a experimentar). Semana dois: dez a trinta por cento (o passa-palavra espalha-se). Mês um: vinte a cinquenta por cento (taxa estabilizada). Varia conforme as funcionalidades. Funcionalidades de jogos podem chegar a noventa por cento de adoção. Funcionalidades de conformidade podem chegar só a dez por cento. O objetivo deve basear-se no segmento de utilizadores e na importância da funcionalidade, não numa referência genérica. Antes de lançar, decide: esta funcionalidade é para todos ou só para um segmento. Isso define o objetivo.
Como distinguimos adoção de envolvimento?
A adoção é experimentar a funcionalidade (usaram-na pelo menos uma vez). O envolvimento é usá-la repetidamente (diária, semanal, mensalmente). Uma funcionalidade pode ter alta adoção e baixo envolvimento (todos experimentaram, poucos ficaram). Pode ter baixa adoção e alto envolvimento (poucos experimentaram, mas quem experimentou adorou). As duas métricas importam. Alta adoção mais alto envolvimento é sucesso. Baixo envolvimento significa que a funcionalidade não resolve um problema real. Baixa adoção significa um problema de descoberta.
O painel de produto deve incluir feedback dos clientes ou só métricas?
Inclui os dois. As métricas dizem o que os clientes estão a fazer. O feedback diz porquê. Quinhentos utilizadores abandonaram a funcionalidade (métrica). O feedback diz “a funcionalidade é difícil de encontrar” ou “a funcionalidade não resolve o meu problema” (porquê). Métricas sem feedback são incompletas. Acrescenta uma secção de feedback com as três principais razões de cancelamento ou abandono, com base nos pedidos de apoio e em inquéritos. Implementação: acrescenta um campo de comentários à funcionalidade. Semanalmente: lê os vinte principais comentários de utilizadores e organiza-os em temas. Reporta os temas no painel.
Como definimos objetivos de disponibilidade e tempo de resposta?
Baseia os objetivos no impacto nos clientes e nos padrões do setor. Para o checkout de uma loja online: disponibilidade de 99.9 por cento, tempo de resposta abaixo de dois segundos. Para um site de marketing: disponibilidade de 99 por cento, tempo de resposta abaixo de três segundos. Para ferramentas internas: disponibilidade de 95 por cento, tempo de resposta abaixo de cinco segundos. Quanto mais crítico o serviço, mais exigente o objetivo. Ao definir o objetivo, sabe que nível de investimento é necessário. Uma disponibilidade de 99.99 por cento (quatro noves) custa três a quatro vezes mais do que uma de 99 por cento (dois noves). Garante que o objetivo compensa o custo.
O painel de operações deve disparar alertas ou só mostrar o estado?
Os dois. O painel mostra o estado atual. Os alertas disparam quando os limites são ultrapassados. Se a taxa de erros passar de um por cento durante cinco minutos, o alerta dispara. O alerta vai para o engenheiro de prevenção, que investiga. O painel serve para monitorizar durante o horário normal. O alerta serve para fora do horário ou situações críticas. Nenhum dos dois sozinho chega. Um painel sem alertas significa que os problemas são descobertos durante o horário de trabalho. Um alerta sem painel significa que a equipa fica cega para a degradação lenta até o alerta disparar. Usa os dois em conjunto.