Algumas métricas que podem ajudar PM e Tech Product Manager diariamente
Criar um produto é fácil? Não, mas sem dúvidas as demais fases do ciclo de vida do produto são também muito complexo e fica ainda mais difícil sem nenhum norte. Se temos um norte, surge uma nova demanda: Como vamos saber se estamos indo na direção certa?
Métricas!
Para quem leu o último artigo (clique aqui), vai lembrar de uma palavra que repeti váááááárias vezes: Contexto.
Métricas x Contexto
Usando como referência esse artigo do ProductPlan:
Métricas são uma medida quantificável que permite que as empresas definam e acompanhem o sucesso de um produto ou atividade de negócios. As métricas são usadas por Stakeholders, profissionais de marketing e equipe Tech Product Managers para detectar problemas, definir metas e tomar decisões baseadas em dados. Esses problemas podem estar relacionados tanto aos esforços de engenharia quanto aos resultados do produto final.
O contexto para escolha dessas métricas para Tech Product Managers faz total diferença. No meu caso por exemplo, não temos um funil para aquisição de leads e esses leads convertidos em usuários. Toda a aquisição é realizada através dos nossos RSM (Regional Sales Managers). Eles tem mapeados o controle da carteira/região que atuam, e são responsáveis pela solicitação da criação dos usuários e suas permissões. Ou seja, no meu contexto de B2B e com um modelo de negócios orientado a gestão regional de clientes, essa visão de aquisição não faz sentido monitorar.
Já para alguns dos profissionais com quem conversei, isso faz total sentido. Como por exemplo para alguns produtos da Remessa Online com os quais o Gean tem contato.
Como escolher a métrica certa para o meu contexto?
Essa pergunta pode ter um começo de resposta mais fácil, se você Tech Product Manager, tem acesso ou sabe quais são os principais KPIs dos quais sua área/produto esta envolvida ou saber claramente o momento do ciclo de vida do seu produto. Aqui a Matriz BCG pode encaixar como uma luva (recebaaaa).
Segundo o Vida de Produto, a matriz BCG (também conhecida como “Matriz de Boston” ou “Matriz de Participação no Crescimento”) é uma matriz desenvolvida por Henderson no grupo Boston Consulting nos anos 70. É uma matriz que ajuda na tomada de decisões e investimentos de uma empresa. A matriz primeiro divide o mercado com base em 2 eixos:
- Quota de participação de mercado: a participação de mercado da empresa por produto no mercado em comparação com seus concorrentes / categoria geral;
- Taxa de crescimento do mercado: a taxa de crescimento da indústria como um todo. Essa taxa é levada em consideração a partir da qual a taxa de crescimento do produto é extrapolada.
E apresenta quatro quadrantes, onde os produtos podem ser classificados em qualquer um deles e as estratégias para esses produtos são decididas de acordo.
- Interrogação: baixa participação de mercado e alta taxa de crescimento (incerteza).
- Estrela: alta participação de mercado e alta taxa de crescimento (alta concorrência).
- Vaca leitura: alta participação de mercado, mas baixa taxa de crescimento (mais rentável).
- Cachorro: baixa participação de mercado e baixa taxa de crescimento (menos lucrativo ou até lucrativo)
Legal Alfredo, mas isso vai me ajudar a tomar que decisão? Talvez onde colocar mais investimentos, ajudar na priorização do roadmap, e até no tempo do time em discovery de algumas hipóteses para atacar no próximo quarter. Enfim, o uso fica a critério do freguês.
Complicou?
Mas se você não tem isso bem claro, vou compartilhar o que estou encontrando nas andanças no mercado. Durante minhas pesquisas com a galera Tech Product Manager de empresas como CI&T, Remessa Online, Olx Portugal, Thoughtworks e Pagar.me, percebi que a grande maioria das métricas para Tech Product Managers envolviam Negócios e Tecnologia. Onde tecnologia até pode ser dividido em performance x custo.
Cogitando facilitar a visão, pensei em criar o Super Trunfo das métricas para Tech Product Managers. O Super trunfo era um jogo de cartas que, na minha infância, nós brincávamos com a versão de carro. Cada carta era um carro especifico e nela tinha detalhes desse modelo. Por exemplo: Motor, aceleração, carroceria, potência, 0-100km/h e outras métricas/características específicas daquele carro. Trazendo para nossa realidade, cada métrica terá um compilado de características de onde aplicar.
Abrindo o deck de cartas do super trunfo
Regras do jogo
Para garantir que você tenha o mesmo entendimento que eu tive na criação das métricas abaixo, vou pontuar a única regra para melhor entendimento: as bolinhas
Quanto maior a quantidade de bolinhas preenchidas, maior a participação deste item na métrica e/ou maior sua aplicabilidade no item e/ou maior a sua responsabilidade.
Por exemplo: Regra XPTO
B2B ⚫⚫⚪⚪⚪ Pode se aplicar xpto no contexto B2B, mas não é o melhor cenário
B2C ⚫⚫⚫⚫⚫ Se aplica bem no contexto B2C
Platform ⚫⚫⚪⚪⚪ Envolve pouca responsabilidade em times de Platform
Integrations ⚫⚫⚫⚫⚫ Muita responsabilidade do time de integrations
IT Resourses ⚫⚪⚪⚪⚪ Pouca aplicabilidade de recursos de infra para uso
Business ⚫⚫⚫⚫⚫ Muita responsabilidade do time de negócios sobre as diretrizes da métrica xpto
Customer interface ⚫⚫⚫⚫⚫ Muita responsabilidade dos times que se envolvem diretamente com cliente
Tomando como premissa que estamos com esse entendimento, bora ver as cartas!
Tempo de atendimento – customer
B2B ⚫⚫⚫⚫⚪
B2C ⚫⚫⚫⚫⚫
Platform ⚫⚫⚪⚪⚪
Integrations ⚫⚫⚫⚫⚫
IT Resourses ⚫⚪⚪⚪⚪
Business ⚫⚫⚫⚫⚫
Customer interface ⚫⚫⚫⚫⚫
Nessa métrica o objetivo é impactar diretamente no resultado para o cliente final. Em um exemplo, a integração dos produtos do ERP para a plataforma, ocorrendo em uma periodicidade diária, não estava refletindo as mudanças do porfólio e os clientes acabavam acionando o suporte para dúvidas. Com o indicador do suporte confirmando a origem das dúvidas, essa métrica pode ajudar na tomada de decisão para diminuir o intervalo das integrações.
Tempo de atendimento – developer
B2B ⚫⚫⚪⚪⚪
B2C ⚫⚫⚪⚪⚪
Platform ⚫⚫⚫⚫⚫
Integrations ⚫⚫⚫⚫⚫
IT Resourses ⚫⚪⚪⚪⚪
Business ⚫⚫⚫⚫⚫
Customer interface ⚫⚪⚪⚪⚪
Esse ponto impacta diretamente na performance do time de desenvolvimento. Quanto tempo uma task/demanda leva para ser atendida, avaliada e mudar para o próximo status? Pode ser um indicador de performance do time atrelado a capacidade do time versus volume das atividades. Um possível output seria o aumento da equipe.
Tempo de processamento do pacote (status 200 para client)
B2B ⚫⚫⚫⚫⚪
B2C ⚫⚫⚫⚫⚪
Platform ⚫⚫⚫⚫⚫
Integrations ⚫⚫⚫⚫⚪
IT Resourses ⚫⚫⚫⚫⚫
Business ⚫⚫⚫⚫⚪
Customer interface ⚫⚫⚫⚪⚪
Em um cenário onde a integração do cliente (interno ou externo) é um ponto crítico, identificar o tempo de processamento dos pacotes é crucial. Com isso, podemos mensurar quanto tempo demoramos para retornar o status 200 com determinado volume. Se aumentarmos o volume, o tempo permacene igual? Se não, quantos retornam com falha?
Perceba que aqui pode ser apenas um gatilho para monitoramento e cruzamento com outras métricas.
Tempo de uso/pagina
B2B ⚫⚫⚫⚪⚪
B2C ⚫⚫⚫⚪⚪
Platform ⚫⚫⚫⚪⚪
Integrations ⚫⚪⚪⚪⚪
IT Resourses ⚫⚫⚫⚫⚫
Business ⚫⚫⚫⚪⚪
Customer interface ⚫⚫⚫⚫⚫
Nessa métrica podemos identificar dois possíveis outputs:
1) Nessa página, o user fica mais tempo porque temos mais informações relevantes para ele? Podemos melhorar a performance, usabilidade ou até mostrar o link de acesso dela em outras páginas?
2) Nessa página, o user fica mais tempo porque temos mais processamento de informação ou rotinas? podemos otimizar?
Tempo de jobs executarem (status x erros)
B2B ⚫⚫⚫⚫⚫
B2C ⚫⚫⚫⚫⚪
Platform ⚫⚫⚫⚪⚪
Integrations ⚫⚫⚫⚫⚫
IT Resourses ⚫⚫⚫⚫⚫
Business ⚫⚪⚪⚪⚪
Customer interface ⚫⚪⚪⚪⚪
Dependendo do cenário, monitorar jobs específicos que a aplicação roda pode ser o trigger para identificar possíveis problemas antes mesmo deles acontecerem ou se tornarem mais críticos. Por exemplo, uma aplicação conecta em um cloud server, e executa um job responsável por popular uma view. Esse job, monitorado, informa que a cada 10 execuções, 4 retornam com falha. Aqui cabe uma possível análise dos logs para entender o motivo do comportamento a fim de garantir 100% das transações com sucesso.
Uptime x Downtime
B2B ⚫⚪⚪⚪⚪
B2C ⚫⚪⚪⚪⚪
Platform ⚫⚫⚫⚫⚪
Integrations ⚫⚫⚫⚫⚪
IT Resourses ⚫⚫⚫⚫⚫
Business ⚫⚫⚫⚫⚫
Customer interface ⚫⚪⚪⚪⚪
Nesse caso é uma métrica que pode até ser recurso de marketing e/ou venda. Qual empresa não gostaria de promover um sistema/app/plataforma capaz de ter um uptime extremamente alto? Dependendo do contexto, pode ter a métrica para esse fim ou indicar possíveis ajustes na infra dos servidores minimizem o downtime para o user.
Quantidade de requests (get/post) em determinado endpoint
B2B ⚫⚪⚪⚪⚪
B2C ⚫⚪⚪⚪⚪
Platform ⚫⚫⚫⚫⚫
Integrations ⚫⚫⚫⚫⚫
IT Resourses ⚫⚫⚫⚫⚫
Business ⚫⚫⚫⚪⚪
Customer interface ⚫⚪⚪⚪⚪
Nesse ponto é possível identificar possíveis gargalos que gerem aumento de recursos mas também pode ser usado em conjunto com métricas/indicadores de segurança para identificar a origem das requisições e analisar possíveis tentativas incomuns.
Número medio de transações x custo infra cloud
B2B ⚫⚪⚪⚪⚪
B2C ⚫⚪⚪⚪⚪
Platform ⚫⚫⚫⚫⚫
Integrations ⚫⚫⚫⚫⚫
IT Resourses ⚫⚫⚫⚫⚫
Business ⚫⚫⚫⚫⚪
Customer interface ⚫⚫⚪⚪⚪
Já nesse ponto, a quantidade de transações tem o viés de custo do projeto. Por exemplo, precisamos mudar a configuração dos servidores AWS pois pela quantidade de transações atual, o custo aumentou. Um outro ponto seria transações com serviços terceiros, por exemplo o Twilio. A comercialização pode ser por quantidade de requests e precisamos saber se estamos fazendo somente requests necessários para evitar gastos desnecessários.
Capacidade da solução entregar valor
B2B ⚫⚪⚪⚪⚪
B2C ⚫⚪⚪⚪⚪
Platform ⚫⚫⚫⚫⚫
Integrations ⚫⚫⚫⚫⚫
IT Resourses ⚫⚪⚪⚪⚪
Business ⚫⚫⚫⚫⚫
Customer interface ⚫⚪⚪⚪⚪
Subjetivo né? Depende do contexto né? Sim!!! Aqui, pelas conversas, é uma métrica que pode ser o resultado de um conjunto de métricas. A seguir, algumas métricas para Tech Product Managers que podem estar nesse conjunto:
- Número de entregas
- Entrega dentro do prazo
- Precisão – reabertura de tasks?
- Capacidade do time vs. capacidade disponível
- Tempo médio por entrega
- Custo Médio de cada Entrega
Monitoramento de escala
B2B ⚫⚫⚫⚫⚪
B2C ⚫⚫⚫⚫⚪
Platform ⚫⚫⚪⚪⚪
Integrations ⚫⚫⚫⚫⚪
IT Resourses ⚫⚫⚫⚫⚫
Business ⚫⚫⚫⚫⚫
Customer interface ⚫⚫⚫⚫⚪
Em cenários como, black friday para o varejo, há um período específico onde o volume é maior e a aplicação precisa ter a habilidade de alocar mais recursos e ainda se tornar performática.
Monitoramento de erros
B2B ⚫⚫⚪⚪⚪
B2C ⚫⚫⚪⚪⚪
Platform ⚫⚫⚫⚫⚫
Integrations ⚫⚫⚫⚫⚫
IT Resourses ⚫⚫⚫⚫⚫
Business ⚫⚫⚫⚫⚫
Customer interface ⚫⚫⚪⚪⚪
Os erros fazem parte do dia-a-dia e até, alguns deles, você conhece pelo nome, conhece a família e até onde mora. Mas é fundamental que existam planos de ação para erros mapeados. E essa métrica é o ponto de partida desses planos.
Monitoramento de geração de arquivos
B2B ⚫⚫⚪⚪⚪
B2C ⚫⚫⚪⚪⚪
Platform ⚫⚫⚫⚫⚫
Integrations ⚫⚫⚫⚫⚫
IT Resourses ⚫⚫⚫⚫⚫
Business ⚫⚫⚫⚫⚫
Customer interface ⚫⚫⚪⚪⚪
Um indicador que onera performance é i/o. E certamente a quantidade de arquivos e até logs, pode impactar tanto no consumo de recursos de processamento quanto de espaço em disco (dependendo da rotina de limpeza e/ou sobrescrita).
Http bad request/not found
B2B ⚫⚫⚪⚪⚪
B2C ⚫⚫⚪⚪⚪
Platform ⚫⚫⚫⚫⚫
Integrations ⚫⚫⚫⚫⚫
IT Resourses ⚫⚫⚫⚫⚫
Business ⚫⚫⚫⚫⚫
Customer interface ⚫⚫⚪⚪⚪
Segundo o Mozilla, O código de status de resposta HTTP 400 Bad Request indica que o servidor não pode ou não irá processar a requisição devido a alguma coisa que foi entendida como um erro do cliente (por exemplo, sintaxe de requisição mal formada, enquadramento de mensagem de requisição inválida ou requisição de roteamento enganosa).
Cost per message x return
B2B ⚪⚪⚪⚪⚪
B2C ⚪⚪⚪⚪⚪
Platform ⚫⚫⚫⚫⚫
Integrations ⚫⚫⚫⚫⚫
IT Resourses ⚫⚫⚫⚫⚫
Business ⚫⚫⚫⚫⚫
Customer interface ⚪⚪⚪⚪⚪
Aqui eu posso repetir o exemplo do Twilio adicionando algum parametro do disparo. Por exemplo, cada disparo retorna um status. Assim podemos comparar o custo para envio versus o envio com sucesso. Em um cenário de notificações relevantes, é uma excelente métrica para mensurar a qualidade do serviço terceiro.
Jornada do usuario (monitorando etapas até 100% do mapeado para aquele perfil)
B2B ⚫⚫⚫⚫⚫
B2C ⚫⚫⚫⚫⚫
Platform ⚫⚪⚪⚪⚪
Integrations ⚫⚫⚪⚪⚪
IT Resourses ⚫⚪⚪⚪⚪
Business ⚫⚫⚫⚫⚫
Customer interface ⚫⚫⚫⚫⚫
Como quase toda métrica e conceito que falo por aqui, dependendo do contexto, mapear a jornada do usuário pode ser importante. Algumas ferramentas de onboarding podem te ajudar a criar fluxos e conduzir o usuário a completar as etapas mapeadas. A cada etapa, um checkpoint é marcado e através dele, essa métrica é baseada. Por exemplos, quantos usuários chegaram até a etapa 3? Quantos chegaram a etapa final? Quantos saíram da etapa 1? Cada output pode ter uma ação específica.
DAU / MAU (Daily/Monthly active users)
B2B ⚫⚫⚫⚫⚫
B2C ⚫⚫⚫⚫⚫
Platform ⚫⚪⚪⚪⚪
Integrations ⚫⚫⚪⚪⚪
IT Resourses ⚫⚫⚫⚪⚪
Business ⚫⚫⚫⚫⚫
Customer interface ⚫⚫⚫⚫⚫
Número de usuários únicos que interagem com seu aplicativo em um dia/mês específico. Esses usuários concluíram alguma ação em seu produto, como fazer login, preencher um formulário, clicar em um botão – até mesmo se inscrever pela primeira vez.
Performance por ticket
B2B ⚫⚫⚫⚫⚫
B2C ⚫⚫⚫⚫⚫
Platform ⚫⚪⚪⚪⚪
Integrations ⚫⚫⚫⚪⚪
IT Resourses ⚫⚫⚫⚪⚪
Business ⚫⚫⚫⚫⚫
Customer interface ⚫⚫⚫⚫⚫
Em primeiro lugar, segundo o blog Agendor, a curva ABC é uma das principais formas de classificar clientes. Ela consiste em categorizar de acordo com a sua participação no faturamento da sua empresa. Assim, conseguiremos identificar na categoria A, os clientes com mais participação no faturamento e consequentemente, maior representatividade de atenção das tomadas de decisão da sua empresa. A performance e todos os aspectos que norteiam uma boa experiência, devem ser ainda mais exigidas pelas maiores categorias de cliente. E é nesse ponto que essa métrica se encaixa.
Analisar volume de transações, erros, custo e algumas das métricas acima, aliada a visão de categoria de cliente, pode te dar insights valiosos para tomadas de decisão e estar alinhado ao time de negócio.
Nps, Churn, Upsell, Cross sell vinculado integração/performance
B2B ⚫⚫⚫⚫⚫
B2C ⚫⚫⚫⚫⚫
Platform ⚫⚪⚪⚪⚪
Integrations ⚫⚪⚪⚪⚪
IT Resourses ⚫⚪⚪⚪⚪
Business ⚫⚫⚫⚫⚫
Customer interface ⚫⚫⚫⚫⚫
Todo produteiro deve estar bem familiarizado com esses termos e não quero ser redundante por aqui. O ponto a ser considerado com essas métricas, é o efeito do trabalho realizado na plataforma ou produto, impactando diretamente essa métrica coorporativa. Para mensurar algo desse genêro, o caminho mais fácil é o time da plataforma/produto, a cada interação com o cliente, mapear a satisfação (positiva ou não) e possíveis novas vendas geradas nesse contato. Esses dados coletados, os indicadores serão alimentados e teremos números diretamente relacionados a solução.
Em alguns casos, fica mais difícil coletar esses dados, e o NPS geral pode acabar sendo balizado com o viés da tecnologia. Por exemplo: o produto/plataforma teve uma significativa melhoria/feature liberada no último período de avaliação do NPS e, na nova pesquisa, os valores percebidos foram maiores que o exercicio anterior. Podemos afirmar que a melhora foi exclusiva da feature? Não, mas podemos indicar influência.
Bônus
Nesse conjunto de métricas para Tech Product Managers que grandes profissionais e empresas estão de olho se categorizam em dois indicadores possíveis: Leading ou Lagging
Segundo Bernard Marr, uma das melhores maneiras de gerenciar o desempenho é mesclar os insights de indicadores retroativos (Lagging) com insights e previsões mais avançados (Leading).
É aí que esta a principal diferença entre os dois:
- Um Leading indicator prevê resultados e eventos futuros.
- Um Lagging indicator analisa se o resultado pretendido foi alcançado.
Um indicador financeiro como receita, por exemplo, é um Lagging indicator, pois informa sobre o que já aconteceu.Teoricamente, a receita do ano passado não prevê a receita futura (embora tenha sido usada para fazer exatamente isso por muitas empresas no passado). Mas um indicador como a satisfação do cliente aponta para a receita futura – porque os clientes satisfeitos são mais propensos a recomprar e contar a seus amigos sobre sua empresa. A satisfação do cliente, portanto, é um Leading indicator.
Todas as métricas para Tech Product Managers, basicamente, vão conectar ao seu contexto para encontrar o Outcome. Geralmente o norte (cabe a menção a North Star Metric) pode ser um conjunto dessas métricas com indicadores pré estabelecidos como ótimos. Mas tanto o objetivo do jogo, quanto das empresas é ganhar o jogo.
Deck fechado
Bom pessoal, a pesquisa levou bastante tempo e consolidar todos esses dados, categorizar e depois dar exemplos o mais didáticos possíveis levou mais tempo que imaginei. Normal, mais um dia comum na vida de um Tech Product Manager…. No entanto, mas mais uma vez vou agradecer o apoio de todo mundo que me ajudou durante a jornada e também deixar a porta aberta pra gente trocar ideia sobre o tema (Linkedin ou Instagram). Afinal, quanto maior o deck, melhor preparados estaremos pra a próxima batalha.
Próximo passo: Segurança
