Nessa quarta parte do livro Escaping the build trap: how effective product management creates real value da Melissa Perri vamos falar sobre os processos mais utilizados por Product Managers para resolver problemas e construir soluções na gestão de produtos.
Se você não leu as outras partes, confira aqui os resumos da parte 1 , parte 2 e parte 3.
Boa leitura!
__________________________
PARTE 4 – PRODUCT MANAGEMENT PROCESS
As melhores soluções são aquelas que estão vinculadas a problemas reais que usuários querem que sejam resolvidos. Product Managers usam um processo para identificar esses problemas para que o time possa resolver e assim alavancar o negócio.
O Product Kata
Como visto na Parte anterior, o Product Kata é um processo pelo qual nós descobrimos a solução certa a ser construída. O kata de produto, se feito constantemente, exatamente como um kata de artes marciais, entranha o processo de fazer produto com uma abordagem resolvedora de problemas na sua cabeça e, depois de um tempo, esse padrão fica natural.
A primeira tarefa é definir qual a iniciativa de produto, para isso você precisará entender qual é ou quais são os objetivos estratégicos da empresa, avaliar qual o estado atual da estratégia, no que o produto pode ajudar e quais problemas você pode resolver para alavancar esses objetivos.
Podem existir vários caminhos que podem ajudar a alcançar a iniciativa de produto. Nesse aspecto, um ou mais podem nos levar a um resultado positivo, mas para saber se estamos avançando precisamos destrinchar a métrica de sucesso em algo que seja possível medir a curto prazo, chamamos isso de objetivo do time, que é como medimos o sucesso de um caminho/hipótese.
Desde o lançamento do Lean Startup, experimentação se tornou um tópico popular em várias empresas de software, mas antes de começar nesse processo é importante dar um passo atrás e entender onde você está e o que é preciso nesse estágio. É aqui que o Product Kata ajuda.
Depois de definido um objetivo, começamos a nos fazer as seguintes perguntas:
- Qual é o objetivo?
- Onde estamos em relação a esse objetivo?
- Quais maior problema ou obstáculo no caminho para que alcancemos esse objetivo?
- Como podemos resolver esse problema?
- O que eu espero que aconteça (hipótese)?
- O que realmente aconteceu e o que nós aprendemos?
Nós respondemos as perguntas de 1 a 4 para planejar nosso próximo movimento como um time, então nós trabalhamos e refletimos sobre esse trabalho com as perguntas 5 e 6 para entender se voltamos ao início do processo. Essas perguntas nos fazem explorar o problema, a solução e as hipóteses.
Para cada uma dessas etapas existem etapas a serem passadas e ferramentas a serem usadas, sendo importante entender o que é necessário para que não sejam aplicadas as coisas erradas na hora errada, por exemplo, experimentar desnecessariamente quando o problema ainda não está bem determinado ou quando já existe uma boa ideia para a solução de um problema que não é core para o seu negócio.
Quando se trata do core do seu produto o melhor é, depois de entender o problema com clareza, testar várias soluções antes de se comprometer com uma. Nessa abordagem, design e desenvolvimento trabalham com o intuito de atingir um objetivo ao resolver um problema e você irá testar várias coisas que não serão entregues, que irão falhar.
Entendendo a direção e estabelecendo uma métrica de sucesso
As métricas de produto te dizem quão saudável seu produto é e, consequentemente, seu negócio. Isso é crucial para qualquer Product Manager, pois é como você determina quando e onde agir. Entretanto, geralmente vemos times medindo as coisas erradas.
De um lado existem os times que se prendem em métricas de vaidade como número de usuários. Do outro, times que focam em medir métricas orientadas a entrega como número de features ou quantidade de story points entregues. Ambos os tipos são interessantes para a empresa, mas nenhuma te fala sobre a saúde do produto e do negócio.
Para setar métricas que te ajudem a entender sobre o produto e orientar seu comportamento, prioridades e negócio, existem alguns frameworks como métricas piratas e HEART.
As métricas piratas são como um funil, os usuários te encontram na fase de aquisição, têm uma primeira boa experiência na fase de ativação, continuam retornando ao produto na fase de retenção, contam para outras pessoas que eles amam seu produto na fase de recomendação e, finalmente, pagam pelo seu produto na fase de receita.
Essa ordem de etapas funciona muito bem para produtos no modelo freemium, mas você pode alterar a ordem para se encaixar, por exemplo, em um modelo de vendas B2B com uma equipe de vendas. Com o funil certo você consegue facilmente medir conversão de cada fase e orientar seus esforços para onde está o problema.
Apesar de muito popular, esse framework não fala sobre a satisfação do cliente, o que impulsionou a criação do HEART, que mede felicidade, engajamento, adoção, retenção e sucesso da tarefa. Aqui a fase de adoção é muito similar a fase de ativação que existe nas métricas piratas, e a fase de retenção também é a mesma. No entanto temos algumas novas métricas que medem a interação do cliente com o produto, a felicidade mede o quão satisfeito seu cliente está, o engajamento mede a frequência de uso e o sucesso da tarefa mede o quão fácil é para que um usuário concretize o que eles quer com o produto.
Nesse sentido, independente do framework que você está usando, é preciso entender em qual fase você estará atuando para conseguir medir quais métricas nessa fase vão te dizer sobre sua evolução.
Explorando o Problema
Entender o problema envolve falar com pessoas, mas apesar de todos sabermos disso, na maioria das vezes não falamos o suficiente. A verdade é que, falar com pessoas exige um grande esforço e é tentador ir direto para testes A/B e análise de dados, entretanto, apesar de também serem muito importantes, os dados nunca vão conseguir te contar a história inteira.
Para ir entender a fundo o problema é preciso falar com pessoas e você pode usar ferramentas como pesquisa com usuários (user research), observação, pesquisas e feedback de clientes para explorar o ponto de vista do usuário.
As pesquisas com usuário com base em problemas são generativas, elas tem o objetivo de encontrar o problema a ser solucionado, ela envolve ir até a fonte do problema e entender o contexto ao redor dela. Quais os pontos de dor existentes? Qual a causa raiz? Quando você entende o real problema e o contexto ao redor dele, você consegue criar uma solução para resolvê-lo. Sem isso, você está apenas chutando. É fácil cair na armadilha de resolver problemas sem antes saber sua causa raiz, afinal, nosso cérebro adora pensar em termos de solução, mas isso pode ser extremamente prejudicial ao negócio, pois a solução possivelmente não resolverá o problema certo da maneira certa, a não ser que você tenha muita sorte.
Quando se faz pesquisa com usuários também é preciso se atentar que muitas vezes as pessoas estão ansiosas para te dizer o que você poderia fazer, entretanto você precisa entender a causa do problema. Perguntas como, “Porquê você precisa disso?”, “Porquê esta é a melhor coisa?” e “O que você gostaria de concretizar com isso?”, vão te ajudar a explorar melhor.
Depois de levantar os problemas falando com alguns usuários é interessante que você consiga validar se esse problema acontece com outras pessoas. Uma boa opção é usar de pesquisas quantitativas.
Explorando a Solução
Uma vez identificado o problema é preciso entender qual a solução certa. Nesse momento você pode utilizar de técnicas como MVP concierge, Wizard of Oz e teste de conceito, para entender quais aspectos precisam existir na solução através da prática. O importante aqui é entender o que resolveria o problema e se essa solução faz sentido para a empresa.
As empresas confundem os conceitos de criar para aprender e criar para lucrar. Experimentação é sobre aprender e um experimento não deve ser construído para durar, portanto, um MVP não deve ser confundido com a primeira versão do seu produto. O MVP é o que se cria com o mínimo de esforço possível para aprender o que se precisa.
O tipo de experimentação concierge se trata de entregar ao cliente o resultado desejado manualmente, não necessariamente de forma parecida como uma solução final. Seus clientes vão saber que você está fazendo de forma manual e não automática, não envolve desenvolver nada em termos de código, você estará próximo do seu cliente recebendo uma tonelada de feedback e aprendendo na prática o que é preciso para resolver o problema.
Por sua vez, no Wizard of Oz seu experimento parece um produto final para o cliente, entretanto, por trás você estará desempenhando as ações de forma manual. Essa é uma boa técnica para pegar feedback em escala. Como se parece com um produto real as empresas ficam tentadas a manter o experimento por um longo tempo, mas é preciso definir quando começar a pensar na solução final.
Por fim, no teste de conceito você foca em demonstrar o que você pretende para usuários e pegar feedback, utilizando de wireframes, protótipos, landing pages, vídeos, o que fizer mais sentido para o negócio. É importante destacar que esse tipo de experimento é muito mais generativa do que avaliativa.
Mas é preciso testar tudo? A resposta é não. Essas ferramentas são utilizadas para mitigar grandes riscos e incertezas. Quando a solução já está um pouco mais clara, podemos partir para protótipos e validar se os fluxos fazem sentido e resolvem o problema proposto. Mas lembrando que, protótipos não fazem sentido se você precisa validar o problema.
Construindo e Otimizando sua Solução
A etapa de entender qual a melhor solução para o problema em questão pode durar alguns ciclos de iteração no Product Kata, e, depois de definida a direção, é preciso entender qual a melhor forma de entregar essa solução ao cliente.
É importante nessa etapa garantir que todo o time entende o contexto e o trabalho que precisa ser feito. Existem dois documentos que podem te ajudar com isso, o Story Mapping e o North Star Metric.
O documento North Star explica o produto de uma forma que pode ser visualizado por toda a empresa e inclui o problema que está sendo resolvido, a solução proposta, os fatores de sucesso para a solução e os resultados que o produto irá gerar. Esse documento deve ser evoluído ao longo do tempo à medida que você aprende mais sobre o produto e nele não conterá um plano de como o time irá construir a solução.
Por sua vez, o Story Mapping ajuda o time a quebrar o trabalho a ser feito em torno de objetivos e ações desejadas do ponto de vista do usuário. É uma atividade que ajuda o time a visualizar o que precisa ser feito para entregar valor para o usuário o que ajuda vocês a desenvolverem o produto mais rápido e de forma a entregar valor mais rápido.
Para chegar até a versão 1 a ser entregue ao usuário você precisará priorizar o trabalho e um dos métodos priorização que Melissa gosta de usar é o Custo de Atraso, que se trata de um valor numérico que descreve o impacto de tempo nos resultados que você espera atingir, ele combina urgência e valor para que você consiga mensurar impacto e priorizar o que você deveria fazer primeiro. Seu objetivo deve ser reduzir escopo o suficiente para que você possa capturar o máximo de valor no momento certo, discutindo feature a feature o que causará impacto.
Depois de entregar a primeira versão você ainda precisa atingir seus objetivos, que constitui a real definição de feito (Definition of Done). Times que trabalham no modelo agile geralmente tem uma definição de feito relacionada a requerimentos para entrega do produto em produção, que é útil para que o time termine o que precisa ser feito, mas passa uma expectativa errada.
Frequentemente os times entregam uma primeira versão da feature e seguem para a próxima sem medir os resultados para o usuários, por isso ajuda se vocês estabelecerem uma métrica de sucesso a ser medida depois do lançamento. A realidade é que você só terminou de desenvolver ou iterar em uma funcionalidade quando você atingiu seus objetivos com ela.
Escrito por Letícia Rezende, aluna da PM3 e também Product Manager na Zup Innovation.
Ainda sim, tendo uma estratégia clara e todos os processos que falamos durante essa parte, nada irá adiantar se você não tem uma política, estrutura e cultura sólida de produto na empresa.
A parte 5 fala sobre organizações orientadas a produto (Product Led Companies), então fique ligado no texto da semana que vem. 🙂
Que tal conhecer mais sobre a gestão de produtos digitais?
Se quer se tornar um Product Manager mais preparado(a) para enfrentar o mercado, baixe a ementa do curso referência em produto no país e aprenda com 17 instrutores de empresas como OLX, Nubank, Booking.com, iFood, Creditas, Grupo ZAP, entre outras grandes Tech companies brasileiras.
