Pesquisa com Usuários que Move o Roadmap, Não Só Confirma Suposições

O PM já havia decidido. O documento de roadmap tinha três sprints planejados, os tickets no Jira estavam rascunhados, e o gerente de engenharia tinha uma estimativa preliminar. Então a área de design disse "provavelmente deveríamos conversar com os usuários primeiro", e um projeto de pesquisa foi agendado.

Cinco chamadas. Cinco clientes escolhidos a dedo pelo CSM porque eram "engajados e dispostos a conversar." Um documento no Notion com dezesseis citações, quatro delas levemente favoráveis, nenhuma surpreendente. O PM leu o resumo, disse "isso confirma o que já pensávamos", e entregou a funcionalidade seis meses depois. A adoção ficou em 11%. A retro pós-lançamento chamou de "problema de comunicação."

Não era um problema de comunicação. Era um problema de pesquisa disfarçado de pesquisa com usuários. O estudo não falhou por causa da metodologia. Falhou porque ninguém estava disposto a deixar que ele mudasse a decisão. Isso não é pesquisa. É ritual.

Se você já esteve nesse ciclo e está cansado, este é o guia. Ele cobre quando usar cada tipo de pesquisa, como dimensionar estudos corretamente, como escrever resultados que sobrevivem a um PM cético, e como escapar da armadilha do "os usuários disseram que querem X", que silenciosamente transforma roadmaps de SMB em prioridades de quem gritou mais alto no último QBR.

Pesquisa generativa versus avaliativa: escolha a ferramenta certa primeiro

A forma mais rápida de desperdiçar um orçamento de pesquisa é escolher a categoria errada. A pesquisa generativa responde "qual problema estamos resolvendo?" A pesquisa avaliativa responde "o que construímos resolve esse problema?" Elas parecem semelhantes por fora (ambas envolvem usuários, ambas produzem citações), mas respondem perguntas em direções opostas e exigem tamanhos de amostra, recrutamento e apoio de stakeholders diferentes.

A maioria das equipes de SaaS B2B recorre à avaliativa quando a pergunta real é generativa. Alguém diz "precisamos testar o novo dashboard", e um teste de usabilidade é agendado antes que alguém tenha perguntado se o dashboard é a coisa certa a construir. Quando o teste acontece, a resposta que ele pode oferecer é estreita: os usuários acham os botões? A pergunta que importava (esse dashboard deveria existir?) já está fora de pauta porque o protótipo já foi construído.

Use a tabela como mecanismo de alinhamento. Antes de especificar um estudo, escreva a decisão que a equipe está prestes a tomar. Se a decisão for "devemos construir isso?", você precisa de pesquisa generativa. Se for "devemos entregar a versão que construímos?", precisa de avaliativa. Se for "devemos iterar na versão que entregamos?", precisa de contínua. A maioria dos pedidos de "precisamos de pesquisa com usuários" é, na verdade, um desses três, e quem faz o pedido geralmente não sabe qual.

O teste de usabilidade com 5 usuários: a regra real de Nielsen, não o meme

O artigo de Jakob Nielsen de 1993 concluiu que 5 usuários são suficientes para identificar cerca de 85% dos problemas de usabilidade num estudo. Esse número foi comprimido em "sempre teste com 5" e tem sido citado por pessoas que não leram o artigo há trinta anos. A regra dos 5 usuários se aplica em condições específicas, e essas condições são mais restritas do que a maioria das equipes de produto age.

A regra se aplica quando você tem um segmento de usuário, fazendo uma tarefa, em uma interface. Um novo usuário se cadastrando. Um administrador configurando uma única opção. Um usuário final registrando um relatório de despesas. Dentro desse escopo, a matemática se sustenta: no quinto usuário você já viu a maioria dos problemas, e no oitavo você está vendo repetições.

A regra se rompe no momento em que qualquer uma dessas condições se rompe:

• Múltiplos perfis de usuário. Se o seu produto B2B tem administradores, usuários finais e TI, você precisa de 5 de cada. Isso são 15 sessões, não 5. Administradores se confundem com coisas que usuários finais nunca veem.
• Problemas conceituais, não de interação. A regra dos 5 usuários identifica "não encontrei o botão." Ela não identifica "não entendo por que essa funcionalidade existe." A incompreensão conceitual aparece com baixa frequência por usuário, mas importa mais: você precisa de 12 a 15 para identificá-la com confiança.
• Fluxos de trabalho ramificados. Um fluxo de cadastro linear funciona bem com 5. Um fluxo com 6 ramificações condicionais precisa de cobertura de amostra em cada ramificação. Você pode ter 5 usuários e ver 4 deles nunca chegarem à ramificação onde está o problema.
• Comparação entre segmentos. Se a pergunta é "isso funciona para SMB e enterprise?", você precisa de um estudo dimensionado para comparação entre segmentos, o que exige de 8 a 12 por segmento no mínimo.

Quando um stakeholder diz "vamos fazer só com 5", pergunte qual perfil, qual tarefa e qual decisão o resultado vai embasar. Se a decisão for "entregar ou não entregar para toda a nossa base de usuários", 5 não é suficiente. Se for "esse fluxo de cadastro está quebrado para novos usuários SMB especificamente", 5 pode ser suficiente.

Testes não moderados: Maze, UserTesting, Lyssna e o que escondem

Plataformas não moderadas mudaram a velocidade com que um designer pode conduzir um estudo avaliativo. Maze, UserTesting e Lyssna permitem que você envie um protótipo para 50 testadores e tenha resultados até sexta-feira. A velocidade é real. Assim como o custo.

O teste não moderado vence em três coisas: velocidade (retorno em 24 a 72 horas), alcance (você consegue recrutar painéis que nunca obteria numa chamada moderada) e comparação quantitativa (A/B de dois designs em escala). Para tarefas claras e de baixo contexto voltadas a um público amplo, é difícil superar.

Ele perde em três coisas, e produtos B2B enfrentam todas:

1. Fluxos de trabalho complexos. Estudos moderados permitem que você observe um usuário pensar em voz alta, pergunte "por que você clicou aí?" e investigue quando ele trava. Não moderado, você tem um vídeo de alguém clicando na coisa errada em silêncio e seguindo em frente. Você aprende que ele falhou. Não aprende por quê.
2. Interfaces cheias de jargão. Produtos B2B estão repletos de termos que os usuários entendem apenas em contexto. Um testador não moderado de um painel vai chutar, falhar e avaliar o teste como "fácil" porque não sabe o que não sabe. O teste produz dados de aparência limpa e lacunas silenciosas de compreensão.
3. A pergunta do "por quê". Qualquer coisa que exija entender intenção, motivação ou raciocínio sobre escolhas precisa de um moderador. Ferramentas não moderadas melhoraram em follow-ups, mas uma pergunta gravada de acompanhamento recebe uma resposta ensaiada. Um moderador ao vivo recebe a resposta real.

Taxas reais de conclusão confirmam isso. Para tarefas voltadas ao consumidor, testes não moderados B2C têm 80 a 95% de conclusão. Para fluxos de SaaS B2B, espere 60 a 75%. Essa diferença importa no dimensionamento: um estudo que precisa de n=20 sessões válidas num fluxo B2B precisa de 28 a 32 inícios para atingir isso. Planeje para o abandono.

A armadilha em que a maioria das equipes cai: escolhem não moderado porque é rápido, depois tomam decisões que precisavam de profundidade moderada. O Maze te diz a taxa de cliques. Não te diz que 4 dos 12 usuários SMB não tinham ideia do que "tenant" significava no painel de configurações de TI e simplesmente chutaram a resposta certa.

A armadilha do "a pesquisa mostrou que os usuários querem X"

É aqui que a maioria das pesquisas B2B morre. Viés de seleção, viés de recência e viés de confirmação se somam, e um estudo com oito participantes se torna um roadmap construído para um público que você não tem.

O viés de seleção vem de quem responde à chamada. O customer success escolhe os clientes engajados porque eles respondem e-mail. Clientes engajados têm mais chances de ser enterprise, de ser administradores, e de querer funcionalidades que tornem o fluxo de trabalho existente mais poderoso. Recrute 8 deles e você vai ouvir uma mensagem unificada: mais permissões, mais papéis, mais controles enterprise. Se o seu negócio tem 70% de SMB por ARR, você acabou de conduzir um estudo voltado para os 30% que não precisavam de ajuda de qualquer forma.

O viés de recência vem do último cliente barulhento. Aconteceu um QBR na semana passada, o VP ouviu de uma conta de R$ 2 milhões, e "os usuários querem SSO" entrou no documento de planejamento como uma citação sem n associado. Quando a pesquisa é recrutada, a pergunta feita não é "os usuários querem SSO?", mas "o quanto os usuários querem SSO?", e o recrutamento seleciona usuários que achariam o SSO valioso.

O viés de confirmação está nas próprias perguntas. "Seria útil se você pudesse exportar relatórios em massa?" recebe um sim de quase todo mundo. "Como você lida com relatórios hoje?" te diz se a exportação em massa é um gargalo real ou um bom-ter enterrado sob as dez coisas com que eles realmente lutam diariamente.

Um exemplo real, anonimizado: um estudo com 8 administradores de 3 contas enterprise produziu o título "os usuários querem SSO." O roadmap mudou para um trimestre de trabalho em SSO e SCIM. Seis meses depois, o churn de SMB subiu porque o time responsável pela ativação tinha sido deslocado para o projeto de SSO. Os 8 administradores estavam satisfeitos. As 1.400 contas SMB que nunca passaram da segunda semana de ativação não foram consultadas. O estudo não estava errado sobre os 8 administradores. Estava errado em ser tratado como um estudo sobre "os usuários."

A defesa é procedimental. Antes de recrutar, escreva: sobre qual segmento é este estudo, qual proporção da receita esse segmento representa, e quais decisões este estudo pode legitimamente embasar? Se a resposta à terceira pergunta for "apenas decisões sobre este segmento", coloque isso no slide de capa da apresentação. Os stakeholders vão supergeneralizar a menos que você torne o escopo explícito.

Como escrever um resultado que muda uma decisão

A maioria dos resultados de pesquisa morre no slide em que é escrita. "Os usuários ficaram confusos com o botão de exportar" perde todo argumento porque não tem n, não tem segmento, não tem especificidade e não tem recomendação. Pode ser verdadeiro e ainda assim ser ignorado.

Um resultado que sobrevive a um PM cético tem cinco partes:

1. Observação: o que aconteceu, comportamentalmente
2. Evidência: n, segmento, tarefa, tipo de estudo
3. Inferência: o que isso provavelmente significa
4. Recomendação: o que fazer a respeito
5. Nível de confiança: o quanto você tem certeza

Compare:

Ruim: Os usuários ficaram confusos com o botão de exportar.

versus:

Bom: 6 de 8 administradores (n=8, tier enterprise, teste de usabilidade moderado, tarefa de exportação de relatório semanal) abandonaram o fluxo de exportação na etapa de seleção de formato. Três disseram em voz alta que não sabiam o que "delimitado" significava; dois clicaram no formato errado sem perceber. Inferência: o seletor de formato é uma barreira de compreensão, não de descoberta. Recomendação: padronizar para CSV com uma opção "mais formatos", entregar sob uma flag e medir o delta de abandono. Confiança: média. A amostra é pequena e apenas enterprise; um acompanhamento não moderado de 2 semanas com SMB confirmaria.

O segundo vence porque diz ao PM exatamente o que é conhecido, o que é inferido e qual ação decorre. O PM cético pode questionar qualquer uma das cinco partes, mas precisa questionar uma parte específica. Ele não pode simplesmente dizer "amostra pequena" e sair, porque a recomendação já considera isso com um plano de acompanhamento.

Um segundo padrão que ajuda: apresente os resultados pela decisão que afetam, não pela metodologia. "Precisamos mudar o padrão de exportação" impacta. "Conduzimos um estudo moderado com 8 administradores" faz o público dormir antes de a recomendação chegar.

Apresentando pesquisa para um PM cético

Uma apresentação de pesquisa de 23 slides entregue a um PM no standup não vai mudar um roadmap. Vai ser reconhecida, arquivada e ignorada. PMs são tomadores de decisão sob pressão de tempo. A pesquisa precisa encontrá-los onde estão.

Cinco coisas que realmente funcionam:

Comece pela decisão. Abra com "este estudo informa se entregamos o novo fluxo de exportação como está, entregamos com uma mudança, ou reconstruímos." Depois a metodologia, depois os resultados. O PM agora está lendo para tomar uma decisão, não para avaliar pesquisa.

Antecipe as objeções. Antes de apresentar, escreva as três objeções que você espera ("amostra pequena", "esses não são o nosso ICP", "já decidimos"). Aborde cada uma na apresentação antes de ser levantada. Dizer "n=8 é pequeno para afirmações entre segmentos, por isso este estudo fala apenas sobre administradores enterprise fazendo a tarefa de exportação" desativa o ataque de amostra pequena antes de chegar.

Traga o clipe bruto, não o resumo. Um vídeo de 45 segundos de um administrador olhando fixamente para o dropdown de formatos e dizendo "não faço ideia do que nenhuma dessas opções significa" vale quinze slides de citações. PMs confiam mais nos próprios olhos do que na sua síntese. Ferramentas como Dovetail e UserTesting facilitam muito a extração de clipes.

Ancore numa métrica que o PM já se importa. Se o PM é responsável pela ativação, enquadre os resultados em torno do impacto na ativação. Se é responsável pela retenção, enquadre pela retenção. "Essa fricção de exportação afeta a ativação na semana 2 de novos administradores" supera "essa fricção de exportação é um problema de UX" sempre.

Nomeie o custo de ignorar. "Se entregarmos como está, esperamos que cerca de 30 a 40% dos novos administradores abandonem a tarefa de exportação no primeiro mês, com base na taxa de abandono da sessão moderada" dá ao PM algo para pesar em relação à data de entrega.

Uma regra prática: se um resultado de pesquisa não cabe em um único slide com a decisão, evidência, recomendação e uma citação, ainda não é um resultado. É uma anotação de caderno. Continue trabalhando nele antes de levá-lo para a sala.

O Que Fazer Esta Semana

Escolha uma decisão de roadmap que se aproxima. Escreva o que está sendo decidido, quem está decidindo e o que precisaria ser verdade para a decisão mudar. Depois pergunte: a equipe tem evidências para o que precisaria ser verdade? Se não, esse é o estudo. Se sim, a pesquisa já foi feita e o próximo passo é torná-la visível.

Pesquisa que move o roadmap é pesquisa voltada para uma decisão específica, dimensionada para a afirmação que precisa sustentar, e apresentada de uma forma que um PM ocupado possa agir. Todo o resto é um workshop. Workshops são válidos. Só não os confunda com estudos.

Saiba Mais

• Crítica de Design que Melhora o Trabalho, Não o Humor do Designer
• Trabalhando com PMs que Acham que Design É Decoração
• Velocidade de Entrega para Designers
• Modelo de Descrição de Cargo para Product Designer