Resumo: 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.
Como gerentes de produto, aproveitamos todas as oportunidades para saber mais sobre nossos clientes, pois entender suas necessidades é fundamental para a criação de produtos úteis. Isso significa conduzir entrevistas de cliente, fazer pesquisas e examinar as análises de produtos. Os dados que inferimos da análise de produtos nos mostram como os usuários realmente usam o produto – não o que eles querem fazer, como pensam que estão usando ou até mesmo como achamos que eles estão usando.
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 recursos 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 recursos
Vamos começar!
Teste o Jira Product Discovery, é grátis
Priorize, colabore e forneça novas ideias de produtos — e construa para causar impacto.
O que é análise de produtos?
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.
A fim de obter uma compreensão quantitativa do que os usuários estão fazendo com o produto, o primeiro passo é implementar a análise de produtos. A ideia é acionar um evento para cada ação que um usuário pode tomar no produto para que você obtenha uma exibição agregada de quantos usuários usam um recurso e a frequência de uso. Por exemplo, se você quer controlar o número de vezes que um usuário clica em um botão específico, você pode acionar um evento chamado "big-red-button.click". Então, será possível ver quais recursos precisam de trabalho, quais são os mais importantes e usar essa informação para priorizar as mudanças.
Há várias soluções que fornecem uma estrutura para adicionar eventos de análise e rastreá-los. Como ponto de partida, confira o Google Analytics ou o KISSmetrics
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.
"Dívida de empatia": o mais novo tipo de dívida
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ários recursos 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 um recurso específico 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.
Testando o futuro antes que ele esteja aqui
Embora a adição de análise do produto possa ser valiosa para a compreensão de como os usuários usam os recursos existentes, ela também é extremamente valiosa para testar novos recursos e experiências. Se você tem um objetivo claro de quanto quer que seu recurso seja utilizado, 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 os novos recursos desta forma.
- Não há nada pior do que chegar ao final de um teste e perceber que você não tem todos os eventos necessários... Tente fazer sua análise antes de executar o teste usando alguns dados fictícios, assim você verá rapidamente eventuais lacunas no que está capturando.
- Chegar a uma hipótese pode ser demorado, mas você precisa ter certeza de que tem uma e que você está confiante que pode prová-la ou refutá-la com a análise do produto antes do lançamento. Fazer uma análise sobre dados fictícios antes do lançamento ajudará você a testar isso também.
- Certifique-se de fazer o teste com usuários suficientes e por um tempo suficiente. Você quer certificar-se de que seus resultados são estatisticamente significantes.
- Estar preparado descartar más ideias! Como mencionei, você quer testar recursos menos custosos possíveis e executar esses testes tão rápido quanto possível. Falhar rápido é bom.
Apenas não se esqueça de ouvir seus usuários também
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 um recurso específico, 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.
