The Mom Test: descubra o trabalho antes de construir a solução

Uma equipe apresenta um painel novo a clientes e pergunta se ele parece útil. As pessoas elogiam a tela, sugerem filtros e dizem que gostariam de experimentar. Meses depois, quase ninguém muda o processo atual. A conversa foi simpática, mas misturou cortesia com evidência. The Mom Test, de Rob Fitzpatrick, ensina a reduzir esse erro: perguntar sobre a vida e o trabalho da pessoa, investigar episódios que já aconteceram e buscar fatos que possam mudar uma decisão.

O livro em poucas linhas

O livro é um manual curto de conversas de descoberta para quem precisa entender problemas e decisões de clientes antes de investir em uma solução. A tese não é que clientes mentem deliberadamente; elogios, perguntas hipotéticas e respostas vagas costumam ser contaminados por educação, desejo de ajudar e dificuldade de prever o próprio comportamento. O site oficial apresenta The Mom Test como um guia prático para obter aprendizado útil em conversas com clientes, mesmo quando a ideia ainda não existe (site do livro).

Por que ler: desenvolvedores, designers e lideranças frequentemente chegam à entrevista com a solução na cabeça. O livro oferece um método simples para adiar essa apresentação, ouvir como o trabalho acontece hoje e perceber se existe uma necessidade concreta, recorrente e custosa o bastante para merecer investimento.

As regras que tornam uma pergunta útil

O primeiro princípio é falar sobre a vida da pessoa, não vender sua ideia. “Você usaria uma ferramenta para automatizar relatórios?” pede que a pessoa avalie sua proposta e tente imaginar um futuro. “Como você preparou o último relatório?” convida a reconstruir uma situação específica. A primeira pergunta produz opinião sobre um conceito; a segunda pode revelar fontes de dados, passos, atrasos, exceções e quem recebe o resultado.

O segundo é perguntar sobre fatos passados e concretos, não previsões genéricas. Em vez de “isso costuma acontecer?”, peça um exemplo recente: quando aconteceu, o que foi feito, quem participou, qual foi a consequência e que alternativa foi tentada. O detalhe não garante verdade perfeita — memória e interpretação também falham —, mas reduz o espaço para uma resposta idealizada. Se a pessoa não lembra de nenhum episódio, isso é um dado para a hipótese, não um convite para oferecer pistas até obter um “sim”.

O terceiro é falar menos e ouvir melhor. Uma entrevista não é demonstração de produto, apresentação de roadmap ou debate para convencer alguém. Perguntas curtas deixam a pessoa revelar a ordem e o vocabulário próprios. Quando a equipe preenche silêncios com explicações, passa a testar se a entrevistada consegue ser agradável, não se o problema existe.

Essas regras também mudam o modo de tomar notas. “A gerente enviou três planilhas ao time toda sexta” é um relato observado; “ela precisa de um painel centralizado” é uma interpretação; “a empresa comprará nosso produto” é uma hipótese de negócio. Separar esses níveis protege a equipe de transformar uma ideia conveniente em requisito confirmado. A distinção entre problema, solução e compra é uma das contribuições mais valiosas do livro.

Da conversa ao compromisso

Fitzpatrick recomenda procurar evidências mais fortes que elogios. Uma pessoa pode oferecer tempo para uma reunião de acompanhamento, apresentar alguém que executa o trabalho, compartilhar um exemplo autorizado ou participar de um teste. Cada compromisso tem custo e significado diferentes. A equipe precisa perguntar o que ele demonstra: acesso ao usuário, permissão para observar um processo, interesse em aprender ou intenção real de compra.

Um compromisso também não é uma venda. Quem sofre com o problema pode não controlar orçamento; quem aprova a compra talvez não execute o trabalho. Em empresas, usuários, compradores, segurança, jurídico e operação podem ter objetivos diferentes. Uma conversa útil mapeia essas relações sem fingir que a pessoa entrevistada representa toda a organização. Antes de pedir dados, documentos ou introduções, explique finalidade, uso, retenção e quem poderá consultar o material.

O livro se concentra na qualidade da conversa, não em um roteiro rígido para cada etapa de produto. Uma conversa pode ajudar a descobrir o que acontece e por que; quando o problema já está bem definido, pode também informar uma decisão de validação. O próprio Fitzpatrick alerta que entrevistas não são a ferramenta certa para todo tipo de validação e que problemas ainda vagos geram aprendizado, não comprovação (“Customer convos are the carpenter’s hammer”). Essa ressalva evita transformar o livro em religião de entrevistas.

Um caso aplicado: automatizar relatórios de operação

Considere este cenário hipotético: uma equipe de software pensa em criar um serviço que gera automaticamente o relatório semanal de incidentes. Antes de discutir o painel, conversa com quem prepara e usa esse material. Em vez de perguntar “você gostaria de relatórios automáticos?”, pede que a pessoa descreva a última edição: quais sistemas consultou, como alinhou identificadores, quando percebeu dados ausentes, quem revisou o texto e como uma decisão foi tomada a partir dele.

O relato pode mostrar que montar a tabela leva pouco tempo; o atraso está em receber autorização para acessar logs de dois sistemas. Outra pessoa pode dizer que o relatório raramente influencia uma decisão e que o processo manual já é aceitável. A primeira descoberta sugere uma dependência de acesso e governança, não apenas automação de texto. A segunda questiona se vale construir a feature. Ambas são mais valiosas que uma lista de filtros sugerida por alguém que viu uma tela bonita.

O time separa as notas em fatos relatados, perguntas em aberto e interpretações. Depois compara conversas com pessoas em papéis diferentes e, com consentimento, observa o processo ou examina um exemplo anonimizado. Se a hipótese for que a revisão manual causa atraso, uma próxima etapa pode medir tempos de produção em casos reais. Se a hipótese for que falta uma fonte de dados, pode testar uma integração estreita. Em nenhum dos casos a entrevista, sozinha, estima quantas equipes têm o mesmo problema ou prova que comprarão a solução.

Uma boa pergunta seguinte é o que a pessoa já tentou e quanto aquilo custou em tempo, dinheiro, risco ou retrabalho. “O que acontece se o relatório não ficar pronto?” revela impacto melhor que “isso é importante?”. “Quem precisa aprovar uma mudança nesse fluxo?” expõe restrições de decisão. Perguntas assim ajudam a entender consequências sem colocar palavras na boca do participante. Esse exemplo é uma aplicação editorial, não uma história atribuída ao livro.