tderoussel/competitive-teardown

Análise Competitiva (Teardown)

O resultado é uma decisão, não um inventário de funcionalidades. Cada lacuna recebe uma classificação, uma estimativa de esforço e um veredito de construir ou ignorar.

Método

1. Pesquise o estado atual do concorrente — preços, posicionamento, o que foi lançado nos últimos 6 meses, do que os usuários reclamam. Datem cada afirmação; a maioria das categorias se move mais rápido do que a análise sobrevive.

2. Audite seu próprio repositório para o que já existe. Este é o passo que muda a resposta. Repetidamente, as "lacunas" de maior valor acabam sendo andaimes adormecidos já no código, sem chamadores, ou uma funcionalidade enviada atrás de uma flag que ninguém ativou. Use grep antes de concluir que algo está faltando.

3. Filtre pelo usuário real. Nomeie a quem seu produto atende, especificamente, e julgue cada lacuna em relação a essa pessoa. Uma funcionalidade que impressiona em uma demonstração empresarial pode ser inútil para um usuário solo, e vice-versa. Indique a quem cada lacuna atende — se a resposta for "alguém para quem não vendemos", esse é o veredito.

4. Classifique pelo valor para esse usuário, com uma estimativa aproximada de esforço e o que torna a implementação barata ou cara.

Estrutura

# <Concorrente> vs <Nós> — Análise de Lacunas Competitivas (AAAA-MM-DD)

<Uma linha nomeando o modo de pesquisa usado.>

## Manchete
<Qual é a verdadeira vantagem deles — geralmente não é o que eles divulgam.>

## Lacunas classificadas
1. **<Lacuna>** (~esforço) — evidência do repositório, por que é importante para o nosso usuário, o que construir.

## Explicitamente não vale a pena copiar
<Nomeado, com razões.>

## Leitura estratégica
<A lição durável, separada da lista de funcionalidades.>

A seção "não vale a pena copiar" é obrigatória

É a seção que mantém o backlog honesto. Sem ela, uma análise é uma lista de trabalho no qual você agora se sente atrasado.

Funcionalidades que demonstram bem e geralmente não servem a ninguém em particular: objetos personalizados, canvases de fluxo de trabalho visual, quadros kanban, superfícies de colaboração em produtos de jogador único e enriquecimento voltado para um comprador para quem você não vende. Rejeite-as pelo nome, com o motivo, para que a próxima análise não as proponha novamente.

Distribuição supera funcionalidades

Quando o concorrente é maior, a ameaça geralmente é como eles alcançam o usuário — agrupamento, uma integração padrão, um relacionamento com o incumbente — não seu conjunto de funcionalidades. Pese isso explicitamente. Uma análise que compara apenas funcionalidades recomendará o trabalho errado.

Restrições permanentes

Mantenha uma lista curta de decisões anteriores para que a análise não reabra questões já resolvidas: coisas que a liderança já decidiu não construir, alegações de posicionamento que foram descartadas e apostas estruturais que não estão em debate. Adicione à medida que os vereditos são emitidos.

Registre-as na própria cópia do projeto desta skill — o ponto é que um concorrente fazer algo não é, por si só, um argumento para reverter uma decisão.

Páginas de comparação

Se a solicitação incluir texto de marketing, siga o padrão da casa que já existe, em vez de inventar um. Mantenha todas as afirmações factuais sobre o concorrente datadas e com fontes — essas páginas são públicas e uma afirmação desatualizada é um risco.

Deixe-as como rascunhos. Não publique uma página de comparação sem aprovação explícita de um humano.

Saída

Escreva a análise onde o projeto mantém sua pesquisa. Se a análise alterar a estratégia, adicione uma seção datada ao hub ou plano relevante — não substitua silenciosamente um veredito anterior.