Processo de gestão de produto.

Ligando os pontos para levar o nosso produto aonde queremos.

Quando me perguntam o que uma pessoa product manager faz, minha resposta resumida é: trabalha para evoluir o produto na direção certa — de forma a resolver o problema da pessoa usuária, sustentar o negócio da empresa e ser possível de construir.

Só que para chegar nesse objetivo, existem muitos caminhos diferentes que podem ser tomados. Quem me conhece sabe que eu vivo parafraseando um certo moço aí que diz que há método na sua loucura, então eu gosto de organizar um processo pra chegar lá.

“Though this be madness, yet there is method in ‘t.” — Beijo, Shakespeare.

Há tempos que eu estava querendo desenhar “no papel” como eu enxergo diversas práticas e ferramentas de produto se combinando no meu processo de gerir produto, e finalmente o fiz.

É como eu vejo o ciclo completo de gestão de produto, o trabalho da PM do início ao fim (fim até começar de novo, risos), vamos colocar assim.

Compartilho abaixo com vocês.

O que esse post não é: uma tentativa de verdade absoluta de como deve ser a gestão de produto. Cada um está convidado a adaptar à sua realidade. Também logicamente não sou autora (quem me dera) das ferramentas e conceitos que compõem o processo. Sou "autora" apenas de uma das formas de amarrar esses conceitos em uma ordem lógica para gerenciar produto, que divido a seguir.

O que esse post é: um work in progress eterno, na tentativa de construir o melhor processo de gerir produto. Decidi parar nesse ponto onde ele está para dividir com outras pessoas, e espero feedbacks de outras PMs para questionar, complementar e iterar. :)

Vale lembrar que é uma estrutura que funciona bem para evoluirmos produtos já existentes. Quem sabe depois eu faça uma adaptação para situações de construção de um novo produto?

Bem, sem mais delongas, segue abaixo o desenho desse fluxo, que detalharei na sequência.

Processo de Gestão de Produto — Principais etapas

Enxergo 3 grandes camadas do processo, e dentro delas, 5 diferentes etapas. Por sua vez, cada etapa é feita de algumas tasks. Vamos começar pelas 3 camadas maiores, depois para as 5 grandes etapas, e por fim detalharei todas as tasks que compõem o processo na minha visão.

Camada estratégica

Essa é a camada mais abrangente dessa história, pois ela extrapola squads, tribos e área de produto, e reune elementos que dizem respeito à empresa como um todo. Nessa camada vamos olhar para objetivos estratégicos da companhia, por exemplo.

Também são elementos mais perenes, então ficam mais estáticos do que aquilo que se segue a essa camada. Eles não mudam o tempo todo, e não são nosso objeto de trabalho do dia a dia. Estão lá como guias, como pontos de partida, e como garantias de que, se cada time da empresa quiser pegar esse modelo e aplicar no seu contexto, está tudo bem, pois todo mundo vai remar na mesma direção.

Na lógica do Golden Circle, seria a etapa do "why", a razão para trabalharmos na evolução do nosso produto.

Camada tática

É aqui que começamos a botar a mão na massa de forma sistemática no dia a dia, até o ponto onde estamos seguras como PMs do que deve ser feito (e primeiro) para obtermos sucesso com o produto.

Aqui ainda não vamos trabalhar nos detalhes de features específicas, mas também saímos do alto nível de estratégia da empresa. Ou seja, aqui é tudo sobre o produto (ou a parte do produto com a qual você trabalha).

No Golden Circle, estamos falando do "how": o processo que nos leva aonde queremos chegar.

Camada operacional

É onde eu brinco que a mágica acontece. Tudo o que fizemos até aqui foi para garantir que esse momento não seja desperdiçado. Se até aqui estávamos entendendo, estudando, planejando, validando e por aí vai, agora vamos fazer! Ou, para usar um termo que cabe bem aqui, desenvolver.

É aqui que finalmente a gente fala de features, pois estamos seguros e confiantes para isso, respaldados pelo processo até aqui. Agora pode se apaixonar pela solução, sim! (Para quem não pegou a referência clichê, no universo dos produtos repete-se o mantra de se apaixonar pelo problema e não pela solução). Bom, já trabalhamos bastante os problemas nas etapas anteriores, e agora é a hora de entregar.

Esse é o "what" do Golden Circle, o resultado do processo.

Legal. Agora que passamos pelas camadas que estruturam essa lógica, passemos às etapas dentro delas.

1. Inputs globais

Esta é uma etapa mais de alinhamento do que qualquer outra coisa. Lembra que comentei na primeira frase do post que devemos olhar para como o produto colabora na construção do business da empresa? Por isso que começamos por aqui.

Por mais que eu enxergue a visão de produto nesse âmbito, e a visão de produto quem constrói é o PM, essa é uma etapa menos de mão da massa da pessoa de produto, e mais de consumo e conhecimento profundo dos alicerces da empresa, estrela do norte, objetivos, missão, direcionadores, e por aí vai.

2. Inputs locais

Depois de garantirmos alinhamento com os objetivos da empresa, começamos a diversão! A etapa de inputs locais é onde vamos entender, dados os drivers da companhia, onde existem oportunidades para chegarmos lá. Gosto de ser bem abrangente aqui, enxergando essa como a etapa onde vou entender a fundo o mercado onde eu atuo, os meus usuários/clientes e suas dores, os meus concorrentes, etc. Por mais que eu esteja direcionada pela camada acima, eu vou de coração aberto. Na linguagem do double diamond, é hora de divergir.

Notem que coloquei uma seta que sai dos inputs locais e "volta" para os inputs globais. Enxergo dessa maneira porque, por mais que não faça sentido questionarmos a estratégia da empresa o tempo todo, acho saudável existir essa margem para que eventualmente nosso trabalho colabore com a camada acima. Isso porque, nessa etapa de inputs locais, cavocamos a fundo nas dores dos nossos clientes e nas tendências do mercado, então se tem algo que a gente está vendo aqui que não estava nos drivers — mas que pode colaborar com eles — que a gente tire o melhor proveito desse conhecimento!

No início dos trabalhos desta etapa, olharemos só para problemas. Só no final desses estudos é que vamos traçar hipóteses para solucioná-los, e passá-las para a etapa seguinte, de organizá-las.

3. Organização

Essa é a mais simples das etapas, porém muito importante. Como já escrevi aqui, chove input na vida da PM, e para garantirmos um bom processo de priorização, tudo começa em organizarmos bem nossas hipóteses.

4. Validação

Se na etapa 2 nossa preocupação principal era de mapear problemas, aqui sim vamos falar de solução. Mas não no sentido de construir a solução (ainda). Bem sabemos que precisamos validar nossas hipóteses antes, e é aqui que isso acontece.

Quanto mais hipóteses colocamos à prova nessa etapa, mais material temos para seguir na próxima priorização, aquela onde definimos o que entra em roadmap.

Essa, juntamente com a etapa 2, é onde a pessoa PM trabalha mais em contato com a sua dupla designer. O que não significa que ela não esteja presente em todo esse processo; pelo menos eu não vivo sem! ❤

5. Execução

Agora, com muito mais confiança de que nossas propostas em roadmap são as melhores para a evolução do produto, é chegada a hora de construir e entregar. A pessoa PM dá suporte ao delivery tanto junto ao time de engenharia — direcionando as regras de negócio e detalhes da solução — , quanto aos times responsáveis por treinamento e go-to-market da funcionalidade — trazendo a essência do que foi feito, e da razão por traz do que foi feito.

Tudo pronto? Fechamos acompanhando de perto as métricas do que foi entregue, conferindo os efeitos da feature em produção.

Processo de Gestão de Produto — Tasks

Agora que passamos pelas camadas principais, entrarei mais no detalhe das tarefas que enxergo dentro de cada uma delas.

1. Inputs globais

Jobs to Be Done

Vamos começar pelo "JTBD". Por mais que essa metodologia tenha uma série de aplicações, a que eu vejo como mais importante está no momento de consolidar um product-market-fit. Entender o mercado a entrar e com que produto entrar nele.

Para produtos estabelecidos no mercado e maduros em PMF, a necessidade dos clientes atendida pelo nosso produto já está bem clara, mas no fim do dia, continuam sendo elas que antecedem tudo o que a empresa planejará.

Missão, objetivos e direcionadores da companhia

Derivando, então, dessa premissa básica, vem a estratégia da companhia. Aqui moram vários elementos, que variam de empresa para empresa, mas podem ser: planejamento estratégico, OKRs, estrela do norte, direcionadores, missão, visão, metas, objetivos, etc.

Meu principal ponto aqui é: isso deve ser amplo. Se os direcionadores forem, e desculpa e brincadeira com as palavras, muitos direcionados, perderemos a riqueza das etapas seguintes. "O que deve ser feito" e "como deve ser feito" estaria posto, sem necessariamente ser embasado no mais completo alicerce.

Da mesma forma, por favor, não deve ser uma lista de features a serem feitas no ano seguinte. "Reduzir churn dos clientes de planos XYZ" soa como um direcionador pra mim. "Criar um algoritmo que faz tal coisa" não soa como um direcionador pra mim. Se você está em um contexto onde os times de produto reclamam das decisões serem muito top down, é possível que seja aqui que more um dos problemas.

Por fim, desde já o processo deve ser centrado no usuário. Essa camada é "a da empresa" porque os direcionadores guiam a empresa toda (para além da área de produto), e não porque ela fala somente sobre os objetivos de negócio. Claro que aqui teremos clareza sobre qual dor do negócio vamos atacar, mas vamos sempre pensar em quais dores do usuário, quando atendidas, resolvem essa dor do negócio.

A frequência com que uma empresa revisa seus direcionadores é outra coisa que depende de cada uma, mas é bastante comum ser um processo anual. (Aquela brincadeira legal que costuma acontecer por outubro).

Visão de produto

A pessoa PM, por sua vez, vai estabelecer a visão de produto, o que pode significa uma visão de todo um produto, ou de um domínio do mesmo. De forma sucinta, é como enxergamos nosso produto no futuro, e como se parece o caminho para chegarmos até lá. Por ser algo de médio a longo prazo, pode ser revisado com alguma frequência, mas não muda radicalmente o tempo todo.

2. Inputs locais

Bom, se temos objetivo X, precisamos descobrir quais problemas existem no nosso caminho, nos impedindo de chegar lá. A ideia aqui é levantar todos esses problemas e, junto a eles, a maior quantidade possível de hipóteses promissoras para resolvê-los.

Essa etapa não será tão revisitada quanto as 4 e 5 (validação e execução), porque as dores das pessoas e o cenário do mercado não mudam toda semana. Mas… eles mudam! Então essa etapa está aqui para nos lembrar de sempre estarmos atualizados quanto às oportunidades que temos no nosso produto.

Na minha visão, as hipóteses que queremos derivam principalmente de dois processos:

Discovery macro

É o que eu também chamei aqui de "discovery do discovery". A intenção desse trabalho é ir atrás de numerosos inputs que nos indicam quais problemas precisamos resolver, e dão material para construirmos hipóteses de como pode ser essa resolução. Note que aqui ficamos nas hipóteses, por ora sem validarmos nada sobre elas. Na linha do brainstorming, quanto mais, melhor. Depois teremos tempo para validar o potencial delas.

Vejo essas hipóteses vindo, resumidamente, de duas direções.

• Dados qualitativos

Aqui é sobre conversar com as pessoas, e ouvir delas os problemas a resolver.

Pode ser na forma de entrevistas clássicas com usuários, por exemplo, porém com um roteiro bem aberto. Num estilo "fale sobre a sua experiência com o produto", deixando a pessoa abrir o coração, e seguindo a conversa de acordo com o que a pessoa trouxer. Também podemos envolver pessoas da empresa que têm contato frequente com o cliente para trazer a sua voz.

Mas não precisamos nos ater a essas entrevistas padrão. Podemos buscar a voz do cliente em tickets abertos no suporte, respostas de pesquisas como NPS ou, polêmica, até alguns áudios dos clientes mais próximos via WhatsApp.

Também faz sentido fazer alguns benchmarks para entender como o nosso produto se contextualiza no mercado, e buscando daí oportunidades de evolução.

Por mais que muitas dessas fontes trará soluções, a gente vai organizar esses insights na forma de hipóteses.

• Hipóteses geradas por dados

Aqui é sobre conversar com os dados, e ouvir deles os problemas a resolver.

Vamos olhar para dados estratégicos de uso do produto e fazer cruzamentos que nos levem a insights relevantes. Exemplo hipotético: clientes que usam a feature X têm LTV N vezes maior que os que não usam, porém somente Y% dos clientes usa feature X.

A partir disso, podemos convidar pessoas com contexto para nos ajudarem em uma sessão de ideação, onde a pergunta que guia pode ser (seguindo o exemplo): como podemos fazer mais clientes usarem a feature X?

O resultado dessa sessão é uma lista de hipóteses de como evoluir o produto.

Hipóteses validadas por dados

Na mesma linha das hipóteses geradas por dados, vejo uma outra forma de extrair esses insights dos dados. Em vez de partirmos de uma exploração mais aberta dos nossos dados principais, partimos dos conceitos de sucesso para nossos clientes e para a nossa empresa. Exemplo: para o meu usuário, uma das formas de sucesso é taxas altas de abertura de emails.

A partir disso, contando com nosso conhecimento acumulado sobre o produto como PMs, temos várias hipóteses. Poderia ser: clientes que usam feature X têm taxas de abertura de emails mais altas que os usuários que não a usam. E a nossa grande sorte aqui é que o banco de dados pode rapidamente provar que estamos certos ou que estamos errados.

Pegamos, então, as hipóteses que foram validadas por dados, e seguimos a mesma lógica da ideação que comentei antes. Como podemos fazer mais usuários aderirem à feature X? Isso é o que eu chamo de hipótese secundária.

Juntamos estas às hipóteses advindas do discovery macro, e temos em mãos problemas e hipóteses pra não colocarmos defeito.

3. Organização

Para não virar o caos e não sabermos por onde continuar, proponho uma organização nesse ponto.

Eu gosto de dividir todas as hipóteses provenientes da etapa 2 em dois grandes lugares:

• Árvore de oportunidades: é onde eu coloco todos os itens que estão alinhados com os inputs globais, na estrutura clássica proposta pela Teresa Torres.
• Backlog: eu chamo de backlog algo um pouco diferente do que é o backlog no contexto do Scrum, por exemplo. Eu encaro o backlog como uma lista para registrar todos os itens provenientes de inputs locais, mas que no momento não se alinham com os inputs globais. Muitas pessoas vão sugerir muitas coisas para a pessoa PM, e em determinadas condições de temperatura e pressão podem até fazer sentido. Mas, se no momento presente não faz, deixa lá guardadinho no backlog, para revisitar e avaliar se posteriormente faz sentido entrar pra árvore de oportunidades.

Maravilha! Temos, em uma estrutura organizada, dezenas de oportunidades de melhorias no produto, que podem nos levar aos nossos objetivos. Qual eu escolho primeiro para validar? Aqui entra a primeira "rodada" de priorização: escolher qual problema e qual hipótese você vai por à prova.

Uma das minhas formas preferidas de priorizar é usando a boa e velha matriz esforço vs. impacto. Mas existem diversas outras formas, como o Kano Model, por exemplo, que eu testei e descrevi aqui. Por fim, sempre tem esta lista de técnicas de priorização, que pode trazer uma luz.

Escolhida a felizarda, bora validar!

4. Validação

Lembra que eu falei, no discovery macro, que não iriamos validar nada por ora? É porque agora a gente vai fazer isso. Como sabemos, investir o nosso time de desenvolvimento em algo que a gente não tem certeza se é o que resolve o problema das pessoas, não sabemos ao certo se as pessoas vão saber usar (e por aí vai) é um grande desperdício. Além disso, ainda há o timing de mercado: sermos cirúrgicos nas nossas escolhas aqui pode significar uma vantagem junto aos outros players, ao chegarmos antes com o que é mais prioritário.

Para quem curte os 4 riscos do Marty Cagan, é aqui que vamos mitigá-los.

Novamente, vejo duas grandes formas de fazer isso:

• Discovery micro: é o que eu vejo a maioria das pessoas chamando de product discovery. Cagan já dizia:

Product discovery is mostly about quickly trying out an ideia.

Vejo o discovery micro seguindo a estrutura clássica: (1) falar com pessoas para entender se realmente o que estamos pensando tem potencial de resolver o problema que escolhemos trabalhar; (2) prototipar um caminho de solução e (3) colocar na mão da pessoa usuária para testar.

Só que às vezes esse pode ser um processo um pouco demorado, e queremos fazer essas validações o mais rápido possível. Por isso, em vários casos, rodar um experimento é suficiente, mais rápido e mais barato.

• Experimentos

No processo de experimentação, a gente simplesmente coloca no produto algo super simples, que possa nos ajudar a validar nossa hipótese. Pode ser, sim, código, desde que seja um que estejamos dispostos a jogar fora. Se conseguirmos ir por um caminho no code, melhor ainda. Ou, quem sabe, uma fake door? Aqui vejo bastante espaço para queimarmos neurônio e termos criatividade.

Só não esqueça, o lema aqui é: o experimento não pode sair mais caro que desenvolver a funcionalidade.

E o que queremos ao final de tudo isso?

Muitas hipóteses, sim, vão ser jogadas fora. E que bom! Imagina se descobríssemos isso em produção…

Mas muitas vão ser validadas, e é isso que queremos ao final: uma lista de diversas oportunidades mapeadas e já validadas, bonitinhas, só esperando a segunda rodada de priorização, aquela que vai indicar o que vai para roadmap.

5. Execução

Assim, chegamos à última etapa da brincadeira, onde vemos tudo ganhando vida.

• Roadmap: famosinho no mundo do produto, ele é um documento primordialmente de comunicação, e deve ser vivo. Se esse processo todo segue acontecendo constantemente, é natural que tenhamos descobertas no caminho que nos façam repensar o que vai ser construído e quando. Com o que aprendemos até aqui, teremos insumos suficientes para organizar nossas melhores apostas em uma linha do tempo.
• Delivery: nessa etapa, ficamos disponíveis para tirar dúvidas do time de engenharia quanto às regras de negócio, trocamos ideias, filosofamos, mas não falamos como a coisa deve ser feita. Ao longo de todo o processo, idealmente, já envolvemos as pessoas desenvolvedoras, então nesse ponto elas já sabem qual o valor queremos entregar, e qual o caminho pra isso. Está na mão do time propor a forma de construir.

Nesta etapa de execução, entre a coisa estar no roadmap e vir à vida, a pessoa PM também dá suporte ao go-to-market da feature, melhoria ou o que quer que esteja sendo entregue. Eu sugiro um listinha de perguntas que a pessoa PM pode se fazer:

• Tenho instrumentadas todas as métricas de que preciso para medir se isso vai entregar o que promete? Se não, bora colocar isso no escopo da entrega.
• O time de product marketing (no caso da empresa ter um) está alinhado com a entrega? Precisamos dar apoio à alguma campanha ou comunicação para o cliente?
• Será um rollout faseado? Se sim, como eu organizo as fases? Após decidir, partiu selecionar as contas que entrarão em cada fase para deixar a coisa no jeito.
• Existem times internos que precisam ser treinados sobre o que eu estou lançando? Vendas? Operações? Atendimento? Como eu posso ajudar nisso?
• Existe uma Central de Ajuda da empresa ou algum material externo que ficará desatualizado quando eu lançar o que eu vou lançar? Se sim, organizar a atualização do que for necessário.

A funcionalidade foi pra rua!?

Comemore!

E, depois: marque entrevistas com os primeiros beta testers. :)

Além disso, inclua no seu dashboard de acompanhamento de métricas os números necessários para acompanhar a saúde do que foi entregue. Isso, aliás, poderá servir de insumos da etapa "hipóteses geradas por dados".

Concluindo

Após passar pelo que eu, até então, vejo como um processo ideal de gerenciar produto, deixo alguns tópicos de fechamento.

Primeiro: por mais que o desenho mostre um fluxo seguindo uma certa sequência, a gente nunca está em só uma delas de cada vez. Costumo dizer que um dos desafios de ser PM é estar sempre no passado, presente e futuro ao mesmo tempo. Você está dando apoio ao delivery do presente, acompanhando as métricas e percepções dos usuários daquilo que foi entregue no passado, e fazendo os discoveries do que virá no futuro.

Segundo: você verá muitas pessoas PMs trocando um pouco a ordem desses passos, principalmente levando hipóteses do passo 2 direto para o roadmap, e depois validando elas. Isso é meio estranho porque, se você já priorizou e apresentou esse roadmap para pessoas de interesse, existe uma grande tendência de ir enviesado para essas validações, querendo confirmar que você estava certo de colocar tal coisa no roadmap.

O que eu acho que pode acontecer e não é estranho é algo não necessariamente passar por uma etapa de validação. Alguns inputs do ponto 2 são tão concretos, que em certas situações podemos, sim, passá-los direto para o roadmap, sem validar antes de construir. O experimento perde o sentido se estiver sendo feito para provar uma convicção. Eu realmente acredito que tem muita arte na ciência de ser PM, e ela mora muito nesses momentos, de usar seu conhecimento acumulado sobre o seu produto para ter a sensibilidade de entender o que precisa ser validado e o que não precisa.

Terceiro: olhando para esse desenho, pode parecer que a gente vai sempre da etapa 1 à 5, e depois volta para a 1. Obviamente, isso não faz muito sentido. Primeiro porque os direcionadores macro da empresa não vão mudar com tanta frequência. A maioria das empresas que eu acompanho trabalha com um cenário de 12 meses para eles. Da mesma forma, os problemas que os usuários enfrentam com o seu produto não mudam tanto o tempo todo.

O que vamos fazer de forma mais frequente é da primeira priorização em diante: ir pescando hipóteses seguidas de hipóteses da nossa árvore, para podermos ter várias delas validadas para priorizar em um roadmap.

Sem mais, gostaria muito de ouvir de outras pessoas PMs se seus processos são similares, e onde há espaço para evoluir essa lógica apresentada.

Happy PM process! :)