Ciclo de Discovery de produto: reduzindo incertezas e maximizando valor

Conversa com o programa de aceleração de carreira: MPA 2026

Transcript

1. Ciclo de Discovery de Produto: Reduzindo Incertezas e Maximizando Valor Wagner Beethoven oi@wagnerbeethoven.com.br
2. Olá, sou Wagner Designer fã de café com vasta experiência em na construção de produtos digitais com foco na usabilidade, entusiasta da acessibilidade e da tecnologia assistiva. Acesse meus links aqui!
3. O produto nasce de um problema mal resolvido, não de um pedido. Discovery não é um cargo, é uma responsabilidade coletiva para evitar a construção da coisa errada.
4. Armadilha: “tirar pedidos” • Construção baseada em opiniões ou pedidos isolados. • Resultado: Produtos caros que ninguém usa. • Mentalidade: “order taking”
5. Objetivo: resolver problemas • Integração de negócios, tecnologia, operações e pessoas. • Busca pela causa raiz. • Resultado: soluções de valor real.
6. Os 4 grandes riscos: por que não vamos direto para o código? de valor O cliente vai comprar ou escolher usar? de viabilidade técnica Temos tecnologia para construir? de usabilidade O usuário consegue descobrir como usar? de viabilidade de negócio Funciona para o nosso modelo de negócio?
7. Case real: o dashboard de ninguém Contexto: Clientes pediam “relatórios”. O time passou meses construindo um dashboard sofisticado. Resultado: O que o cliente queria era apenas baixar um CSV. Lição: ouvir a necessidade real teria poupado meses de desenvolvimento (risco de valor)
8. Discover é um processo de redução de incerteza.
9. “Discovery não busca respostas finais, busca decisões melhores.” O que não é? O que é? Uma frase isolada antes do delivery (waterfall) Um hábito contínuo de validação. Brainstorming sem direção. Pensamento crítico e pesquisa com método. Apenas gerar artefatos bonitos. Aprender rápido para mitigar riscos. O produto é um sistema de decisões, não apenas uma tela.
10. Compreender O que é? Definir E se...? Insight, problema ou acordo de trabalho inicial? Planejamento Idear Que Prototipar e Testar O que funciona? Entregar Shadowing Pesquisa qualitativa/ quantitativa Análise de dados Resumir em uma frase clara e priorizar De esboços em Papel a MVPs Testes A/B Entrevistas Surveys Não é uma linha reta. O ciclo recomeça com novo insights. Os aprendizados alimentam o backlog continuamente.
11. As caixas de ferramentas Métodos servem ao contexto. Não use todos de uma vez , use o que reduz o risco atual. Exploração Definição/Ideação Validação • Entrevista de profundidade • Shadowing (observação) • Desk Research • Análise de dados • Event storming • User Journey Mapping • Design sprints • Teste de usabilidade • Landing pages • “Fakes door” testes • Prototipagem (baixa/alta fidelidade) Atenção: Métodos são úteis, mas não substituem o pensamento crítico. Cuidado para não sair no “teatro do Discovery”
12. Discovery na prática: Caso Hustly Desafio: Tom, um empresário que a ajudar sua filha Amy (16 anos) a encontrar “bicos” (trabalhos rápidos) de forma segura.
13. Hustly: da fricção ao MVP O aprendizado: • Feedback: “a navegação estava confusa e havia dúvidas sobre a reputação dos contratantes”; • Ação: ajustes imediatos na interface e inclusão de “ratings” antes do lançamento massivo. Descobrir exige experimentação e ajustes constantes, não apenas seguir um plano inicial.
14. Dinâmica 1: quem é e qual é a dor? Objetivo: exercitar um olhar para o usuário e validar se é um problema é real.
15. Dinâmica 2: Hipóteses e experimentos. Objetivo: entender que toda ideia carrega riscos e precisa de teste. 1. Listar suposições: o que precisa ser verdade para isso funcionar? 2. Priorizar na matriz de risco 3. Desenhar o experimento: como testar rápido? Exemplo: Se a dúvida é sobre o valor de um relatório, envie um CSV manual antes de codificar um dashboard. Esforço Alto Alto Baixo Baixo Impacto
16. Dinâmica 3: Prototipação rápida. Objetivo: visualizar a solução para aprender, não para vender Instruções: 1. Mapear jornada: desenhar o passo a passo da experiência atual vs desejada. 2. Sketching: usar papel ou quadro branco. Desenhar a tela ou fluxo que resolve a maior dor. 2. Teste de “corredor”: Trocar protótipo com colegas e coletar feedbacks imediatos.
17. Antipadrões: o que evitar desde o Dia 1. Validar a solução, não o problema Pergunta viciada: “vocês gostariam desse app? Discovery de evento único Tratar como uma fase que acaba quando o código começa. Terceirização “Designers pesquisam, PMs decidem, Devs codam” Ignorar riscos técnicos Descobrir tarde demais que a tecnologia não suporta a ideia. Síndrome do check- list Fazer as cerimônias sem buscar o aprendizado real.
18. Elenco: Discovery é um esporte coletivo. Engenharia (Devs) Participa de entrevistas, avalia viabilidades técnicas Agilista Remove impedimentos, garante fluxos. Produtct Manager Prioriza problemas, decide experimentos. Product Designer Conduz investigação, facilita workshops. Um case típico de falha é quando apenas designers pesquisam e devs apenas codam.
19. Conectando Discovery & Delivery Sem silos: Discovery sem entrega vira academia; entrega sem Discovery vira desperdício. Fluxo contínuo: o ciclo alterna pesquisa e execução. Priorização: baseada em valor vs complexidade. Métricas: retenção, adoção e NPS
20. Discovery não é moda, é disciplina estratégica. Reduzir risco antes de gasta dinheiro Apaixonar-se pelo problema, não pela solução. Aprender rápido é a maior vantagem competitiva. Pratique continuamente. O aprendizado nunca para. Não decore frameworks, aplique pensamentos críticos e humildade para aprender com os usuários.
21. Obrigado Acesse meus links aqui!