Hoje, todas as empresas adoram big data e quase todas as empresas definitivamente terão um departamento de analistas de ciência de dados. No entanto, não há um entendimento claro no setor sobre quem é um analista de produtos e como ele difere de um cientista de dados ou pesquisador de UX que se concentra em métodos quantitativos.
Cada vez mais, há uma divisão de analistas de produtos que:
- definir metas e métricas, determinar o vetor de desenvolvimento do produto
- investigar a natureza dos fenômenos, identificar relações causais
- construir algoritmos preditivos
Por exemplo, uma estrutura semelhante no Indeed é semelhante :
Neste artigo, quero resumir um pouco de especialistas dedicados exclusivamente ao aprendizado de máquina e falar sobre a visão do papel da análise de produto no Wrike e sobre as tarefas que nossa equipe de produto tem que trabalhar diariamente.
Qualitativo versus Quantitativo
Como regra, desenvolvedores e piemas adoram números: dados quantitativos ajudam a capturar com precisão o estado atual, mostrar dinâmica, avaliar perspectivas de mercado. É frequentemente esquecido que os próprios números não oferecem uma oportunidade de dar uma resposta sobre a motivação das pessoas, sobre a causa raiz de sua escolha e outras ações.
Qualitativo antes do Quantitativo: Como os métodos qualitativos suportam melhor ciência de dados
Portanto, na Wirke, não estabelecemos uma divisão clara entre analistas que organizam pesquisas qualitativas e quantitativas. Pelo contrário, em nossa opinião, em uma equipe pequena (somos cerca de 10), precisamos ser capazes de combinar essas habilidades o máximo possível, usando métodos quantitativos para desenvolver as idéias da análise qualitativa , que geralmente é realizada em conjunto com o gerente de produto e o designer.
De fato, quando se trata de pesquisa, temos duas expectativas do analista. Ele deve ser capaz de:
- encontre pontos promissores de crescimento de produtos
- validar o problema formulando e dimensionando-o
Em seguida, falaremos mais sobre essas duas expectativas e mostraremos exatamente como o analista cumpre o papel de conexão entre o entendimento comercial do problema e os métodos quantitativos que os ajudam a dimensionar e validar.
1. Encontre pontos de crescimento do produto
Um analista é uma pessoa que encontra pontos promissores de crescimento de produtos, ampliando problemas e tarefas.
O primeiro passo para entender qualquer tarefa de um analista de produto é determinar a qual classe de problemas ele pertence. Três tipos de pesquisa são geralmente distinguidos:
- Descoberta de problemas - quando não sabemos quais problemas os usuários têm fora de uma funcionalidade específica do produto. Esta é geralmente a fase da entrevista.
- Validação de problemas - quando parecemos saber que existem determinadas tarefas, mas queremos verificar se um número realmente grande de usuários as possui. Esta é a fase de várias pesquisas.
- Validação de uma solução (validação de solução) - quando verificamos soluções já específicas que criamos ou prototipamos. Prototipagem em estágio ou teste beta.
O analista está envolvido nas três etapas da pesquisa, no entanto, o foco principal do trabalho geralmente recai na validação de problemas e soluções. Suponha que um gerente de produto, juntamente com um analista e um profissional de marketing, conduziu vinte entrevistas com clientes diferentes. Como entendemos que essas conclusões podem ser confiáveis e que os problemas expressos são realmente relevantes para todos os usuários? Como garantir a objetividade do potencial de desenvolvimento encontrado, avaliando a escala? Em outras palavras, como podemos verificar se o que encontramos na entrevista é realmente um potencial ponto de crescimento para o produto?
É aqui que ele maximiza o uso de ferramentas e o conhecimento de trabalhar com dados que conectam pesquisas qualitativas e quantitativas. Para entender a escala e encontrar a maneira mais correta de determiná-la - essa é a principal competência de um analista de produto. Aqui está apenas um pequeno exemplo em que a abordagem analítica nos permitiu alterar nosso processo de coleta de preocupações dos clientes e, de outra forma, abordar sua validação pela equipe do produto.
Reconhecer e analisar conversas
A Wrike possui uma divisão de gerentes de contas (gerentes de sucesso do cliente ) cuja principal tarefa é oferecer suporte a clientes não para fins de vendas, mas para melhorar sua experiência no uso do produto. Eles ligam para os clientes por vídeo, discutem suas dores atuais, informam práticas recomendadas, sugerem rodadas de trabalho e relatam o status de desenvolvimento de novos recursos. Todas essas conversas foram gravadas por um longo tempo e praticamente não foram usadas pela organização de alimentos - os piemas preferiam se comunicar pessoalmente com os gerentes de contas para ter uma idéia geral das dores dos clientes. Isso pode adicionar um elemento de "telefone quebrado" e nem sempre revela o contexto em que o usuário se deparou com esse problema.
Um dos projetos de iniciativa da análise de produtos foi o desenvolvimento do pipeline, que transformou a conversa em um formato de texto compreensível. Usando a API do Google Speech, além de vários modelos adicionais para organizar a pontuação, foi possível ter uma idéia rápida da extensão de alguns problemas e requisitos de funcionalidade com base nas muitas conversas dos gerentes com os clientes, em vez de em uma única entrevista . Graças a essa fonte simples, foi possível realizar uma pesquisa em larga escala por palavras-chave relacionadas a algumas funcionalidades ou problemas, avaliar a natureza dos usuários que exigiam uma solução específica e também entender o contexto em que ela costumava aparecer. Agora também estamos testando um modelo de análise sentimental que nos ajuda a obter automaticamente o nível médio de satisfação com partes individuais de um produto e notifica a equipe do produto sobre isso.
Um analista é uma pessoa que pode formular um problema no nível adequado de abstração, medi-lo e verificar a significância, oferecer recomendações de ação.
Independentemente da etapa do estudo, existem diferentes níveis de hipóteses (discutiremos em detalhes abaixo) que ajudam a avaliar a interação do usuário com o produto e a construir planos de desenvolvimento adicionais. Aqui, geralmente surge a tarefa de avaliar corretamente o nível necessário de hipótese e selecionar uma ferramenta para coletar informações ou sua validação. De fato, o processo é o seguinte:
- Formulação de hipóteses - por exemplo: "é importante que usuários-administradores de uma determinada coorte possam cobrar com base em um relatório semanal".
- A coleta de estatísticas de uso - uma tarefa clássica de análise - é entender se os números são capazes de responder às hipóteses formuladas acima.
- Coleta de feedback - conduzindo pesquisas por meio de marketing, listas de discussão ou ferramentas internas de feedback
- Análise e validação de resultados - verificação de resultados em uma estatística. relevância
Vamos nos debruçar sobre o terceiro parágrafo, já que muitas vezes é ele quem distingue um analista de produto de apenas uma pessoa que é bem versada em estatística.
Coleta de Feedback
Muitas empresas acreditam que, depois de configurar um sistema de registro, prender serviços de análise como o Google Analytics em seus produtos, a preparação de uma plataforma para análise termina aqui. No entanto, infelizmente, com essa abordagem, o elemento mais importante é esquecido - a necessidade de feedback do usuário, a capacidade de perguntar a ele no momento certo sobre suas tarefas e as dificuldades que ele enfrenta.
Portanto, é fundamental que a equipe tenha ferramentas suficientes para interrogar discretamente os usuários e coletar feedback deles, não apenas por meio de algum tipo de pesquisa de marketing, mas também por meio de um mecanismo interno.
Utilizamos a ferramenta QFF interna (formulário de feedback qualitativo) para formular e validar hipóteses e considerar possíveis cenários de experiência do usuário como uma pirâmide de três estágios (produto → recurso → interação):
- Nível do produto
- Nível de funcionalidade
- Nível de interação específico
Vamos discutir cada um deles com mais detalhes e mostrar quais métricas usamos para entender seus problemas.
1. Nível do produto
Aqui, é importante entender as partes mais amplas e multifuncionais do funil de experiência do usuário. Esse é o desejo de encontrar respostas para as perguntas mais globais, seja a satisfação com o produto como um todo ou com o conjunto de funcionalidades para resolver uma única tarefa (por exemplo, coordenar férias pode exigir a interação da funcionalidade de calendário, status das tarefas, algoritmos de agendamento etc.).
Não há métricas claramente regulamentadas que precisem ser aplicadas em tais situações; sempre há nuances. No entanto, como regra, nesse nível de abstração, estamos falando de métricas NPS (net promoter score) ou SUS (system usabilidade scale). As métricas não são incontestáveis, mas, em regra, são os padrões da indústria e ajudam a orientar-se para o estabelecimento de metas na escala de vários trimestres.
2. Nível de funcionalidade
Nesse nível, fazemos perguntas mais específicas que se relacionam diretamente a um funcional específico. A partir do exemplo acima - já podemos analisar separadamente, não o problema de “coordenar feriados” em geral, mas pegar apenas uma parte específica do produto, por exemplo, calendários. Quão confortáveis eles são para a percepção? Por que as pessoas os usam?
Dependendo do estágio de nossa pesquisa, não apenas as perguntas podem diferir, mas também os indicadores que coletamos de nossos usuários. O mais simples é o nível de satisfação, que pode ser lido de uma tarefa para outra usando diferentes escalas (três emoticons ou escala Likert), CES (pontuação do esforço do cliente) - quão difícil ou fácil é para o usuário implementar algumas tarefas.
3. Nível de interação
A tarefa desse nível é avaliar a iteração específica que o usuário executou com o produto (por exemplo, clicou em um botão). Ao mesmo tempo, é importante que o resultado dessa interação seja uma determinada ação ou solução que não possamos medir ou controlar. Como regra, aqui estamos falando de níveis de satisfação e adoção de determinadas decisões subseqüentes: por exemplo, o gerente, olhando o calendário, entendeu quando o funcionário está de férias? O formato de exportação de dados é adequado para o usuário? Como todas as ações posteriores ocorrem apenas na cabeça do usuário ou fora do nosso produto, não temos outro método para avaliar a iteração.
De fato, o nível de avaliação da interação é uma tentativa de avaliar a métrica CSAT (satisfação do cliente), que é frequentemente usada em suporte e outros serviços em que você precisa avaliar um evento específico. Ao mesmo tempo, métricas como a CES também podem ser usadas aqui, mas em uma formulação mais "local".
Análise e validação de resultados
Depois de fixarmos hipóteses, formularmos perguntas e conduzirmos nossas pesquisas de validação no nível adequado de experiência do usuário com o produto, surge uma tarefa que novamente exige talentos especiais do analista - desta vez no campo de estatística e teste de hipóteses.
De fato, após cada pesquisa, o analista deve garantir com que grau de confiança você pode confiar nos resultados, incluindo os resultados do seu trabalho. O fator de trabalho em uma grande empresa influencia a resposta? E a posição do empregado?
Todas essas hipóteses são cuidadosamente verificadas usando as ferramentas necessárias: como conduzir corretamente um teste A / B, são exatamente as abordagens que se aplicam a cada situação específica que dependem diretamente do analista. Por via de regra, a análise de regressão pode frequentemente ser usada, no entanto, não é a única solução universal, pois Possui campos de aplicação e interpretação próprios. Métodos específicos estão sempre a critério do analista.
Em vez de uma conclusão
Acima, revelamos apenas dois casos principais no trabalho do analista e, ao mesmo tempo, não falamos intencionalmente sobre todas as etapas de seu trabalho - uma descrição detalhada de todos os tipos de pesquisa, a formulação de hipóteses e a coleta correta de dados vale a pena artigos separados. No entanto, acreditamos que mesmo uma formulação de nível superior semelhante das expectativas da análise e da fixação dos principais métodos de seu trabalho fortalecerá significativamente qualquer equipe de produtos e ajudará a criar melhores produtos.
A capacidade de encontrar pontos de crescimento nos dados (não importa quão desestruturado possa ser), formulá-los corretamente em hipóteses, dimensionar e validar para todos os usuários atuais e futuros - essas são as qualidades que distinguem nossos analistas de produtos. Portanto, sabemos com certeza que esses requisitos fornecem os resultados mais tangíveis e não permitem que ele entre na rotina operacional e, portanto, recomendamos com ousadia esses princípios a outras equipes.
E se você quiser falar sobre análise quantitativa, big data e itens de infraestrutura que suportam todas as análises no Wrike, visite-nos em uma reunião no escritório de São Petersburgo . Bem, ou apenas vá visitar.