Gestão de produto é difícil, mas não precisa ser complicado. É fácil quem trabalha em produto se sentir sem direção, pois por definição em uma startup estamos construindo coisas que ninguém sabe se vai funcionar. Este passo a passo vai ajudar você a dar um norte para suas atividades como product manager, product owner ou fundador de startup.

Porém atenção: este post é mais uma bússola do que uma receita de bolo.

Não existe receita pra fazer um produto bem sucedido. Quem disser que tem precisa ensinar (e ficar rico no processo). Product management é uma disciplina com uma parte de arte. Deal with it.

1. Tudo começa no “por quê”

Nenhuma mudança de produto deve ser feita sem definir qual é o objetivo da mudança.

Definir um objetivo claro é imprescindível. Se o time não sabe isso, pare tudo e clarifique qual é o objetivo. Sem isso o time pode fazer muitas alterações no software, porém nunca chegar a lugar algum.

Exemplos de “por quês”:

• Ruim: disponibilizar a funcionalidade X
• OK: Aumentar o NPS do produto
• Bom: Aumentar o NPS de contas do plano Pro com mais de 6 meses de vida
• Melhor: Aumentar de X para Y o NPS de contas do plano Pro com mais de 6 meses de vida

Ter um por que claro vai ajudar o time a priorizar, reduzindo discussões sobre, por exemplo, porque o bug X não deve ser priorizado agora (“porque não vai ajudar com o objetivo definido como prioridade”).

Comunique o por que mais do que você acha necessário

Vejo como muito do papel do PM comunicar/clarificar em todas as oportunidades possíveis esse “por quê”. Não é possível comunicar demais isso. Mesmo que você vire um meme por abrir todas as reuniões com os mesmos 3 slides explicando a lógica do que querem atingir como time. Vale a pena por evitar muita dor de cabeça com discussões desnecessárias.

2. Descoberta das oportunidades para atingir o objetivo

Definido o objetivo, é preciso entender quais são as alavancas para atingi-lo.

Aqui é fácil explorar muitos caminhos e sentir-se sem rumo, com dificuldade de definir uma prioridade. Por isso recomendo usar uma árvore de oportunidades. Se você não conhece o conceito ou quer refrescar, veja este vídeo da Product Starter onde eu explico como funciona. Além disso tenho o curso Árvore de Oportunidades na Prática que ensina de A a Z como usar a framework.

A estrutura básica da árvore de oportunidades é:

objetivo -> oportunidades -> ideias de solução

Exemplo:

Quer um exemplo completo? Neste board do Miro tem um exemplo de uma árvore de oportunidades real.

É importante não confundir as oportunidades com as hipóteses de solução. Se você pular direto de “Objetivo” para “Ideias de solução” vai ser muito difícil discutir e priorizar o que fazer, pois você estará comparando “bananas com maçãs” — ideias de solução que endereçam oportunidades diferentes, como por exemplo “condicional de clique em link específico” e “zoom no editor”. A primeira endereça a oportunidade de que é preciso muitos passos para criar um fluxo, já a segunda endereça a oportunidade de que é ruim trabalhar com fluxos de automação muito grandes. É papel do PM e do time descobrir qual destas duas (ou outras) oportunidades traz maior alavancagem para atingir o objetivo — e só depois discutir que ações podem endereçar a oportunidade.

Métodos para descobrir oportunidades são o feijão com o arroz de um discovery:

• Entrevista com clientes / suporte / CS / vendas…
• Entrevistas de Jobs to be Done
• Análise de tickets, uso de features, NPS…
• Pesquisa quantitativa com clientes / suporte / CS / vendas…
• Brainstorm com o time
• …

Naturalmente enquanto você for descobrindo oportunidades, também vai começar a aparecer também ideias de como endereçá-las. Vá anotando no nível de hipóteses de solução da árvore.

Envolvendo o time na descoberta de oportunidades

O ideal é envolver o time inteiro no discovery de oportunidades, não para “ser legal”, mas porque 1) conhecendo o contexto do problema, eles estarão muito mais aptos a tomarem as decisões corretas como time depois; 2) vai ser necessário muito pouco convencimento do que é prioridade, pois o time já entende os principais problemas do cliente/negócio.

Porém na minha experiência a maioria dos engenheiros não disponibiliza muito do seu tempo para participar de entrevistas com clientes, por mais que muitas vezes eles queiram participar. O hack que eu encontrei para manter o time alinhado no discovery, mesmo não participando ativamente, foi compartilhar no canal do time as descobertas interessantes, frases de clientes e novas hipóteses que apareceram logo após uma entrevista ou análise. Assim o time acompanha o discovery passo a passo quase como se estivesse executando ele.

Exemplos dessas mensagens:

3. Escolhendo a oportunidade para atacar primeiro

Ok, você e o seu time descobriram uma série de oportunidades para atingir o objetivo. E agora? Como escolher qual atacar? E em que ordem? Aqui PMs menos experientes podem se embananar um pouco, buscando uma certeza muito elevada em metodologia e processo (ex: RICE e GUT) para dar um ar de “ciência”. Mas vou contar dois segredos sobre a escolha da “melhor” oportunidade: 1) essa parte tem um pouco de arte; 2) 99% das vezes essa é uma decisão do tipo 2, ou seja, facilmente revertida: se você escolher uma oportunidade que não é boa e fizer uma validação decente, é fácil voltar atrás e escolher outra oportunidade.

Qual é a melhor oportunidade? Qual das oportunidades que você descobriu você sente que é a maior alavanca para atingir o objetivo? E o seu time? Esse sentimento, por que você tem ele? Existe algo que você descobriu que apoia essa decisão? Exemplo: X foi a oportunidade que mais os clientes mencionaram em entrevistas como obstáculo para nosso objetivo Y.

Escolha uma oportunidade que parece a melhor por algum motivo e siga em frente:

Testando a oportunidade

Se você ainda tá no sentimento, essa é uma boa hora pra testar se essa oportunidade é de fato uma oportunidade (ou seja, se ela vai ajudar a subir sua métrica e, quem sabe, quanto vai ajudar). Esse é o principal problema? Ao endereçar essa oportunidade, o quanto ela vai ajudar você a atingir o objetivo?

Exemplo:

uma das oportunidades para melhorar a satisfação de clientes maduros do plano Pro com o editor de automação era endereçar o problema de criar e editar fluxos muito grandes. Como eu sabia que essa era uma oportunidade grande o suficiente? Pelo feedback dos clientes essa era a categoria mais citada com ~33% das menções:

4. Explorando soluções para a oportunidade

Uma vez acertado que a oportunidade faz sentido, é preciso gerar ideias de como endereçar a oportunidade. Provavelmente muita coisa já vai ter vindo do próprio discovery da oportunidade, mas é bem bom fazer mais uma exploração além das ideias óbvias. Essa exploração no mínimo deve ser feita com o time, mas é também útil incluir CS, clientes com o problema e, em alguns casos, vendas.

Dica: se for fazer brainstorm, comece com um brainstorm assíncrono, onde qualquer um pode sugerir ideias para a oportunidade. Existem estudos que mostram que indivíduos são melhores que grupos para gerar ideias.

5. Escolhendo qual solução atacar primeiro

Sejam quais forem os métodos usados para gerar ideias de solução, é preciso avaliá-las e compará-las. Existem muitas formas de fazer isso, mas pra mim a que eu mais uso é plotar as soluções em uma matriz de custo vs impacto no objetivo. Exemplo:

Para gerar essa matriz, uma boa prática é envolver tanto quem está mais próximo da tecnologia (engenharia), quanto quem está mais próximo do problema (PM, UX, CS, etc). Antes de fazer essa dinâmica de priorização eu costumo apresentar as evidências que eu tenho do que descobrimos no discovery. Isso coloca todo mundo na mesma página sobre o que gera impacto na oportunidade e no objetivo.

Com essa matriz fica relativamente simples escolher qual solução explorar primeiro: as que geram mais valor com o menor custo. Obviamente isso também não é uma ciência exata, então tem um pouco de feeling e arte envolvidos. Também existem decisões estratégicas, onde às vezes faz sentido pegar um item mais simples de construir e que gera um pouco menos de valor (ainda que gere bastante) para entregar valor rápido. Vale o bom senso.

6. Hora de construir? Nope. Hora de mitigar riscos

Erro comum clássico: achar que ao passar pelos passos anteriores, basta construir e abrir a champanhe pra comemorar os resultados. Ainda existem muitos riscos nessa priorização e é preciso mitigá-los. Por exemplo: a matriz de esforço vs retorno foi feita baseada em boa, mas limitada, informação. Será que é realmente simples de construir como os engenheiros imaginaram? Será que vai de fato contribuir significativamente com a solução da oportunidade como imaginamos? Será que o cliente vai usar? Será que ele conseguirá usar? Será que a solução pode afetar negativamente outras áreas ou até o business? Ela é legal (em termos de legislação)? É ética?

Todas essas perguntas precisam ser em algum grau respondidas. Minha framework preferida para pensar nos principais riscos e quais mitigar são os 4 riscos do Cagan:

1. Risco de valor: as pessoas vão usar/comprar? Esse é um dos riscos principais, pois nada mais importa se a solução não resolve o problema do usuário. Surpreendentemente é um dos riscos mais negligenciados, visto a quantidade de vezes que é lançado um produto ou funcionalidade que tem baixíssima adoção.
2. Risco de usabilidade: as pessoas conseguirão usar? Testes de usabilidade predominam aqui.
3. Risco de viabilidade: conseguimos construir isso? Temos os recursos e conhecimentos necessários? De nada adianta você fazer um produto fantástico de teletransporte se não é possível construir um teletransporte.
4. Risco de negócio: nossos stakeholders vão apoiar isso? Quando alterações afetem o negócio como um todo ou outras áreas é preciso ganhar o buy-in ou enfrentar uma revolta dentro da própria empresa. Ex: o Adwords, o maior negócio do Google, quase foi vetado pelo time de vendas e o time de engenharia.

Dependendo da solução e das evidências que você coletou, será preciso focar mais em um ou outro desses 4 riscos. Mas o principal é sempre focar em “qual é o maior risco” e ir trabalhando dos maiores para os menores riscos. Atenção para não ir ao extremo de testar tudo. Muitas pessoas acabam tão focadas em testar que fazem testes de coisas que elas já sabem a resposta (o que é inútil).

Alguns exemplos de testes comuns:

Valor:

• Entrevista com cliente
• Fake door test
• Testar reação do cliente com protótipo
• Tickets de suporte
• Pedidos de cliente / CS
• Citações como razão de churn os lost de vendas
• Erros no Rollbar

Usabilidade:

• Teste de entendimento com ferramenta como Usability Hub
• Teste de usabilidade com protótipo navegável
• Teste de usabilidade com protótipo em papel
• Benchmark com concorrentes ou ferramentas com uso similar

Viabilidade:

• PoC (Proof of Concept)
• Tech design doc

Negócio:

• Falar com as pessoas da empresa 😜

Em geral será preciso fazer uma proposta de solução de produto mais tangível (como uns rabiscos do flow em um papel) e um estudo de viabilidade técnica (pra saber se realmente é simples como pensado). Tanto no desenho de solução quanto no estudo de viabilidade técnica é uma boa prática definir um “apetite” de investimento na solução. Por exemplo “essa solução provavelmente não vale a pena se precisarmos investir mais do que 3 semanas nela”. Isso ajuda tanto UX quanto engenharia a não fazer algo mais sofisticado do que vale a pena. Também serve de guia para conversas do tipo “ok, como podemos fazer isso entregar a maior parte do valor, mas investindo só 3 semanas?”.

E se não passar no teste?

Ou você itera (por exemplo, o usuário não entendeu, mas podemos tentar XYZ para que ele entenda melhor) ou você define a hipótese de solução como invalidada e parte pra outra. E, se esse segundo acontecer, pode abrir a champanhe pra comemorar, porque você descobriu cedo o suficiente que não iria funcionar — muito melhor do que depois de fazer as modificações em produção!

Lembre-se de atualizar a árvore de oportunidades

A medida que uma oportunidade ou ideia é validada ou invalidada, atualize a árvore de oportunidades. Uma boa forma é colocar em verde o que foi validado e vermelho o que não foi. Uma boa prática é linkar na árvore o documento mestre que explica porque foi validado ou invalidado.

7. Principais riscos mitigados? Fatiou e passou

Você está seguro de que vai entregar valor, que o usuário consegue usar, que conseguimos construir dentro do nosso apetite e que não há problemas de negócio. Então é hora de avançar. O ideal aqui é “fatiar” a solução em entregas de valor incrementais. Isso é importante por 3 motivos 1) por mais que você tenha feito tudo que é teste, nada é tão real quanto software na mão do usuário. Quanto mais cedo estiver na mão do usuário, mais cedo é possível receber feedback real e iterar. 2) quanto mais cedo estiver integrado de ponta-a-ponta, mais cedo é possível identificar alguma treta que não foi possível identificar antes (e isso acontece). E 3) Se uma parte entrega valor para o usuário, porque você quer represar esse valor para entregar só no fim? Entrega o mais cedo possível e começa a colher benefícios!

8. Deliver

Isso merece um playbook a parte focado em agilidade em delivery — que eu não sou nem de longe a pessoa mais capacidade pra escrever. Meu resumo do playbook é: ship it.

9. Rollout

Algumas vezes é preciso fazer rollout faseado porque há algum risco a ser mitigado ou teste a ser feito. Eu costumo fazer assim:

• Rollout 0: contas do time de desenvolvimento
• Rollout 1: contas internas da empresa
• Rollout 2: 100 clientes (escolhidos por algum critério X, por exemplo, número de fluxos de automação ativos)
• Rollout X: a partir daí vou multiplicando por 10 o número de clientes que recebem o rollout até dar o release to all. Essa multiplicação por 10 é estatisticamente o sweet spot entre aumentar a abrangência e ao mesmo tempo limitar a exposição ao risco.

10. Comunicação / lançamento

Além de conversar com Product Marketing (antes), eu aviso em alguns canais do Slack ao dar o primeiro rollout pra cliente e ao dar o release to all. Exemplo de canais que eu uso são os canais gerais das áreas de suporte, customer success, vendas e marketing.

Exemplo dessa comunicação:

11. Next

Meça os resultados e volte para o passo 1.