Skip to content
Reuniões estruturadasQuestionamento ativoQue progresso o usuário está tentando fazer?Qual métrica isso impacta?
PMDesignerTech LeadData
Quebra solution-first.Pressiona evidência.Identifica se é causa ou sintoma.Eleva a conversa para impacto estratégico.
O kick-off já nasce errado.Você oficializa um problema mal definido.O time trabalha em cima de suposição.
redesenhar a interfacereorganizar camposmudar layout
Diferentes visões não alinhadasDecisões baseadas em opinião individualConflitos ao longo do processoProblema mal definido ou mal priorizado
Alinhamento claro entre as áreasProblema compreendido de forma compartilhadaRedução de conflitos e retrabalhoBase sólida para estruturar o Job (JTBD)
Objetivo
Desafiar e alinhar o entendimento do problema
Papel no processo
Aqui você coleta e tensiona diferentes visões sobre o problema.
Como conduzir
JTBD + OKRs
Reunião para extrair clareza de stakeholders
Pense nessa etapa como uma reunião de tensionamento estratégico.
Você não entra vazio. Você entra com base mínima.
Esse é o seu instrumento de autoridade.
Use em 1:1 ou reunião pequena.
Para que serve (resumo: Quebra suposição e valida impacto real)
Serve para desafiar suposições e evitar decisões baseadas em solução pronta.
É a etapa que transforma
De → “Precisamos melhorar isso.”
Para → “Existe um problema real que está impactando X métrica.”
Exemplo aplicado
Antes da conversa
“Precisamos criar um simulador melhor para aporte.”
Depois da reunião estruturada
“Usuários estão abandonando o fluxo porque não têm clareza sobre o valor permitido de aporte e têm medo de cometer erro fiscal.”
Quando usar
Antes do kick-off oficial da iniciativa.
Antes de iniciar o projeto de melhoria do fluxo de aporte, é realizada uma reunião com
Para entender se o problema é realmente experiência ou algo mais profundo.
O que ela resolve
Exemplo aplicado
O time inicialmente acreditava que o problema era
Interface confusa.
A reunião revelou que o problema real era:
Insegurança fiscal sobre o valor de aporte.
Se você pular essa etapa
Exemplo aplicado
Sem essa etapa, o time poderia
Mas o problema real (medo de erro fiscal) continuaria existindo.
Resultado esperado dessa etapa
Ao final desta etapa, o time deve sair com um entendimento compartilhado e minimamente estruturado sobre o problema.
Isso inclui
Problema claro e alinhado
→ O time consegue descrever o problema da mesma forma, sem interpretações diferentes
Usuário definido
→ Há clareza sobre quem é impactado e em qual contexto isso acontece
Relevância validada
→ O time entende por que esse problema importa agora (urgência, frequência, impacto)
Alinhamento entre áreas
→ Principais stakeholders concordam sobre o direcionamento inicial
Conexão inicial com o negócio
→ Existe uma visão de qual métrica pode ser impactada (mesmo que ainda não refinada)
Principais dúvidas e riscos explícitos
→ O que não está claro foi identificado (e não ignorado)
Em outras palavras:
O problema deixa de ser individual e passa a ser coletivo
O que essa etapa garante
Sem Stakeholders
Com Stakeholders
O time passa a trabalhar sobre o mesmo problema
Resumo
Stakeholders não definem a solução.
Eles ajudam a revelar o problema.
Essas respostas preparam você para a próxima etapa
Want to print your doc?
This is not the way.
This is not the way.
Try clicking the ··· in the right corner or using a keyboard shortcut (
CtrlP
) instead.