Product Discovery & User Research

O Problema

A maioria das falhas de produto são falhas de discovery

A base de dados de post-mortems da CB Insights mostra que 42% das startups falham porque não havia necessidade de mercado. Não má execução. Problema errado. A product discovery existe para fechar esta lacuna: perceber o problema a fundo antes de se comprometer com uma solução.

Abordagem build-first

O PM escreve specs com base em pedidos de stakeholders
A equipa constrói durante 3 meses sem input de utilizadores
O lançamento revela que os utilizadores queriam outra coisa
Os pivots obrigam a deitar fora trabalho concluído
A discovery acontece depois do lançamento, de forma cara

A equipa esteve ocupada. O produto estava errado. O custo foram meses de engenharia desperdiçada.

Abordagem discovery-first

O PM entrevista 10 utilizadores antes de escrever uma spec
As hipóteses são testadas com protótipos na semana 2
O lançamento valida pressupostos feitos com dados reais
Os pivots acontecem no papel, não em código de produção
O esforço de engenharia é aplicado a problemas validados

A equipa avançou mais devagar no início. O produto estava certo. O custo de aprender foram entrevistas e protótipos.

O Processo

Como funciona a discovery

A product discovery é um processo contínuo, não uma fase que acaba antes de o desenvolvimento começar. O framework “Continuous Discovery Habits” de Teresa Torres sugere pontos de contacto semanais com utilizadores, não sprints de research trimestrais.

01

Define o espaço do problema

Começa pelo Opportunity Space: que outcomes precisa o negócio? Que outcomes precisam os utilizadores? Onde é que estes se cruzam? Usa a Opportunity Solution Tree (OST) para mapear o espaço do problema antes de saltar para soluções. Um problema bem definido já contém a maior parte da solução.

02

Recruta e entrevista utilizadores

5–8 entrevistas chegam para identificar temas recorrentes (ponto de saturação). Recruta participantes que correspondam à tua persona-alvo, não colegas, amigos, ou os utilizadores mais vocais. Foca as entrevistas em comportamento e contexto (“conta-me sobre a última vez que…”), não em opiniões sobre a tua solução (“usarias uma funcionalidade que…”).

03

Sintetiza padrões em insights

Uma observação é “3 utilizadores mencionaram alternar entre duas apps”. Um insight é “os utilizadores precisam de um workflow unificado porque o context-switching parte a concentração durante tarefas sensíveis ao tempo”. Os insights são generalizáveis, acionáveis e ancorados em evidência; conduzem decisões, não apenas acrescentam cor.

04

Gera e prioriza hipóteses

A partir dos insights, gera várias hipóteses de solução, não uma. Para cada hipótese, escreve um pressuposto testável: “Acreditamos que [tipo de utilizador] vai [fazer/sentir isto] porque [insight]. Saberemos que é verdade quando [outcome mensurável].” Prioriza por impacto potencial × confiança × esforço de testar.

05

Testa com o artefacto mais barato possível

O objetivo é invalidar pressupostos de forma barata. Um protótipo em papel leva 2 horas; uma funcionalidade em código leva 2 semanas. Usa a fidelidade mínima necessária para gerar uma decisão. As landing pages testam procura. Os protótipos clicáveis testam usabilidade. Os testes Wizard-of-Oz testam viabilidade. Constrói só quando uma hipótese sobrevive a testes suficientes.

Entrevistas a Utilizadores

Como conduzir entrevistas que de facto fazem emergir a verdade

Más entrevistas confirmam o que a equipa já acredita. Boas entrevistas revelam o que a equipa não sabia que não sabia. A diferença está quase toda nas perguntas.

Antes da entrevista

Prepara, mas mantém-te flexível. Escreve um guião de discussão com 5–8 perguntas abertas, ordenadas do amplo (conta-me sobre o teu workflow) ao específico (o que acontece quando o X falha). Não partilhes nenhum brief com antecedência; queres respostas não enviesadas. Grava com consentimento. Tem alguém a tirar notas para o entrevistador se poder focar em ouvir, não em transcrever.

Durante a entrevista

Ouve mais do que falas. Pergunta sobre comportamento passado específico, não sobre comportamento futuro hipotético. “Usarias isto?” não te diz nada. “Leva-me pela última vez que tentaste resolver este problema” diz-te tudo. Segue os fios: quando surge algo interessante, pergunta “conta-me mais sobre isso”. O silêncio é produtivo. Não o preenchas.

Depois da entrevista

Faz o debrief de imediato, sintetiza ao longo das sessões. Escreve um debrief de 3 pontos nos 30 minutos seguintes a cada entrevista: a coisa mais surpreendente, a mais comum, e o que testarias a seguir. Depois de todas as entrevistas, faz um affinity map das observações, agrupando temas relacionados e elevando os grupos a insights. Evita a interpretação até teres pelo menos 5 sessões.

Modelos de Utilizador

Personas e Empathy Maps

As personas e os empathy maps são ferramentas de comunicação; tornam as descobertas de research memoráveis e acionáveis para equipas que não conduziram a research elas próprias. O perigo é criá-las a partir de pressupostos em vez de evidência.

Personas baseadas em evidência

Uma persona é um compósito de utilizadores reais, não uma personagem inventada. Deve incluir: dados demográficos (só os relevantes), objetivos principais, frustrações-chave, ferramentas e workflows atuais, e uma citação que capte a sua mentalidade. Personas construídas a partir de entrevistas conduzem decisões; personas construídas a partir de pressupostos apanham pó.

Empathy Map

Mapeia o que um utilizador pensa, sente, diz e faz, em quatro quadrantes. O poder está nas lacunas: o que diz (“isto está bem”) vs. o que sente (frustrado mas educado). Os empathy maps são construídos colaborativamente em workshops com post-its; o processo de os construir é tão valioso como o artefacto.

Customer Journey Map

Traça a experiência do utilizador ao longo de todos os touchpoints, da notoriedade à compra, à advocacia. Cada fase mostra o que o utilizador está a fazer, a pensar e a sentir, mais os seus pain points e oportunidades. Os journey maps revelam os momentos em que a experiência se parte e onde a intervenção tem mais leverage.

JTBD

Jobs-to-be-Done: uma forma diferente de ver os utilizadores

Jobs-to-be-Done (JTBD), desenvolvido por Clayton Christensen, reformula a user research de “quem é o utilizador?” para “que job é que o utilizador está a contratar este produto para fazer?” Explica por que as pessoas trocam de produto, o que as torna fiéis, e de onde vem a verdadeira concorrência.

O exemplo clássico: “As pessoas não querem um berbequim de meia polegada. Querem um furo de meia polegada.” E muitas vezes nem querem o furo; querem uma prateleira na parede. E não querem a prateleira; querem os livros organizados. O JTBD pergunta: qual é o outcome que o utilizador está, em última instância, a tentar alcançar?

Jobs funcionais

A tarefa prática a concluir. O job de superfície: “Enviar dinheiro à minha família noutro país depressa.” “Encontrar um canalizador de confiança na minha zona antes de sábado.” “Criar uma fatura profissional sem formação em contabilidade.” Os jobs funcionais definem o âmbito mínimo viável de uma solução.

Jobs emocionais

Como o utilizador quer sentir-se. O mesmo utilizador que contrata o Airbnb por “um sítio para dormir” também o contrata por “sentir-se um local” e “não se sentir um turista num hotel”. Os jobs emocionais impulsionam a diferenciação: dois produtos podem cumprir o mesmo job funcional enquanto falham completamente no emocional.

Jobs sociais

Como o utilizador quer ser percebido. Usar um produto premium sinaliza estatuto. Usar uma marca sustentável sinaliza valores. Usar a ferramenta “standard da indústria” sinaliza profissionalismo. Os jobs sociais explicam por que produtos “suficientemente bons” são deslocados por outros mais caros com funcionalidade equivalente: o sinal social é o produto.

Validação

Validar hipóteses antes de construir

A validação é a disciplina de estar errado de forma barata. Cada hipótese tem um pressuposto por baixo, e os pressupostos podem ser testados sem código, sem design, e muitas vezes sem sequer dizer ao utilizador o que estás a construir.

Validação qualitativa

Testes de conceito de 5 minutos com protótipos em papel
Fake door tests (botão que ainda não existe)
Wizard-of-Oz: um humano executa a “IA” manualmente
Concierge MVP: entregar o serviço manualmente primeiro
Entrevistas a stakeholders para stress-test aos pressupostos

Rápida, barata, direcional. Diz-te se estás a resolver o problema certo. Amostra pequena, não estatisticamente representativa.

Validação quantitativa

Landing page com inscrição em waitlist (sinal de procura)
A/B test de propostas de valor na homepage
Smoke test: anúncio pago para medir click-through rates
Tracking de cohort beta (ativação, retenção)
Inquérito para dimensionar o segmento-alvo

Mais lenta, exige mais setup, estatisticamente significativa. Diz-te quantas pessoas têm o problema, não apenas se ele existe.

Armadilhas

Erros de discovery que levam a construir a coisa errada

Atenção a estes

Perguntar sobre comportamento futuro hipotético: “Usarias uma funcionalidade que…?” obtém sempre um “sim” de utilizadores educados que não te querem magoar. O comportamento passado é o único preditor fiável do comportamento futuro. Pergunta o que fizeram, não o que fariam.

Falar só com power users: Os teus utilizadores mais envolvidos são atípicos. Já se adaptaram às manias do teu produto, encontraram workarounds para fluxos partidos, e perdoaram erros que fariam um novo utilizador desistir. Faz research à tua persona-alvo, o utilizador que estás a tentar adquirir, não ao utilizador que já está preso a ti.

Fazer research para justificar, não para descobrir: A forma mais perigosa de user research é fazer perguntas desenhadas para validar uma decisão já tomada. Isto produz confirmation bias à escala. Se a equipa entra na research a saber o que quer ouvir, vai ouvi-lo. Enquadra as entrevistas em torno de compreender, não de validar.

Parar a discovery depois do lançamento: A discovery é contínua. O lançamento não é o fim. É o início de um ciclo de feedback. O comportamento do utilizador pós-lançamento é a fonte de insight mais rica que alguma vez vais ter. Equipas que param de fazer research depois do lançamento perdem situational awareness e voltam a construir com base em opinião interna.

Conclusão

Os melhores PMs são aprendizes obsessivos

Fala com utilizadores todas as semanas

Não trimestralmente. Não antes do lançamento. Todas as semanas. Mesmo uma entrevista de 30 minutos por semana acumula até um nível de intuição de utilizador que nenhuma quantidade de analytics consegue replicar. O objetivo é nunca ser surpreendido pelo que os utilizadores fazem com o teu produto.

Apaixona-te pelo problema

O apego às soluções é a causa-raiz da maioria das falhas de produto. Equipas que se apaixonam pela sua solução ignoram a evidência de que o problema é diferente. Equipas que se apaixonam pelo problema são livres de descobrir a solução que de facto funciona.

Testa barato, constrói confiante

Cada semana de tempo de engenharia gasta numa hipótese não validada é uma semana de risco. Prototipa, testa e invalida hipóteses na fidelidade mais baixa possível. Quando os pressupostos sobrevivem aos testes, constrói com confiança, não com esperança.

ProductDiscovery &User Research