31 arquétipos de problemas que todo gestor de produto deve reconhecer

Esses 31 arquétipos não são uma lista de curiosidades, são um mapa de falhas estruturais que repetem o mesmo padrão em produtos digitais há anos. O 'Smashed Watch', por exemplo, explica por que tantos times saem de sprints com 'tudo entregue' mas sem impacto: múltiplos problemas estão entrelaçados (UX ruim + dados inconsistentes + integração quebrada), e consertar só um é como trocar o vidro do relógio enquanto o mecanismo está desmontado. Já o 'Leaky Pipe' é a razão pela qual muitos PMs veem métricas piorarem após lançar uma nova feature: resolver a dor do usuário A intensifica a fricção do usuário B, e isso não aparece em nenhum dashboard se você não mapeou as dependências antes.

O 'Oil Land' é especialmente relevante em 2026: com SDKs de IA como o Vercel AI SDK já integrando nativamente UI e streaming, muitos problemas de personalização ou automação estão a um pull request de serem resolvidos, mas ainda ficam parados porque ninguém os nomeou como prioridade. E o 'Toilet Crusade' explica por que tantos PMs evitam melhorar sistemas legados: não há aplauso, só dívida técnica acumulada, mesmo quando a UX desses sistemas está matando conversões, como mostramos em 15 de abril.

Em abril, defendemos que gerenciar problemas, não atualizações, é o cerne do perfil construtor de produto. Agora, com os 31 arquétipos, temos uma linguagem comum para nomear esses problemas *antes* de escrever o primeiro user story. Antes, dizíamos 'temos um problema de alinhamento entre áreas'. Hoje, identificamos: é um 'Middle Court Shot', ninguém assume porque cai entre engenharia, dados e comercial. Antes, chamávamos de 'escopo descontrolado'. Hoje, classificamos como 'Feature Creep', e sabemos que a solução não é mais reunião, mas sim definir um critério de 'problema resolvido' imutável desde a descoberta.

95% dos produtos lançados falham, não por má execução, mas por descoberta equivocada. Esses arquétipos ajudam a cortar o ruído nas conversas com stakeholders: em vez de defender 'precisamos de mais tempo', você mostra que o problema é um 'Shark Laser', a solução proposta não ataca a dor real do cliente, só a sua percepção dela. Isso muda o nível da discussão: de cronograma para estratégia. Também torna visível o que antes era invisível no roadmap: um 'Sleeping Horror' (ex: falta de compliance em dados de IA) pode parecer baixa prioridade até virar multa. Nomear é o primeiro passo para priorizar, e priorizar bem é o que separa PMs que entregam features de quem entrega resultados.