problem-statement

Visão geral da skill problem-statement

A skill problem-statement ajuda você a transformar uma demanda de produto vaga em uma definição de problema centrada no usuário, explicando quem está travado, o que essa pessoa tenta fazer, por que isso importa e como ela se sente. A skill problem-statement é mais útil quando você precisa de alinhamento antes de partir para a solução: discovery, priorização, PRDs e revisões com stakeholders.

Para que serve a problem-statement

Esta skill problem-statement foi pensada para enquadrar o problema, não para desenhar funcionalidades. Ela ajuda você a descrever a dor do ponto de vista do usuário, para que os times consigam avaliar se vale a pena seguir com o trabalho antes de discutir implementação.

Para quem ela funciona melhor

Use esta skill se você escreve briefings de produto, especificações técnicas, resumos de pesquisa ou notas de roadmap e precisa de uma narrativa de problema mais limpa. Ela é especialmente útil em fluxos de Technical Writing quando você precisa transformar entradas bagunçadas em uma definição concisa e empática.

O que a torna diferente

A skill centraliza o framework de enquadramento do problema: I am, Trying to, But, Because e Which makes me feel, além de contexto e restrições. Essa estrutura é mais útil para tomada de decisão do que um prompt genérico, porque obriga você a capturar tanto o bloqueio funcional quanto o impacto humano.

Como usar a skill problem-statement

Instale e inspecione a skill

Instale com:

npx skills add deanpeters/Product-Manager-Skills --skill problem-statement

Depois, leia primeiro skills/problem-statement/SKILL.md, seguido de template.md e examples/sample.md. Esse é o jeito mais rápido de entender o formato esperado, a saída final e como é uma boa definição de problema concluída.

O que fornecer no prompt

Para usar bem a skill problem-statement, entregue uma entrada rascunhada, mas específica: o tipo de usuário, a tarefa que ele quer concluir, o bloqueio e quaisquer restrições. Se você fornecer apenas uma solicitação de funcionalidade, a saída tende a escorregar para linguagem de solução em vez de um problema real.

Uma entrada mais forte se parece com isto:

• Persona: “novos agentes de suporte no mobile”
• Objetivo: “resolver tickets sem alternar entre ferramentas”
• Bloqueio: “eles perdem contexto entre o CRM e o chat”
• Restrições: “alto volume, pouco tempo de treinamento, equipe remota”

Fluxo de trabalho sugerido

Comece com um rascunho curto e depois afine até chegar à narrativa em cinco partes. Use o template como checklist: se Because soar como solução, volte e pergunte o que realmente está causando a dor. Se Which makes me feel parecer genérico, troque por uma emoção real do usuário ligada ao fluxo de trabalho.

Arquivos para ler primeiro

Priorize SKILL.md, template.md e examples/sample.md. O arquivo de exemplo é especialmente útil porque mostra tanto um bom padrão de enquadramento quanto um anti-padrão, o que ajuda você a evitar escrever uma solução disfarçada em vez de uma definição de problema.

FAQ da skill problem-statement

A problem-statement é só um modelo de prompt?

Não. A skill problem-statement é um método reutilizável de enquadramento, não apenas um prompt para preencher lacunas. O valor está em forçar clareza sobre o usuário, o bloqueio e a causa raiz antes de você escrever um PRD ou propor uma correção.

Quando eu não devo usá-la?

Não use a skill problem-statement se você já tiver um documento de requisitos bem delimitado ou se estiver documentando um detalhe de implementação. Ela também é uma escolha ruim quando o objetivo é brainstorm de soluções; esta skill existe para definir o problema primeiro.

A problem-statement é amigável para iniciantes?

Sim, desde que você consiga descrever um usuário e uma dor em linguagem simples. O template é simples, mas a qualidade depende de conseguir separar o problema do usuário da solução que você prefere.

Como ela se encaixa no trabalho de Technical Writing?

Para Technical Writing, a skill é útil quando você precisa esclarecer a dor do público, apoiar uma solicitação de documentação ou enquadrar uma lacuna de conteúdo antes de escrever. Ela ajuda a manter o texto focado no resultado do documento, em vez de derivar para uma narração de funcionalidades.

Como melhorar a skill problem-statement

Dê evidências à skill, não slogans

Os melhores resultados com problem-statement vêm de observações concretas: o que o usuário tentou fazer, onde travou, o que usou no lugar e o que quebrou. “Usuários estão confusos” é fraco; “administradores de primeira viagem não conseguem concluir a configuração porque a interface esconde o campo obrigatório da chave de API” é muito melhor.

Separe o problema da solução

Um erro comum é enfiar a correção no meio da descrição. Se o seu rascunho diz “os usuários precisam de um dashboard”, reescreva como “os usuários não conseguem comparar a saúde das contas entre serviços porque os sinais de status estão espalhados”. Isso mantém problem-statement focada na barreira real.

Adicione restrições que mudam a resposta

Inclua qualquer coisa que afete o formato do problema: dispositivo, tamanho do time, pressão de tempo, compliance, nível de experiência ou limitações da plataforma. Esses detalhes tornam a definição mais crível e ajudam a saída final a sustentar uma priorização melhor.

Evolua do rascunho para algo pronto para decisão

Depois da primeira saída, verifique se a definição está específica o suficiente para sobreviver a uma revisão com stakeholders. Se não estiver, refine a persona, torne o Because mais causal e garanta que a frase final possa ser lida sem explicação adicional.