O CB Insights publica anualmente um levantamento sobre por que startups falham. Por anos, o motivo número um tem sido o mesmo: "ausência de demanda de mercado." Não execução ruim. Não falta de dinheiro. Não um time ruim. O produto simplesmente não resolvia um problema pelo qual as pessoas se importavam o suficiente para mudar o seu comportamento.
Essa estatística é impressionante quando você considera quanto esforço vai para construir produtos. Times passam meses — às vezes anos — projetando sistemas, escrevendo código, discutindo sobre arquitetura e aperfeiçoando fluxos. E o motivo mais comum de fracasso é que ninguém perguntou se tudo isso estava resolvendo um problema real.
Construir produtos que as pessoas realmente querem não é um talento. É uma disciplina. Tem um método, e esse método pode ser aprendido.
O erro de produto mais comum é se apaixonar por uma solução antes de entender profundamente o problema. Isso é quase universal entre fundadores de primeira viagem e surpreendentemente comum entre os experientes. O padrão é sempre o mesmo: alguém tem uma ideia, acha ela convincente e começa a construir. O cliente é uma reflexão tardia — alguém a ser convencido, não compreendido.
O antídoto não é complicado, mas exige disciplina: passe mais tempo no problema do que você acha necessário, antes de considerar soluções. Fale com pessoas que têm o problema. Observe como elas trabalham. Entenda os workarounds que usam hoje e por que esses workarounds são imperfeitos. Só então você tem contexto suficiente para projetar algo que realmente se encaixe.
O bom desenvolvimento de produto não é uma linha reta — é um loop. Cada iteração ao redor do loop é uma oportunidade de substituir suposições por evidências. Os times que constroem produtos que as pessoas querem são os que completam esse loop com rapidez e frequência.
O loop não é uma formalidade. Cada etapa tem um output específico que se torna o input da próxima. Pular etapas — mais comumente pular direto do Problema para Construir — é o que produz produtos que erram o alvo.
Nem todos os problemas valem a pena ser resolvidos. Um bom problema de produto tem três qualidades: é frequente (afeta as pessoas com frequência, não raramente), é intenso (as pessoas sentem o suficiente para querer alívio) e as soluções existentes são genuinamente inadequadas (não apenas ligeiramente diferentes do que você construiria).
O erro é otimizar para a primeira qualidade e ignorar as outras duas. "As pessoas perdem tempo em reuniões" é frequente. Mas se a dor é baixa — se as pessoas encontraram workarounds suficientemente bons — o problema pode não valer a pena ser resolvido comercialmente. E se já existem doze ferramentas fazendo o que você quer fazer, você precisa de uma razão muito específica para que a sua seja escolhida.
A pesquisa tem má reputação nos círculos de produto — está associada a consultorias lentas, relatórios grossos e descobertas que ninguém lê. Isso é uma falha de execução, não da prática. Uma boa pesquisa de produto é rápida, específica e muda o que você constrói.
O objetivo da pesquisa não é confirmar que o problema é real. Você já deve acreditar nisso antes de investir pesado em pesquisa. O objetivo é entender o problema profundamente o suficiente para saber como é uma boa solução: quem especificamente tem o problema, em que contexto, o que já tentaram, que palavras usam para descrevê-lo e o que "resolvido" significaria para eles.
Uma hipótese é uma previsão específica e falsificável sobre o que você acredita ser verdade. Ela força a clareza. Se você não consegue escrever uma hipótese clara, ainda não entende o problema bem o suficiente para construir uma solução.
Uma hipótese de produto útil tem três partes:
O sinal é a parte mais importante — e a mais comumente omitida. Sem um sinal pré-definido, todo experimento "funcionou de certa forma". Os times encontram maneiras de interpretar dados ambíguos favoravelmente. Uma hipótese sem condição de falsificação é apenas um desejo.
A fase de construção é onde a maioria dos times passa tempo demais. O objetivo não é construir o produto — é construir a coisa mínima que vai te dar sinal sobre a hipótese. Esses são objetivos diferentes e produzem outputs muito diferentes.
Para a maioria das hipóteses em fase inicial, o mínimo é muito menor do que os times imaginam. Você pode fazer manualmente o que o software faria, para dez pessoas, para testar se elas valorizam o resultado? Você pode conectar ferramentas existentes e testar o fluxo de trabalho antes de construir nova infraestrutura? Você pode esboçar um protótipo e percorrê-lo com cinco usuários antes de escrever qualquer código?
A disciplina aqui é perguntar, antes de construir qualquer coisa: "O que estou tentando aprender?" e "Qual é a coisa mínima que me permitiria aprender isso?" A resposta quase sempre é menor do que o time quer construir.
Após o lançamento — seja um protótipo, um piloto manual ou uma funcionalidade implantada — a fase de medição é onde os times mais comumente se enganam. Eles perguntam aos usuários se gostaram. Os usuários dizem que sim. O time marca o experimento como validado.
Sentimento não é sinal. O único sinal confiável é o comportamento: as pessoas fizeram o que era esperado? Voltaram? Pagaram? Indicaram para alguém?
Para medição quantitativa, instrumente antes de lançar. Saiba quais ações específicas você está rastreando. Defina um limite antecipadamente — "vamos considerar isso validado se X% dos usuários completarem Y dentro de Z dias". Para medição qualitativa, conduza entrevistas de acompanhamento estruturadas, não pesquisas abertas de satisfação.
A fase de aprendizado é sobre atualizar seu modelo mental do usuário e do problema, não apenas decidir o que construir a seguir. Times que pulam essa etapa coletam dados mas não acumulam compreensão. Executam rapidamente mas não melhoram seu julgamento ao longo do tempo.
Uma boa sessão de aprendizado pergunta: O que previmos? O que realmente aconteceu? O que a lacuna nos diz sobre nossas suposições? O que agora é a coisa mais importante que não sabemos?
O output da fase de aprendizado é uma definição de problema mais clara, uma hipótese revisada ou — se o experimento claramente falhou — uma decisão de seguir uma direção completamente diferente. Todos esses resultados são valiosos. O pior resultado é a ambiguidade: "aprendemos algumas coisas, mas não temos certeza do que fazer a seguir." Isso é um sinal de que o experimento não foi específico o suficiente.
O desenvolvimento de produto nunca chega a um estágio em que você para de rodar esse loop. As perguntas mudam — no início você está validando se o problema é real; mais tarde você está validando se um elemento específico da solução está funcionando — mas a estrutura é sempre a mesma. Observe, formule hipóteses, teste, aprenda.
Os times que constroem produtos que as pessoas querem não são os que têm o insight inicial mais inteligente. São os que completam o loop mais rápido e de forma mais honesta. Velocidade de aprendizado, não velocidade de entrega, é a vantagem competitiva.