mLabs
Como validei o interesse em uma integração com a Stone antes de uma única linha de código ser escrita.
challenge.
A Stone propôs incluir um link de pagamento dentro do Inbox da mLabs — o chat unificado das redes sociais. Antes de mobilizar squads e gastar meses construindo uma integração, eu precisava responder duas perguntas: os usuários realmente querem isso? e como eles vendem e cobram hoje?. Construir pra descobrir saía caro. Perguntar direto também não funcionava — usuário diz que quer tudo. Precisava de um teste que medisse comportamento real.
how I solved.
Desenhei um fake door: um botão de fácil acesso no Inbox que, ao ser clicado, abria um modal perguntando se o usuário tinha interesse em enviar link de pagamento Stone direto na conversa. Sem feature por trás. Apenas instrumentação pra medir quantos acessavam o Inbox, quantos clicavam no botão e quantos confirmavam interesse. No mesmo modal, abri espaço pra pesquisa qualitativa: como o usuário vende hoje, quais soluções já usa, o que espera de um link de pagamento.
results.
14 respostas qualitativas estruturadas em 7 grandes temas: integração, personalização, segurança, competitividade de taxas, facilidade de uso, inovação (QR Code) e suporte. Os usuários validaram interesse e ainda entregaram, de graça, o benchmark da concorrência (Pagar.me, PagSeguro, Cielo, Safra Pay, Picpay). A conversa com a Stone deixou de ser sobre 'fazer ou não fazer' e passou a ser sobre como fazer pra ganhar do que já existe.
activities.
context.
A mLabs é uma plataforma de gestão de redes sociais. O Inbox é o módulo de chat unificado: o usuário responde DMs do Instagram, Facebook e outras redes em um só lugar. A Stone propôs integrar link de pagamento direto nessa conversa — o vendedor cobra o cliente sem sair do chat.
Atuei como Product Designer responsável por desenhar o fake door, definir os eventos de tracking, redigir a pesquisa qualitativa e sintetizar os achados em recomendações acionáveis pro time de produto e pra parceria com a Stone.
Antes de mobilizar dev, design e integração com a Stone, era essencial ter dado de comportamento real — não opinião em entrevista. Fake door entrega isso: o usuário acha que a feature existe e clica (ou não).
Uma integração de pagamento entre duas plataformas (mLabs + Stone) é cara: contratos, squads, compliance, prazos. Errar na hipótese custa meses. Acertar com fake door custa uma semana de design.
methodology.
O fake door isolado mede interesse. A pesquisa isolada mede opinião. Combinei as duas coisas na mesma jornada: o clique no botão dispara o modal, o modal valida interesse e abre espaço pra contexto qualitativo. Quantitativo direciona, qualitativo explica.
Botão de pagamento Stone no header do Inbox, posicionado pra ser descoberto naturalmente no fluxo de conversa — sem banner, sem onboarding, sem aviso. O usuário precisa achar como acharia uma feature real.
Três eventos: acesso ao Inbox, clique no botão Stone, confirmação de interesse no modal. O funil mostra quem viu, quem se interessou e quem cravou.
Perguntas abertas dentro do próprio modal: como vende hoje, quais ferramentas usa, o que espera de um link de pagamento. Captura no momento de maior interesse — diferente de mandar formulário depois.
Leitura cruzada dos 14 depoimentos, agrupamento por tópico, extração de citações marcantes e priorização do que vira requisito de produto.
Documento de achados estruturado pra alimentar tanto o time interno quanto a conversa com a Stone — com benchmark indireto incluído (concorrentes citados pelos próprios usuários).
discovery.
A análise dos 14 depoimentos revelou um cenário diversificado — cada usuário trouxe uma camada diferente do problema. Sete temas se repetiram com força:
Usuários iniciando negócio online buscam fluxo de check-out direto, sem fricção. A integração nativa no Inbox responde a essa dor — ferramenta única, sem precisar pular pra outra plataforma.
Demanda clara por boleto, depósito, cartão de crédito parcelado e débito no mesmo link. O vendedor quer oferecer ao cliente a forma que ele preferir — não impor uma só.
Os usuários cobram a mesma confiabilidade da transação presencial, incluindo a possibilidade de antecipação. Segurança aqui não é só técnica — é percepção da marca.
Vários compararam diretamente PagSeguro, Cielo e Safra Pay. Quem usa link de pagamento sabe exatamente quanto paga — e quanto pode repassar. Taxa alta mata a hipótese.
Interface intuitiva e suporte a várias bandeiras/operadoras. O usuário não quer estudar a ferramenta; quer mandar o link e receber.
Sugestão recorrente de QR Code pra pagamento instantâneo, sem digitar dados. Sinal de que o usuário acompanha a evolução do mercado e espera o mesmo da mLabs.
Relato negativo com o Picpay (suporte inexistente quando a cliente pagou pra pessoa errada) mostrou que suporte é dealbreaker. Erro acontece — o que importa é como a marca responde.
Três tensões se cruzavam:
• Tempo: a conversa com a Stone tinha prazo. Construir pra testar levaria meses. • Risco: entregar uma integração que ninguém usa queima credibilidade dos dois lados. • Profundidade: medir só o clique não basta — precisava entender o porquê do interesse e como o usuário compara essa solução com o que já usa.
impacto real
Pensa em um pequeno empreendedor que vende pelo Instagram. Ele responde DMs o dia todo no Inbox da mLabs, fecha pedido, e na hora de cobrar precisa: abrir outra aba, gerar o link no Pagar.me ou PagSeguro, copiar, voltar pro chat, colar. Cada etapa é uma chance de perder a venda — distração, link errado, cliente desistindo. O botão direto no Inbox encurta isso pra um toque. A pergunta era: o usuário percebe esse atalho como valor real, ou ele já se acostumou com a fricção?
proposed solution.
A solução fake door foi propositalmente minimalista: um único botão no Inbox que abre um modal. Sem feature por trás. O foco era extrair sinal de comportamento real (cliques) e contexto rico (depoimentos) na mesma jornada — antes de qualquer linha de código de integração.
O fake door abriu três frentes de oportunidade pra integração real:
fake door in action.
Botão Stone no Inbox abrindo o modal de interesse — fluxo real testado em produção.
results.
antes
Validação
✗ Hipótese baseada em opinião do time
Custo do teste
✗ Meses de squad + integração
Sinal de demanda
✗ Suposição — 'usuário deve querer'
Visão do usuário
✗ Sem dado qualitativo estruturado
Benchmark
✗ Pesquisa de mercado paga e demorada
Risco
✗ Construir feature que ninguém usa
Decisão no escuro, com risco alto e prazo longo
depois
Validação
✓ Comportamento real medido em 1 semana
Custo do teste
✓ Design + tracking, zero código de produto
Sinal de demanda
✓ Funil completo: viu → clicou → confirmou interesse
Visão do usuário
✓ 14 depoimentos sintetizados em 7 temas
Benchmark
✓ Concorrentes citados pelos próprios usuários
Risco
✓ Conversa com a Stone embasada em dado de uso
Decisão informada, custo baixo, prazo de uma semana
conclusion.
O fake door do Link Stone mostrou na prática que discovery não precisa esperar produto pronto. Com um botão, um modal e instrumentação básica, gerei dado quantitativo (funil de cliques) e qualitativo (14 depoimentos) suficiente pra orientar uma decisão de parceria entre duas empresas. Mais do que validar a feature, o trabalho deixou um mapa claro do que o produto real precisa entregar pra ganhar do que já existe no mercado — integração simples, múltiplos métodos, taxas competitivas, segurança equivalente à maquininha e suporte transparente.
key takeaways.
Fake door é o atalho mais honesto. Mede comportamento real, não intenção declarada. Em uma semana você sabe se vale construir — ou se a hipótese morre antes de virar squad.
Quantitativo direciona, qualitativo explica. Saber quantos clicaram me diz se há interesse. Ler o que escreveram me diz por que clicaram — e o que precisa estar no produto pra eles continuarem clicando.
O usuário entrega o benchmark de graça. Quando ele cita Pagar.me, PagSeguro, Cielo, Safra Pay e Picpay sozinho, ele tá te mostrando contra quem você compete e por quais critérios é comparado.
Pesquisa no momento de interesse vale ouro. Modal aberto logo após o clique captura o usuário no pico de atenção. Formulário enviado depois nunca volta com a mesma qualidade.
Suporte é parte do produto. O relato sobre o Picpay mostrou que falha técnica acontece — o que mata a marca é a ausência de resposta. Pra link de pagamento, suporte não é extra; é core.
skills demonstrated.
Design de fake door, definição de hipótese, escolha do método de validação e orquestração de quantitativo + qualitativo
Instrumentação de eventos, leitura de funil (acesso → clique → confirmação) e tradução de número em recomendação
Pesquisa qualitativa embutida no fluxo, síntese de depoimentos em temas e extração de citações representativas
Benchmark indireto via menções dos usuários, conexão entre dor real e oportunidade de produto, recomendação acionável
Documento de achados estruturado pra alimentar discovery interno e negociação com parceiro externo (Stone)
Validação com o menor esforço possível antes de mobilizar squad — design como ferramenta de redução de risco
stack.
thanks for reading.
Quer entender melhor como conduzo discovery? Vamos conversar.
Ver mais casesOutros cases
