O que cada gerente de produto precisa saber sobre análise de produto

Como gerentes de produto, a gente aproveitou todas as oportunidades que temos para aprender mais sobre nossos clientes, pois entender as necessidades deles é fundamental para criar produtos úteis. Isso significa fazer entrevistas com clientes, fazer pesquisas e examinar os dados de análise do produto. Os dados que a gente coletou da análise de produtos nos dizem como os usuários de fato usam o produto — não o que eles querem fazer, como acham que estão usando os produtos ou até mesmo como achamos que estão usando esses dados.

A metodologia ágil é usada quando o desenvolvimento de software difere e a criação de um software próprio seria definitivamente benéfico. O método ágil permite que várias equipes respondam às mudanças rapidamente. Então, como a entrega contínua do método ágil, um método baseado na frequência, existe com um planejamento de cenário a longo prazo? É possível criar uma previsão realista para um período longo, sabendo que a única constante é a mudança?

Como um PM, perguntas como, "quanto tempo os usuários gastam por dia?", "quais ações mais tomam?" e "com quais funções se acostumar menos?" são muito valiosas para a compreensão dos usuários e nos mostram como melhorar a sua experiência. Nessa publicação, vou explicar o que a análise do produto é e por que você deve usá-la; como obter verdadeira compreensão dos usuários para poder pagar a "dívida de empatia"; e como usar a análise para ajudar na orientação de novos desenvolvimentos de funções

Vamos começar!

A análise de produtos é o processo de analisar como os usuários se engajam com um produto ou serviço. Ela possibilita que as equipes acompanhem, visualizem e analisem o engajamento do usuário e os dados comportamentais. As equipes usam estes dados para aprimorar e otimizar um produto ou serviço.

Para entender de maneira quantitativa o que os usuários estão fazendo com o produto, a primeira etapa é implementar a análise de produtos. A ideia é acionar um evento para cada ação que um usuário pode executar no produto. Assim, você tem uma visualização agregada de quantos usuários usam uma função e a frequência disso. Por exemplo, se você quer acompanhar o número de vezes que um usuário clica em um botão específico, basta acionar um evento chamado “botao-vermelho-grande.clique”. Assim, é possível ver quais funções precisam de ajustes e quais são as mais importantes, além de usar essas informações para priorizar as alterações.

Na Atlassian tentamos facilitar ao máximo para que todos obtenham dados e possam executar suas próprias consultas e relatórios. Usamos algumas ferramentas desenvolvidas pela própria empresa para oferecer estes serviços, mas ferramentas, como o Google Analytics, também vão ajudar você a começar. Esse uso fez com que todos, de desenvolvedores a PMs e designers, fizessem perguntas e tentassem compreender o impacto do que a gente criou.

Vamos testar este novo termo, "dívida de empatia".

A análise do produto pode ajudá-lo a pagar a dívida de empatia de duas maneiras: com feedback qualitativo reunido por meio de atividades, como teste de conceito e entrevistas com clientes; e com dados quantitativos coletados no produto com itens como análise de produto e pesquisas NPS.

Como exemplo,  o Confluence está sendo usado há bastante tempo e tem várias funções que têm pouca ou nenhuma análise. Um desses é o painel, que é o início da jornada da maioria das pessoas com o Confluence. Recebemos alguns feedbacks sobre o painel de entrevistas do cliente, mas não tínhamos todas as análises do produto necessárias para realmente entender o uso de uma perspectiva quantitativa. Recebemos várias perguntas sem resposta, como:

• De quanto é o uso do painel? Quantas vezes as pessoas acessam o painel em uma típica sessão de confluência?

• Para o que as pessoas realmente usam o painel? O feed Todas as atualizações? O feed Popular? Navegação a um espaço?

• O que as pessoas querem no painel? Podemos determinar as melhores coisas a abranger com base no que as pessoas fazem após acessar o painel?

Estas são algumas perguntas fundamentais para as quais precisávamos de respostas antes de embarcar em uma mudança para uma das páginas mais visitadas no Confluence. Se não tiver análise em seu produto, ou mesmo uma função específica que está pensando em mudar, então você está no mesmo barco e deve ser muito cauteloso sobre quaisquer decisões. Está na hora de pagar essa dívida de empatia!

Nos testes de painel, aprendemos que uma das ações mais comuns tomadas no painel era ver as "páginas favoritas". Este foi um achado superimportante e que não tinha tanta relevância na hipótese inicial. O que nos leva ao argumento principal aqui: pague dívida de empatia assim que puder – se não houver análise do produto, adicione-a o mais rápido possível e comece a usar dados para ajudar a informar suas decisões de produto. Caso contrário, você vai tomar decisões importantes no escuro. E se lembre de que as análises não mentem! Elas nos mostram bem o que os usuários estão fazendo com o produto, mas tente ir um pouco além e use a análise para entender o que os usuários querem de verdade.

Embora a adição de análise do produto possa ser valiosa para a compreensão de como os usuários usam as funções existentes, ela também é extremamente valiosa para testar novas funções e experiências. Se você tem um objetivo claro de quanto quer que sua função seja utilizada, a análise de produto ajuda você a trabalha de acordo com o antigo mantra ágil de falhar rapidamente e iterar até ter êxito.

O processo que usamos geralmente é parecido com este:

• Defina uma hipótese clara para uma mudança de produto – por exemplo "Ao aumentar o tamanho da caixa de comentário, esperamos ver um aumento de 5% nos comentários."

• Criar a implementação menos custosa possível dessa mudança, carregada com quaisquer eventos de análise que precisamos, o que nos permitirá testar nossa hipótese.

• Implantar a mudança a um subconjunto de clientes em um teste A/B.

• Brincar com os nossos polegares enquanto esperamos os resultados.

• Fazer uma repartição dos resultados, com a ajuda de um analista em caso de alterações mais complexas e decidir se a mudança foi bem-sucedida.

Para nossas mudanças no painel acabamos criando três painéis muito "opinativos", cada um promovendo um caso de uso diferente e um conjunto de comportamentos. Fizemos a comparação por meio desse processo (apesar de nossa hipótese ter sido um pouco mais complicada) e isso funcionou muito bem para nós. Mas há algumas armadilhas comuns que aprendemos – às vezes, da maneira mais difícil – sobre as quais você deverá pensar antes de testar as novas funções desta forma.

Como mencionei acima, é ótimo ter informações advindas dos dados, mas ser totalmente direcionadopelos dados pode, às vezes, não deixar que você veja a experiência geral que está criando para os usuários. Depender totalmente dos dados também pode ser um pouco prejudicial quando for necessário tomar decisões e você não tiver os dados necessários.

A análise de produto expõe a realidade crua de como as pessoas usam o produto, ou até mesmo uma função específica, mas isso pode ser muito unidimensional. Combinar o que você acha que sabe de dados de análise de produto com feedback qualitativo em entrevistas do cliente, workshops de teste de conceito e debates pode dar uma visão mais completa do que está acontecendo para que você possa criar o melhor produto possível.