Imagina você, gerente de produto, terça-feira à tarde, após o almoço, você decide olhar o Notion da sua equipe para ver o andamento das entregas. Quando ao passar o olho no menu lateral esquerdo, você vê uma pequena tag ao lado de uma nova interface escrito “NOVO” destacado com uma cor atípica à plataforma. Você entra na funcionalidade e logo recebe uma mensagem: “Ops, essa função ainda não está disponível”.

Parabéns, você caiu em uma Fake Door Test.

Ou é um bug mesmo, não tem como saber. Mas, pelo bem do texto, vamos admitir que essa experiência foi intencional.

O teste de Fake Door se baseia em passarmos a impressão de oferecermos uma funcionalidade nova, sem a mesma ter sido completamente construída. O objetivo desta ferramenta é validar rapidamente uma hipótese simples, garantindo uma grande confiabilidade nos resultados, metrificando o número de clientes interessados em determinada funcionalidade.

É uma prática muito comum no mercado, porém pouco divulgada, devido a forma de abordagem ao usuário. Afinal, o maior medo é a tal da frustração que o cliente possivelmente vai ter.

— “O usuário vai dar churn”, dizem os mais alarmistas;

— “Não podemos dizer que temos algo sem construir isso”, declaram os tradicionalistas;

— “Quando vamos subir essa funcionalidade por completo?”, conclamam os desinformados.

O fato é que tudo isso se resume em apenas uma coisa: o medo do desconhecido.  Como bons Gerentes de Produto é aí que brilhamos. Afinal, nosso trabalho gira muito em torno de transformar as incertezas em fatos, o medo em confiança e os riscos em experimentos.

Para isso, eu vou mostrar nesse texto algumas técnicas práticas que eu uso para garantir a boa experiência do usuário e a confiabilidade dos dados que você extrai dessa técnica.

Técnicas de mitigação dos riscos

Como todo método, o Fake Door Test possui vantagens e desvantagens, sendo estes os principais:

➕ Confiabilidade do resultado: por se tratar de um cenário em que o cliente não sabe que está sendo testado, é a simulação mais próxima da realidade que podemos ter. Desta forma, conseguimos evitar situações hipotéticas onde o cliente deve responder com base em suposições e conseguimos evitar respostas e reações influenciadas e enviesadas pelo ambiente de teste.

➖ Quebra de expectativa: justamente pelo cliente não saber que está entrando em um ambiente de teste, ele acaba sendo iludido a respeito de uma nova possibilidade, a qual logo em seguida, percebe que não existe.

Tendo em vista os dois lados, o objetivo é sempre equilibrar os dois e fazer o possível para minimizar os impactos negativos.

O quanto você precisa confiar no resultado?

A confiabilidade do seu resultado é diretamente proporcional ao conhecimento da segmentação e target que você definiu de antemão.

O que eu quero dizer com isso? Se você conhece muito bem  seu target de usuários, o problema que você está tentando resolver e a frequência natural desse problema,  garanto que a segmentação vai ser algo natural.

Porém, se a oportunidade não tem uma clareza muito grande disso tudo, você pode usar a técnica justamente para garantir esses dados quantitativos. No entanto, quanto menos usuários você lançar, menor vai ser a sua confiança do viés dos resultados.

Inclusive, dependendo de como a sua equipe de design desenhar o fluxo dessa funcionalidade, você vai garantir um resultado mais ou menos confiável. Vamos ao exemplo:

Componentes como tooltips e tags são excelentes para gerar atração do usuário e garantir a sua capacidade de conhecimento sobre o teste. Todavia, como diferenciar os meros curiosos daqueles que realmente tem o problema que você está resolvendo? Esses mesmos artifícios de design podem mascarar principalmente essa primeira etapa de contato do seu funil de conversão.

Na minha experiência, é importante saber diferenciar os curiosos do target. Principalmente quando você não conhece muito bem o comportamento do seu usuário. A minha dica nesse momento é: só avise que é um teste, ou quebre a expectativa do usuário, apenas no final do teste, não logo na primeira interação. Tenha um funil que garanta essa diferenciação.

Parece óbvio, né? Mas não é. Normalmente, a primeira levantada de mão contra o teste vem com a sugestão que devemos avisar que é um teste logo de cara. Bom, se for pra avisar que é um teste na largada, faça uma pesquisa quantitativa. Aqui, estamos prezando pela confiabilidade dos dados de um experimento rápido e direto!

O golpe está aí, cai quem realmente quer!

Alinhamento interno

Aqui não tem segredo, bons PMs fazem gestão de stakeholders, é o dia a dia. Portanto, é de extrema importância haver um alinhamento entre áreas a respeito dos testes, pois:

• é necessário que estejam cientes e preparados para lidar com clientes que venham a entrar em contato em decorrência do teste;
• podem ajudar a manter contato com os clientes interessados na feature em questão e a fazer essa gestão de expectativa do usuário.

Não existe experiência mais decepcionante do que um time de atendimento e sucesso do cliente ser pego de surpresa quando você sobe um teste. Dependendo da maturidade de cultura de experimentação da sua empresa, você vai acabar passando algumas horas em reuniões acalmando os ânimos e garantindo a confiabilidade da proposta. Para você não apanhar muito, é só seguir esses passos:

Aumente os pontos de contato do seu cliente com o pessoal interno

Pense nas ferramentas que você tem em mãos. Pode ser uma caixa de feedback do Hotjar na tela onde se encontra o final da Fake Door, buscando uma visão quantitativa da frustração gerada nos clientes. Inclusive você pode entrar em contato com esses mesmo clientes para coletar percepções qualitativas do experimento.

Monitoramento dos contatos

Na última tela, insira um botão que pode redirecionar os clientes ao atendimento, através do qual o time estará preparado para lidar com eventuais dúvidas e reclamações que surgirem.

Não esqueça de fazer um estudo de todos os dados possível e legais (Alô, LGPD) de segmentação dos clientes para futuras ações.

“Po, Anselmo, mas aí vai ter aumento dos tickets de atendimento e carga operacional do time”

Não se preocupe, jovem padawan. Comece pequeno, segmente seus usuários com algumas dezenas, depois centenas, então, aí você começa a escalar a partir do momento que você tem mais informações sobre fluxo volumétrico de clientes chegando no time de atendimento.

Lembra de que eu falei sobre a cultura de experimentação? Não precisa dar all-in na primeira vez, com um pouco mais de calma as coisas andam.

Copy, copy, copy. Tudo bem você falar que é um teste

Aqui partimos da seguinte premissa: um teste não é garantia de implementação. Isso tem que ser relembrado constantemente, principalmente para os times internos.

Isso também tem que se refletir no seu copy. Você tem que encontrar o equilíbrio entre “caiu no golpe, otário” e “nos desculpe, vamos implementar isso semana que vem”.

Vou dar um exemplo de um case que tivemos aqui na Conta Simples. Ao final do fluxo completo da Fake Door, subimos o seguinte modal:

“Neste momento, nosso foco é entender a sua necessidade para desenvolver a melhor funcionalidade para seu negócio. Continue acompanhando nossos canais para saber das novidades. Caso queira deixar sua opinião, clique no botão abaixo.” → FALE CONOSCO.

Traduzindo: “Olha, senhor usuário, eu não to dizendo que não vai rolar, mas também não to dizendo que vai rolar. Então segura a onda que estamos experimentando.”

Está tudo bem falar que é um teste. Todas as empresas estão em constante evolução e testando. Não são 10 segundos de quebra de expectativa que farão seu usuário ir embora.

Conclusão

Só para não dizer que eu não trouxe um dado quantitativo para provar que testar é legal.

No caso que citei acima da Conta Simples, 73% dos nossos usuários que completaram a conversão da Fake Door lidaram de forma compreensível e com tom de curiosidade sobre a experiência.

Ou seja, toda vez que você precisar garantir a volumetria de adoção de uma funcionalidade sem precisar dedicar um esforço enorme de implantação, faça uma Fake Door.

Seguindo essas dicas, garanto que você vai trazer excelentes resultados.