Por Guilherme Rodrigues.
Quem decidiu entrar na área de produto com certeza já viveu diferentes níveis de maturidade dessa cultura, se você está começando numa estrutura muito embrionária de produto, tenho certeza que temos dores parecidas.
Acredito que todo mundo já passou por algum momento em que a produtividade do time é medida por entrega de funcionalidades, quanto mais melhor. Vivemos diariamente produzindo coisas, sem entender qual problema estamos resolvendo e qual resultado esperamos atingir.
Nesse nível de maturidade o time não está orientado para atingir algum resultado, mas sim em comemorar um deploy que provavelmente terá pouco efeito para usuários e negócio.
Isso frustra os stakeholders que não atingem objetivos esperados, frustra os usuários que recebem uma série de funcionalidades que pouco agregam e frustra o time que parece andar em círculos.
O curso da PM3 – o maior curso de produto do Brasil me deu a oportunidade de consolidar conhecimentos teóricos e eu pude transformar o meu dia a dia em um grande laboratório para experimentar ferramentas e práticas para evoluir a nossa cultura de produto (Assista à PM3 Lives sobre Cultura de Experimentos para saber mais).
Na empresa onde trabalho, temos um produto onde havia pouquíssimo alinhamento do time e stakeholders sobre o direcionamento que aquele produto deveria tomar e porque estávamos desenvolvendo várias linhas de código.
Eu queria trazer pro time e stakeholders um alinhamento dos nossos objetivos e como podemos atingi-los, não esquecendo de resolver os problemas dos nossos clientes.
Criar um roadmap orientado a resultados do produto foi um dos caminhos e um primeiro experimento deste “laboratório”.
#1 Desconstruindo a palavra roadmap
Roadmap não é uma palavra nova, mas é comum a galera visualizar essa palavra e pensar em uma grande lista de funcionalidades encadeadas com data pra acontecer, aqui não era diferente.
Nesse momento uma das frases do Marcell na aula da PM3 serviu quase que como um mantra onde eu repetia para todo o time: “Roadmap gerencia resultados, não entregas”.
#2 Mapeando objetivos
Confesso que nesse momento, pelo nível de maturidade, é bem difícil propor que as pessoas pensem orientadas a objetivos e resultados, involuntariamente começa-se pela solução.
Ou seja, antes de qualquer exercício nós já tínhamos uma lista de possíveis soluções para melhorar o produto, o nosso primeiro passo aqui foi olhar para cada solução e se perguntar qual era o resultado esperado com aquilo? Iríamos impactar algum objetivo de negócio?
Esse processo de forma colaborativa fez com o que o time pensasse no direcionamento que queríamos tomar ao longo do ano, começamos com um objetivo macro do ano e quebramos em objetivos menores que pudessem ser atacados em períodos mais curtos.
Como não trabalhamos num modelo de quarter, optamos por um roadmap que abordasse períodos de uma forma mais abrangente seguindo pelo modelo que foi ensinado na aula da PM3 pelo Marcell.
Agora -> Em seguida -> Mais tarde
Abaixo segue um exemplo da estrutura (as informações da imagem são apenas exemplos)
#3 Entendendo quais métricas vão ajudar a medir o resultado
Se você está numa cultura de pouca maturidade de produto, muito provavelmente vocês não estão medindo várias coisas importantes para o seu produto. Foi assim comigo também.
Ter mapeado os objetivos nos ajudaram a entender quais métricas que precisavam ser acompanhadas, encontramos dificuldades no início porque pouca coisa era medida.
Uma das métricas que precisávamos medir era a % de conversão de leads qualificados gerados de uma página específica.
De forma mais simples poderíamos criar um goal pelo próprio analytics, mas para medir esse objetivo precisávamos de coisas básicas que não estavam aplicadas, como eventos e até mesmo criar uma página de “obrigado” como resultado da conversão.
A lição que fica aqui é que se você não está medindo, você não tem o que melhorar.
#4 Levantando hipóteses
Como eu disse um pouco acima, nós já tínhamos uma série de hipóteses que poderiam melhorar o nosso produto, o que fizemos foi um processo de validação de dúvidas e suposições entrevistando usuários para entender melhor os problemas.
Também assistimos horas de gravações de sessões de Hotjar. É muito valioso para ajudar a perceber como o usuário entende o seu produto.
Considerando os objetivos e os momentos de cada um, priorizamos os temas ou hipóteses que teriam maior impacto para cada objetivo.
Para trazer um exemplo de uma hipótese, um dos temas era sobre como poderíamos diminuir o tempo médio de trial-to-paid (tempo que um trial leva para assinar o produto).
A hipótese trabalhada foi:
Se reduzirmos o total de dias do trial, os usuários terão um senso de urgência maior para usarem o produto e isso fará com que o tempo médio de trial-to-paid diminua.
#5 Como ficou a estrutura do roadmap
Usei o Miro para criar o roadmap, aqui no exemplo as informações são meramente ilustrativas, a ideia é mostrar um pouco do modelo de como foi pensado e estruturado.
O legal dessa ferramenta é que você consegue criar diferentes frames do roadmap com mais ou menos informações e exportar isso de uma forma rápida para compartilhar com alguém.
O que eu aprendi sobre o experimento
Em relação ao time, a percepção é que o engajamento aumentou, uma vez que o direcionamento do produto ficou muito mais transparente para todo mundo.
Para mim hoje não é só uma ferramenta essencial para comunicação mas também encaro como um grande protótipo da estratégia que iremos seguir, maturando com o aprendizado constante.
Se você, assim como eu, está no começo de uma carreira de produto, eu diria que uma das coisas mais valiosas é usar o seu contexto atual para aprender e consolidar conhecimentos.
Dê “baby steps”, entenda como você pode pegar algum conteúdo teórico e aplicar na sua rotina, no seu cliente ou no seu produto interno.
Isso vai consolidar a sua teoria e ajudar a sua empresa a desenvolver uma cultura de produto mais forte.
Leia também:
