Visão geral
Fake Door Test é uma técnica de validação usada para medir interesse real em uma funcionalidade com comportamento observado — um clique — antes de investir semanas em desenvolvimento, evitando construir o que ninguém vai usar. A utilidade dela está menos no ritual em si e mais na forma como ajuda o time a transformar uma dúvida de projeto em evidências, decisões ou próximos passos observáveis.
Ela faz sentido quando a equipe debate se uma funcionalidade tem demanda suficiente e há produto ao vivo com tráfego. Mais útil em early-stage de funcionalidade ou quando o backlog concorre por recursos escassos. Ao aplicar Fake Door Test, o time deve chegar a taxa de clique por segmento, Volume de interesse qualificado e Decisão de construir, pivotar ou descartar, mantendo rastreabilidade entre o que foi observado, o que foi decidido e quais limites ainda precisam ser considerados.
Como entra no fluxo
Fake Door Test entra quando já existe uma pergunta de trabalho clara e o time precisa conduzir uma atividade estruturada antes de avançar para decisão, protótipo, priorização ou entrega.
Atenção ao usar
Mede intenção de clique, não uso real ou retenção da funcionalidade.
Combina bem com
- Wizard of Oz
- Concept Testing
- A B Testing
Para que serve
Medir interesse real em uma funcionalidade com comportamento observado — um clique — antes de investir semanas em desenvolvimento, evitando construir o que ninguém vai usar.
Quando usar
Use quando a equipe debate se uma funcionalidade tem demanda suficiente e há produto ao vivo com tráfego. Mais útil em early-stage de funcionalidade ou quando o backlog concorre por recursos escassos.
Contexto
Objetivos
Outputs
Situações ideais
- alta incerteza
- necessidade de decisão rápida
Como executar
Pré-requisitos
- Produto ao vivo com usuários reais
- Hipótese clara sobre a funcionalidade e o segmento-alvo
- Tela de destino para quem clicar (pode ser "em breve" ou formulário de interesse)
- Ferramenta de analytics para capturar o evento de clique
Materiais
- Acesso para deploy de UI
- Ferramenta de analytics ou feature flag
- Tela de destino ou modal de coleta de interesse
- Critério de sucesso definido antes de lançar
Passo a passo
- 1Defina a funcionalidade hipotética e o segmento que mais se beneficiaria.
- 2Crie CTA, botão ou link no produto com linguagem que comunica o valor.
- 3Prepare tela de destino — "em breve" honesto ou formulário de lista de espera.
- 4Defina critério de sucesso antes de lançar (ex. taxa de clique mínima).
- 5Publique e monitore cliques por segmento, contexto e frequência.
- 6Após volume suficiente, avalie resultado contra critério.
- 7Entreviste quem demonstrou interesse para entender a motivação.
Critérios de qualidade
- O critério de sucesso foi definido antes do lançamento, não após ver os dados
- A amostra tem volume suficiente para não ser ruído estatístico
- A tela de destino é honesta — não engana o usuário
- O contexto do CTA no produto é representativo do uso real da funcionalidade
Dicas
- Seja honesto na tela de destino — "ainda não existe" gera confiança.
- Segmente o resultado — taxa geral esconde diferenças entre públicos.
- Complemente com entrevistas de quem clicou — clique não explica motivação.
- Taxa de clique baixa pode indicar problema de posicionamento, não de demanda.
Antes (entradas)
- Hipótese de funcionalidade
- Segmento-alvo
- Critério de sucesso pré-definido
Depois (saídas)
- Taxa de clique por segmento
- Volume de interesse qualificado
- Decisão de construir, pivotar ou descartar
Variações
Smoke Test por Landing Page
Cria página dedicada descrevendo a funcionalidade antes de existir, com formulário de cadastro de interesse, e mede conversão via ads ou SEO orgânico.
Fake Door em Onboarding
Apresenta opções de fluxo de onboarding que ainda não existem para identificar qual segmento tem mais tração antes de construir cada um.
Fake Door com Preço
Inclui funcionalidade em plano pago antes de construir para medir se o preço é barreira ou se a proposta de valor é suficiente para conversão.
Uso estratégico
Quando evitar
- Produto não tem tráfego suficiente para gerar sinal confiável
- A funcionalidade é de segurança, compliance ou acesso essencial — não se testa com fake door
- O time vai construir independente do resultado — o teste seria teatro
Limitações
- Mede intenção de clique, não uso real ou retenção da funcionalidade
- Contexto do CTA no produto afeta muito o resultado — generalização arriscada
- Não revela por que o usuário clicou ou não clicou
Riscos
- Frustrar usuários que clicam e descobrem que não existe
- Interpretar taxa baixa como falta de demanda sem investigar posicionamento
- Tomar decisão com volume insuficiente de dados
Exemplos de uso
- 01Testar demanda por relatório avançado antes de desenvolver módulo.
- 02Medir interesse em plano anual antes de criar infraestrutura de billing.
- 03Validar se segmento B2B clica em funcionalidade de equipe antes de construir.
Perfis responsáveis
Também conhecido como
Referências e leitura
Ajude a melhorar este conteúdo
Encontrou erro, lacuna técnica ou exemplo fraco? Envie uma correção com contexto para revisão.
