DEV Community: Anderson Poli

Batemos a meta do NPS! Como foi?

Anderson Poli — Thu, 16 Sep 2021 18:34:01 +0000

Antes de mais nada o que é NPS?

O Net Promoter Score (NPS) é uma métrica de lealdade do cliente criada por Fred Heichheld, com o objetivo de medir o grau de lealdade dos clientes das empresas de qualquer segmento, trazendo reflexos da experiência e satisfação dos clientes.

Resumidamente é uma pesquisa feita com os clientes perguntando de 0 a 10 qual seria a probabilidade deles recomendarem o seu produto para outras pessoas.

As notas são divididas da seguinte maneira.

0 - 6: Detratores
7 - 8: Neutros
9 - 10: Promotores

Imaginem um grupo de amigos em uma mesa de bar, quando o assunto do momento é relacionado a algum produto que resolva determinado problema, e o seu produto é levantado como opção.

Detratores são aqueles que não irão recomendar por N motivos, ou por um pequeno motivo mas que para ele é importante.

Neutros ficarão em cima do muro.

Promotores recomendarão fortemente o produto, dando exemplos de problemas solucionados.

Acho NPS uma forma de medir muito ingrata, a conta para saber se você está em uma zona de excelência não é ter mais promotores do que detratores somente. Um detrator pesa bem mais que um promotor.

Por exemplo: em uma pesquisa com 50 pessoas respostas, 25 deram notas 9 e 10 (promotores), 20 deram notas 7 ou 8 (neutros) e 5 deram notas de 0 a 6 (detratores). O cálculo de NPS deve ser: 25 (promotores) – 5 (detratores) ÷ 50 (número total de pessoas que responderam) = 40%

Seu produto só começa a entrar na zona de excelência após ultrapassar a barreira de 50.

E aqui começa o nosso post =)

Aqui na Convenia, alinhamos como meta do time de produto atingir o NPS acima da zona de excelência. E sabíamos que não seria tarefa fácil, por ser um SAAS, com diversos tipos de clientes, setores etc..

Pelo título do post, já temos um spoiler que conseguimos alcançar nosso objetivo durante o ano, mas o que quero passar aqui é, quais foram as principais ações para que isso se tornasse realidade.

1 - Alinhamento com time de vendas
Sabemos que um vendedor quer vender a qualquer custo, não está errado, mas uma mudança clara foi saber vender a qualquer custo sabendo das limitações e das qualidades do produto. Normal em um time em crescimento ter desalinhamento em relação ao que o produto é capaz de fazer. Por conta disso foi importantíssimo reuniões de alinhamento com o time de vendas e produto constantes, para sanar dúvidas ou sugerir evoluções.

2 - Alinhamento com o time de CS
CS tem papel fundamental de fazer com que o cliente chegue no sucesso esperado utilizando o sistema. E como fazer isso?
Pensando fora da caixa, e porque não sugerir melhorias no produto, seja no processo de implantação para reduzir tempo gasto em alguma tarefa entregando valor mais rápido, ajudando a realizar pesquisas com clientes para entender quais são as principais dúvidas e demandas. Afinal CS é quem mais passa o tempo se relacionando com os clientes. Ter um time de CS integrado com o time de produto foi essencial, onde cada um entendeu a limitação de cada área.

3 - Produto atacando o que realmente importa
Aqui na Convenia temos um processo bem definido de priorização, escrevi sobre o tema a um tempo atrás: https://dev.to/convenia/o-que-atacar-em-produto-user-impact-score-pode-te-ajudar-a-comecar-5a8j

Tendo um processo alinhado com a estratégia da empresa, o que precisa ser feito é executar!

No momento que adiciono como tag do post a palavra alinhamento

Por que esse foi o principal motivo da chegada a meta.

Time de design pensando na melhor usabilidade, como resolver um problema da maneira mais fácil e ágil possível.

Time de engenharia focado em entregar valor rápido, não menosprezando qualidade e segurança.

Mais e ai, qual foi o NPS alcançado?
Durante todo o ano batíamos na trave, 45, 48, 43, até 49, lembra quando falei que NPS era ingrato, teve um mês que no último dia o sonho foi postergado, o time sofreu! E isso é muito legal, fomos mais fortes para a próxima rodada, até que alcançamos o 62.2. BOOOM!

Foi hora de comemorar, e entender que o trabalho apenas começou, pois chegar é difícil, se manter é muito mais. Sabemos que no próximo mês o resultado pode não ser tão bom, mas confiar no processo é essencial para isso se tornar um padrão.

O que atacar em produto? User Impact Score pode te ajudar a começar!

Anderson Poli — Tue, 08 Sep 2020 23:31:18 +0000

Criar e manter um produto digital não é tarefa das mais fáceis. No começo tudo é novidade, qualquer nova feature é recebida com festa e desenvolvida com uma baita agilidade.

Com o passar do tempo o produto que era simples começa a criar dependências e uma estrutura mais robusta. Isso traz um impacto grande na empresa pois a agilidade no desenvolvimento já não é o mesmo. E isso não está errado, ou até pode estar, existem maneiras de manter agilidade no desenvolvimento, mas isso é assunto para outro post.

O que quero abordar aqui é a necessidade de colocar na esteira de desenvolvimento algo que realmente faça sentido para o produto. Aqui entra o papel do Product Owner - PO, o cara responsável por orientar o time sobre quais tarefas/features devem ser atacadas, sempre seguindo a estratégia da empresa, que pode ser definida por um Product Manager - PM ou/e C-Levels.

Mas as vezes a empresa está no começo e não possuí estes papéis tão bem definidos, muito menos uma estratégia de priorização de produto. Lembra acima quando mencionei que o desenvolvimento de produto tende a perder a agilidade com o tempo? Imagina demandar features para o time que não tragam benefícios reais para os usuários/produto? Imagina o tempo, o custo, seus concorrentes crescendo... Tudo isso entra no pacote.

Por isso priorizar corretamente é importante, e uma maneira simples de começar é utilizar o básico do UIS - User Impact Score.

UIS: Pontuação de impacto do usuário, referente a alguma ação.

Para isso temos uma passo a passo:

1 - VOCÊ PRECISA escutar o seu usuário, seja por e-mail, chat, telefone, etc...

2 - MAPEIE as demandas e problemas, falando com os usuários você vai conseguir ter informações valiosas do que funciona no seu produto, o que seus usuários precisam, e o que mais gostam. Organize isso em alguma ferramenta, pode ser um Trello, uma planilha em excel.
Dados como Nome do cliente, tamanho da empresa, região, quantidade de funcionários etc.. O máximo de dado aqui pode ajudar no futuro.

3 - CATEGORIZE, separe as demandas e problemas por áreas do sistema, por tamanho de empresa, por região do país, algo que faça sentido para o seu modelo de negócio.

4 - FILTRE as demandas que não fazem parte da sua estratégia. Parece que não, mas irão aparecer demandas que não fazem sentido algum com o seu modelo de negócio.

Pronto, agora temos uma lista bem organizada =), com sugestões de melhorias dos usuários, problemas recorrentes e novas features. Agora é só escolher uma e atacar, certo? Errado!

5 - PONTUE cada solicitação.

Saber o impacto que cada demanda leva ao seu usuário deve ser levada em consideração.

Imagine a mesma demanda:

Fulano da Empresa ACME
"Gostaria de cadastrar a data de nascimento dos meus clientes para que no futuro eu consiga enviar um cartão de aniversário para eles."

Ciclano da Empresa XPTO
"Preciso saber a data de nascimento do meu cliente para conseguir finalizar o fluxo de pedido"

Podemos pontuar com as seguintes opções.

Not important (+0 pontos)
Nice-to-have (+1 pontos)
Important (+2 pontos)
Critical (+3 pontos)

O responsável pelo board de demandas é quem dita a pontuação, pois conhece a estratégia da empresa, possuí empatia com os usuários dos sistema, ou seja, tem uma linha/padrão de pontuação e que deve ser respeitada para todas as demandas.

Fazendo uma análise simples, para a demanda do Fulano, eu daria a pontuação: Nice-to-have (+1 ponto), me parece que não é algo que faça com que o usuário deixe de usar o meu produto, ou que impeça ele de realizar as principais tarefas que o meu software se propõem a fazer, mas pode ser uma melhoria bacana no futuro.

Para a demanda do Ciclano, entendo que o mesmo não consegue finalizar um fluxo importante que o meu produto se propõem a resolver, sendo assim, existem motivos para que o usuário se sinta insatisfeito com o produto ao ponto de cancelar, por isso, minha pontuação seria: Critical (+3 pontos)

Agora sim, temos uma demanda de inclusão de data de nascimento no cadastro do cliente mapeada, categorizada e com UIS de 4 pontos.

Fazendo isso com todas as demandas teremos uma visão macro do que é mais demandado pelos usuários, fornecendo assim um norte de evolução para o produto.

Então agora é só escolher a demanda com mais pontuação e desenvolver? Nem sempre é tão fácil, outras variáveis devem ser levadas em consideração, como tempo, custo, esforço, assunto para outro post também. =)

Fiz um post um tempo atrás sobre Funil de conversão - Validando um MVP, acredito que pode agregar bastante no processo.

Além disso conseguimos atacar um pouco a questão de levar visibilidade para o restante da empresa sobre o que está sendo feito.

Veja abaixo um relatório de uma Sprint de desenvolvimento com a evolução do UIS aqui no Convenia. Separando por áreas temos:

bloco rosa claro antes de iniciar a Sprint
bloco roxo após o término da Sprint

Na imagem fica claro que: o time trabalhou fortemente em demandas relacionadas ao segundo bloco, saindo de 242 pontos de UIS para 212, diminuindo as demandas e evoluindo o produto em uma áreas específica do sistema.

Com isso, temos o básico do básico para iniciar uma priorização de produto e apresentar resultados. O que achou?

Em caso de dúvidas fico a disposição =)

Além disso estamos sempre com vagas para o time de produto https://convenia.gupy.io

Abs

Funil de conversão - Validando um MVP

Anderson Poli — Tue, 11 Aug 2020 18:38:23 +0000

Recentemente lançamos aqui no Convenia um MVP (Minimum Viable Product ou Mínimo Produto Viável) na nossa área de benefícios, com a principal motivação de entender se seria possível vender produtos de parceiros diretamente para os RHs das empresas, sem a necessidade de ter um intermediador (vendedor) no processo.

Mas para isso ocorrer deveríamos seguir fielmente o propósito de um MVP que é ter um produto bem feito, sem falhas, sendo uma versão mais "clean" e que resolva o problema que gostaríamos de validar, neste caso se o RH contrata ou não um benefício.

A primeira etapa foi desenhar a ideia, normalmente poderia ser feito em papel, ou em qualquer ferramenta de wireframes. Nosso time de UXs com o passar do tempo deixou de utilizar essas opções, e com a evolução do nosso design system normalmente entregam um esboço além das expectativas.

Além de pensar no MVP, o time de UXs já pensa em possíveis melhorias futuras, acrescentando outras áreas do sistema, simulando como poderia ser a evolução da área. Para o MVP, existe um alinhamento com o PO e com o time de desenvolvedores para entender o que seria viável para a primeira entrega em um curto espaço de tempo, e assim separando os principais itens para o processo de desenvolvimento.

Alinhada a expectativa entre produto, uxs e desenvolvedores, se inicia o desenvolvimento.
Neste caso específico o projeto durou um pouco menos de 8 dias trabalhados.
E o resultado foi:

Veja que o resultado foi bem mais simples do que o proposto pelos UXs em um primeiro momento.

MVP finalizado chegou a hora de ter maneiras de mensurar se o projeto foi bem sucedido ou se falhou em alguma etapa para conseguirmos atacar o problema, caso tenha.

Para esse teste específico utilizamos a dupla do barulho Tag Manager + Analytics.

Foi importante uma boa estruturação do código para conseguirmos emitir eventos por meio do Tag Manager. Veja abaixo como o call to action de visualizar informações de um benefício foi criado com um data atribute 'data-exclusive-benefit-open', nele é adicionado o nome do parceiro.

Já no Tag Manager criamos uma variável que ficaria responsável por mandar para o data layer o valor do nome do data atribute criado.

Com a variável criada criamos uma tag responsável por emitir um evento para o analytics, essa tag é a responsável por mandar junto do evento o valor da variável que criamos na etapa anterior e mais informações do usuário logado.

Feito isso só faltou criar um trigger para executar essa tag.

Seguimos esse padrão para as 3 etapas que gostaríamos de obter dados do MVP.

1 - Acesso a página de benefícios (neste caso sem a informação do parceiro)
2 - Clique o call to action
3 - Contratação do benefício

Com isso temos dados valiosos no analytics onde podemos por exemplo criar um funil de conversão e atacar possíveis problemas.

Por exemplo nesta imagem, por que apenas 5% dos usuários que acessaram a área de benefícios converteram?

E que se inicie uma nova etapa de entrevistas com os usuários, teste a/b entre outras formas de validação para identificarmos os problemas =)

E ai? Visualiza no projeto que está trabalhando alguma forma de aplicar um fúnil de conversão ou uma integração entre Tag Manager e Analytics?

Em caso de dúvidas fico a disposição =)

Além disso estamos sempre com vagas para o time de produto:
https://convenia.gupy.io

Abs