O CB Insights publica anualmente um levantamento sobre as razões pelas quais as startups falham. Durante anos, o motivo número um tem sido o mesmo: "ausência de necessidade de mercado." Não execução deficiente. Não falta de financiamento. Não uma equipa fraca. O produto simplesmente não resolvia um problema pelo qual as pessoas se preocupavam o suficiente para mudar o seu comportamento.
Esta estatística é impressionante quando se considera o esforço que envolve construir produtos. As equipas passam meses — por vezes anos — a projetar sistemas, a escrever código, a discutir arquitetura e a aperfeiçoar fluxos. E o motivo mais comum de falha é que ninguém perguntou se tudo isso estava a resolver 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 é apaixonar-se por uma solução antes de compreender profundamente o problema. Isto é quase universal entre fundadores de primeira vez e surpreendentemente comum entre os experientes. O padrão é sempre o mesmo: alguém tem uma ideia, acha-a convincente e começa a construir. O cliente é uma reflexão tardia — alguém a convencer, não a compreender.
O antídoto não é complicado, mas exige disciplina: passe mais tempo no problema do que julga necessário, antes de considerar soluções. Fale com pessoas que têm o problema. Observe como trabalham. Compreenda as soluções alternativas que utilizam hoje e por que razão essas soluções são imperfeitas. Só então tem contexto suficiente para conceber algo que genuinamente se adeque.
O bom desenvolvimento de produto não é uma linha reta — é um ciclo. Cada iteração em torno do ciclo é uma oportunidade de substituir suposições por evidências. As equipas que constroem produtos que as pessoas querem são as que completam este ciclo com rapidez e frequência.
O ciclo não é uma formalidade. Cada etapa tem um output específico que se torna o input da seguinte. Saltar etapas — mais frequentemente saltar diretamente 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 regularidade, não raramente), é intenso (as pessoas sentem-no o suficiente para quererem alívio) e as soluções existentes são genuinamente inadequadas (não apenas ligeiramente diferentes do que 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 soluções alternativas suficientemente boas — o problema pode não valer a pena ser resolvido comercialmente. E se já existem doze ferramentas a fazer o que pretende fazer, 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 extensos e conclusões 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 se constrói.
O objetivo da pesquisa não é confirmar que o problema é real. Já deve acreditar nisso antes de investir fortemente em pesquisa. O objetivo é compreender 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 o descrever e o que "resolvido" significaria para eles.
Uma hipótese é uma previsão específica e falsificável sobre o que acredita ser verdade. Impõe clareza. Se não consegue escrever uma hipótese clara, ainda não compreende o problema suficientemente bem para construir uma solução.
Uma hipótese de produto útil tem três partes:
O sinal é a parte mais importante — e a mais frequentemente omitida. Sem um sinal pré-definido, cada experiência "funcionou de certa forma". As equipas 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 das equipas passa tempo a mais. O objetivo não é construir o produto — é construir o mínimo que lhe dará sinal sobre a hipótese. Estes 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 as equipas imaginam. Pode fazer manualmente o que o software faria, para dez pessoas, para testar se valorizam o resultado? Pode ligar ferramentas existentes e testar o fluxo de trabalho antes de construir nova infraestrutura? Pode esboçar um protótipo e percorrê-lo com cinco utilizadores antes de escrever qualquer código?
A disciplina aqui é perguntar, antes de construir qualquer coisa: "O que estou a tentar aprender?" e "Qual é o mínimo que me permitiria aprendê-lo?" A resposta é quase sempre menor do que a equipa quer construir.
Após o lançamento — seja um protótipo, um piloto manual ou uma funcionalidade implementada — a fase de medição é onde as equipas mais frequentemente se enganam. Perguntam aos utilizadores se gostaram. Os utilizadores dizem que sim. A equipa marca a experiência como validada.
Sentimento não é sinal. O único sinal fiável é o comportamento: as pessoas fizeram o que era esperado? Voltaram? Pagaram? Recomendaram a alguém?
Para medição quantitativa, instrumente antes de lançar. Saiba quais as ações específicas que está a monitorizar. Defina um limiar antecipadamente — "consideraremos isto validado se X% dos utilizadores completarem Y dentro de Z dias". Para medição qualitativa, conduza entrevistas de acompanhamento estruturadas, não inquéritos de satisfação em aberto.
A fase de aprendizagem consiste em atualizar o seu modelo mental do utilizador e do problema, não apenas em decidir o que construir a seguir. As equipas que saltam esta etapa recolhem dados mas não acumulam compreensão. Executam rapidamente mas não melhoram o seu julgamento ao longo do tempo.
Uma boa sessão de aprendizagem pergunta: O que previmos? O que aconteceu de facto? O que a diferença nos diz sobre as nossas suposições? O que é agora a coisa mais importante que não sabemos?
O output da fase de aprendizagem é uma definição de problema mais clara, uma hipótese revista ou — se a experiência claramente falhou — uma decisão de seguir uma direção completamente diferente. Todos estes resultados são valiosos. O pior resultado é a ambiguidade: "aprendemos algumas coisas, mas não temos a certeza do que fazer a seguir." Isso é sinal de que a experiência não foi específica o suficiente.
O desenvolvimento de produto nunca chega a um ponto em que se para de executar este ciclo. As perguntas mudam — numa fase inicial está a validar se o problema é real; mais tarde está a validar se um elemento específico da solução está a funcionar — mas a estrutura é sempre a mesma. Observe, formule hipóteses, teste, aprenda.
As equipas que constroem produtos que as pessoas querem não são as que têm o insight inicial mais inteligente. São as que completam o ciclo mais rapidamente e de forma mais honesta. Velocidade de aprendizagem, não velocidade de entrega, é a vantagem competitiva.