A Arte da Formulação
Encontrar o problema certo é metade do trabalho. A outra metade é escrever de forma que outros possam entender, validar e agir. Um problema mal escrito, mesmo sendo o problema certo, vai gerar confusão, interpretações divergentes e soluções desalinhadas.
A boa notícia: existe um formato que funciona quase sempre. É simples, direto, e força você a pensar nas partes essenciais de qualquer problema.
A Fórmula do Problem Statement
[Audiência] não consegue [resultado desejado]
porque [causa raiz]
Essa estrutura simples contém os três elementos essenciais:
- Audiência: Para quem é problema? Quão específico você consegue ser?
- Resultado desejado: O que essa audiência está tentando conseguir?
- Causa raiz: Por que não conseguem? Qual é o bloqueio real?
Decompondo a Fórmula
1. Audiência: Seja Específico
"Nossos clientes" é vago demais. "Millennials" ainda é vago. A audiência precisa ser específica o suficiente para que você possa imaginar uma pessoa real com esse problema.
❌ Vago Demais
"Consumidores"
"Jovens adultos"
"Usuários do app"
Não sabemos quem são, o que fazem, em que contexto
✓ Específico
"Mães de primeira viagem"
"Profissionais de TI em transição de carreira"
"Usuários que tentam finalizar compra no mobile"
Sabemos quem são e podemos imaginar seu contexto
2. Resultado Desejado: O que Querem Conseguir
Não confunda resultado com solução. O resultado é o objetivo final, não o meio. "Usar nosso app" não é resultado. "Acompanhar seus gastos facilmente" é resultado.
❌ Solução Disfarçada
"Baixar nosso app"
"Ler nossas newsletters"
"Comprar mais"
São objetivos da empresa, não da audiência
✓ Resultado Real
"Controlar seu orçamento mensal"
"Manter-se informado sem perder tempo"
"Encontrar o produto certo para suas necessidades"
São coisas que a audiência realmente quer
3. Causa Raiz: O Bloqueio Real
A causa raiz deve explicar por que a audiência não consegue o resultado. Deve ser algo acionável, não forças externas incontroláveis.
❌ Não Acionável
"A economia está ruim"
"As pessoas são preguiçosas"
"A tecnologia não existe"
Não há nada que possamos fazer sobre isso
✓ Acionável
"Não existe forma simples de comparar opções"
"O processo exige muitos passos"
"A informação necessária não está acessível"
Podemos criar soluções para esses bloqueios
Exemplos Completos: Ruim vs. Bom
❌ Problem Statement Ruim
"Nossos clientes não compram mais."
Problemas: Audiência vaga, resultado é objetivo da empresa, sem causa identificada
✓ Problem Statement Bom
"Pais de crianças pequenas não conseguem planejar refeições saudáveis durante a semana porque não têm tempo para pesquisar receitas e fazer lista de compras."
Qualidades: Audiência específica, resultado real, causa acionável
❌ Problem Statement Ruim
"Precisamos de mais awareness."
Problemas: Não é problema, é solução. Sem audiência, sem causa
✓ Problem Statement Bom
"Profissionais de marketing de pequenas empresas não conseguem tomar decisões informadas sobre fornecedores porque não existe fonte confiável de avaliações comparativas."
Qualidades: Audiência específica, resultado claro, causa que podemos resolver
Testes de Qualidade
Depois de escrever seu problem statement, passe pelos seguintes testes:
Checklist do Problem Statement
- Teste da Pessoa Real: Consigo imaginar uma pessoa específica com esse problema?
- Teste do "Por Quê": Se perguntar "por quê?" a causa, chego a algo mais fundamental?
- Teste da Ação: A causa identificada é algo que podemos resolver?
- Teste da Solução Neutra: O problema permite múltiplas soluções possíveis?
- Teste do Stakeholder: Se mostrar para quem vive o problema, vai reconhecer?
- Teste do Competidor: O mesmo problema poderia ser resolvido por um concorrente?
- Teste da Métrica: Existe forma de medir se resolvemos?
Explicando os Testes
Teste da Solução Neutra: Se seu problem statement só permite uma solução possível, provavelmente você está descrevendo a solução, não o problema. Um bom problema pode ser resolvido de várias formas.
Teste do Competidor: Se um concorrente poderia resolver o mesmo problema, então é um problema real de mercado, não uma necessidade interna disfarçada.
Slack: O Problem Statement que Mudou Tudo
O Slack não nasceu como "mais uma ferramenta de chat corporativo". O problema que atacavam era muito mais específico.
O Problem Statement
"Equipes de trabalho distribuídas não conseguem manter contexto compartilhado porque a comunicação por email fragmenta conversas e enterra informações importantes."
Análise da Formulação
Audiência: Equipes de trabalho distribuídas (não "empresas" ou "profissionais")
Resultado: Manter contexto compartilhado (não "comunicar" ou "colaborar" genericamente)
Causa: Email fragmenta e enterra (acionável: criar alternativa ao email)
Por Que Funcionou
O problema era específico o suficiente para guiar decisões de produto (canais organizados por tópico, busca potente, histórico persistente) mas amplo o suficiente para um mercado enorme.
Formatos Alternativos
A fórmula básica funciona na maioria dos casos, mas existem variações úteis:
Formato "How Might We"
Popularizado pela IDEO, esse formato é útil para transição para ideação:
"Como poderíamos ajudar [audiência] a [resultado] superando [causa raiz]?"
Exemplo: "Como poderíamos ajudar mães de primeira viagem a dormir melhor superando a ansiedade sobre o bebê?"
Formato Jobs to Be Done
Baseado no framework de Clayton Christensen:
"Quando [situação], eu quero [motivação] para que eu possa [resultado esperado]."
Exemplo: "Quando estou em uma reunião e preciso de um dado, eu quero acessar rapidamente para que eu possa responder sem parecer despreparado."
Erros Comuns e Como Evitar
- Problema muito amplo: "As pessoas não são saudáveis" não é acionável. Estreite: qual aspecto de saúde, qual comportamento, qual contexto?
- Problema muito estreito: "Usuários do botão verde da página 3 não clicam" é tático demais. Qual é o problema maior que isso representa?
- Causa circular: "Não vendem porque não compram" não explica nada. Por que não compram?
- Jargão interno: "O funil está vazando no MQL" significa nada para quem não é da área. Reescreva em linguagem humana.
- Múltiplos problemas: "Usuários não encontram e não entendem e não confiam" são três problemas. Priorize um.
Iterando o Problem Statement
Seu primeiro problem statement raramente será o final. O processo é iterativo:
Processo de Refinamento
Passo 1: Rascunho Rápido
Escreva uma primeira versão em 5 minutos, mesmo que imperfeita.
Passo 2: Aplique os Testes
Passe pelo checklist. Anote onde falha.
Passo 3: Questione Cada Elemento
A audiência pode ser mais específica? A causa é realmente a raiz?
Passo 4: Valide com Stakeholders
Mostre para quem vive o problema. Eles reconhecem?
Passo 5: Refine e Documente
Atualize com os feedbacks. Formalize como documento oficial.
Teste Seus Conhecimentos
5 perguntas sobre o conteúdo deste módulo
1. Qual é a estrutura da fórmula do problem statement?
2. "Nossos clientes" como audiência é problemático porque:
3. O que o "Teste da Solução Neutra" verifica?
4. No case do Slack, qual era a causa raiz identificada?
5. Qual destes é um erro comum em problem statements?
Perguntas corretas
📝 Exercício Prático
Escreva três problem statements para um mesmo contexto (pode ser seu trabalho atual ou uma marca que você conhece):
- Escreva um problem statement ruim (propositalmente vago, com solução embutida, etc.)
- Identifique o que está errado usando os testes de qualidade
- Reescreva como um problem statement bom
- Mostre ambas as versões para um colega e peça feedback
- Refine baseado no feedback recebido
Compare suas versões: como a segunda mudaria o tipo de solução que você buscaria?