Como entrego resultados
Veja um pouco da metodologia de trabalho que aplico.
Como entrego valor com produto?
Acredito que um produto de sucesso nasce da combinação entre descoberta contínua, validação baseada em dados e execução eficiente.
Meu foco é que o produto seja um grande aliado do negócio como uma forte alavanca de crescimento de acordo com seus objetivos, gerando receita, adoção do produto e maximizando a entrega de valor aos clientes.
Por isso sempre vou entender profundamente o problema, alinhar stakeholders e garantir que entregamos soluções que realmente geram impacto.
Entre as várias abordagens que existem no desenvolvimento de produto, até o momento o Dual-track Agile é o que mais se aproxima do que utilizo na gestão dos produtos.
No Dual-track, enquanto o time de engenharia desenvolve uma solução, outra parte do time foca em validar e especificar as soluções que serão construídas mais para frente. Sendo o discovery de responsabilidade do PM, Product Designer e Tech Lead, e o propósito garantir que tenhamos evidências suficientes de que, quando pedirmos aos engenheiros para construir o produto, não será esforço e tempo perdido.
Dual Track Agile
Dual-track Agile, by Jeff Patton.
Estruturação de processos
A primeira coisa que avalio em uma área de tecnologia são os processos e métodos envolvidos, não com o objetivo de engessar, mas sim de estruturar rotinas, otimizá-las e reduzir a dependência de maturidade do time. Considero essa habilidade como ponto forte, e a adquiri na minha graduação em Engenharia de Produção e período trabalhando na Nestlé em Performance Industrial.
Em 2020, quando a Neemo foi adquirida via M&A pela Linx, o processo de resolução de bugs era falho, não havia um bom acompanhamento de SLAs.
Eu liderava Produto e a gestão dos SLAs era do gerente de P&D, porém, eu peguei o desafio dado minha facilidade em estruturação de processos. Liderei a criação dos SLAs, documentações, treinamentos, rotinas e etc. Em 2 meses, saímos do zero para um atingimento de +90% do SLA consistentemente.
Talvez você esteja pensando agora:
"Mas é fácil assim, já que não existia meta, é só criar uma meta facilmente atingível..."
Não, tomei cuidado com isso, analisei o histórico de resolução de bugs para ter uma base e colocamos o objetivo de melhorar em 20% o tempo médio de resolução de bugs.
Costumo dizer que a área de desenvolvimento de software é como uma linha de produção, a diferença é que o output é software, ao invés de um produto físico. Os objetivos e Product Discovery são os insumos, e o Product Delivery é a etapa de produção propriamente dita.
Case real sobre estruturação de processos:
Product Discovery
Um dos principais desafios de um Product Discovery é encontrar uma solução que valha a pena ser construída. No contexto de desenvolvimento de software, pode ser uma melhoria, feature ou um novo produto.
O processo começa a partir de um input, que pode ser um objetivo, informação ou hipótese, o papel do discovery é validar hipótese e reduzir riscos até chegar em um output, que pode ser uma hipótese validada, nível de risco, potencial de receita sobre determinado caminho e etc.
Não vou detalhar os riscos que busco mitigar em um discovery, porque existem vários autores relevantes que falam sobre isso (Ex. Marty Cagan), mas vou citar uma variável a seguir que considero importante, que não é fácil de medir e sempre a levo em consideração na hora de liderar um discovery:
Na dinâmica real de um negócio, nunca teremos tempo ou recursos suficientes para sempre ter certeza sobre uma hipótese, por isso existe um equilíbrio importante entre ritmo e qualidade que deve ser dimensionado para definir os requisitos mínimos de um bom discovery e se uma ideia deve ser seguida adiante.
Acervo pessoal. Adaptado da PM3
Ritmo VS Qualidade:
Case real de um Product Discovery:
Disclaimer: Algumas informações sensíveis foram omitidas para preservar confidencialidade.
O desafio é encontrar esse equilíbrio, pois se você toma as decisões em um ritmo muito acelerado, você tende a tomar decisões mais aleatórias, enquanto se você prezar excessivamente pela qualidade, chegará em um nível de indecisão, ou pode perder o timing do negócio.
Levantamos a seguinte hipótese:
Desenvolver um PDV de Food autosserviço para SMB pode ser uma grande alavanca de crescimento e de valor agregado na base de adquirência.
Tendo a hipótese, criei uma squad multidisciplinar com a seguinte estrutura:
- 1 PM;
- 1 PO;
- 1 UX/UI;
- 1 Eng;
- 1 Mkt.
Defini um deadline para o discovery considerando timing do negócio e recursos disponíveis, separando o cronograma da seguinte forma:
Fiz kickoff, esclarecemos o objetivo e etc, mas não vou detalhar aqui a execução em si, quero mostrar visualmente como o Risco variou em relação ao Tempo:
No gráfico acima, ilustro duas variáveis importantes em qualquer discovery:
Porém, quando chegamos na etapa de Riscos de negócio, surgiu um aspecto externo, que aumentava o risco significativamente, conforme imagem abaixo:
Resultado: Decidimos não avançar com o projeto naquele momento.
Aí você pode estar pensando: "Isso não é um case de Discovery de sucesso..."
É sim, Product Discovery não é sempre sobre criar soluções disruptivas. É sobre tomar boas decisões pautadas em dados, pesquisa e etc.
Deixamos de cometer um erro que poderia custar muito dinheiro e tempo e o aprendizado obtido foi levado em projetos futuros.
Risco:
Todos os discoveries têm como objetivo mitigar riscos para apoiar na tomada de decisões.
Linha de tolerância:
Existe uma linha de tolerância que é intangível, mas diz sobre o quanto a empresa está disposta a arriscar. Essa linha vai diminuindo ao longo do tempo em um discovery, porque naturalmente os stakeholders esperam que o risco reduza conforme vai sendo investido tempo e recursos na pesquisa.
Ou seja, se você investir 6 meses em um discovery, não é aceitável assumir um risco muito alto, já deveria ter um bom racional estruturado sobre a hipótese.
O risco foi reduzindo, conforme imagem abaixo, até que ultrapassou a linha da tolerância, ou seja, havia uma boa probabilidade de avançarmos com a ideia de desenvolver a solução:
Product Analytics
O que não é medido, não pode ser melhorado. Levo isso como premissa no dia a dia.
Só que nem sempre teremos dados suficientes e disponíveis para pautar nossas decisões. Por isso as vezes será necessário fazer um trabalho estrutural para mapear nos produtos quais dados/métricas deveríamos medir, e como esses dados ficarão disponíveis para os times, seja um PowerBI, SQL, Google Analytics ou qualquer outra ferramenta.
Já utilizei muito Google Analytics, Hotjar, Microsoft Clarity e excel para análise de dados, nos últimos tempos tenho explorado SQL (em breve vou incluir aqui um case de product analytics).
Na imagem abaixo, o Daniel Paredes (instrutor do curso de Product Analytics, que fiz há um tempo) demonstrou bem e de forma visual como normalmente nós pautamos uma decisão.
Não podemos ignorar aspectos como Intuição, Estética e Experiência do Usuário, mas sempre tento pautar as decisões em dados sempre que possível. Se não for possível porque está faltando dados que poderiam ser mensurados, inicio a coleta dos dados para analisar uma amostra, antes de tomar a decisão (se houver timing para isso).
Acervo pessoal. Adaptado da Tera - Product Analytics
Abordagem informada em dados:
Você tem alguma oportunidade aderente ao meu perfil, ou quer falar comigo?
Não hesite em falar comigo, clique no botão abaixo.