Como entrego resultados

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.

Continuous Delivery e 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 meu conhecimento 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.

Continuous delivery. Acervo pessoal.

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 ela 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:

Você tem alguma oportunidade aderente ao meu perfil, ou quer falar comigo?

Não hesite em falar comigo, clique no botão abaixo.