Validação de ideia vs validação de produto

Validação de ideia: o quê você testa

Aqui o objeto é a hipótese de valor do problema: existe dor relevante, para quem, com que frequência e urgência? A "ideia" pode ser só uma frase — "Pequenos lojistas perdem vendas por falta de controle de estoque multicanal" — sem especificar stack, pixels ou biblioteca de UI. Evidências típicas: entrevistas sobre comportamento passado, dados de mercado, lista de espera com tráfego qualificado, carta de intenção, piloto pago com entregável manual.

Se a ideia não passa nesta fase, qualquer produto construído em cima será remendo. Por isso validação de ideia é mais barata: você desliga caminhos com conversa e experimentos de mensagem, não com microserviço.

Validação de produto: o quê você testa

Depois que o problema está sólido, validação de produto testa a solução concreta: fluxos, usabilidade, performance, integrações, preço percebido versus valor entregue, retenção após onboarding. Métricas entram com força: ativação, uso recorrente, NPS contextual, churn por motivo, tempo até valor. A/B test, cohortes e suporte nível 2 fazem parte do jogo.

Você pode ter validado a ideia ("sim, dói") e ainda falhar na validação de produto ("não entendi o painel", "não confio na migração", "falta integração X"). São falhas diferentes e exigem respostas diferentes no roadmap.

Ordem e sobreposição

Na teoria, ideia primeiro, produto depois. Na prática, há loop: um protótipo clicável pode revelar que o problema que você pensou que era central é secundário. O erro é tratar demo bonito como substituto de evidência de problema — ou entrevistar só sobre features sem nunca cravar se a pessoa pagaria ou mudaria de processo.

Regra prática: se você não consegue explicar em duas frases por que essa persona compraria agora, volte à validação de ideia antes de escalar time de engenharia.

Tabela mental rápida

• Ideia: dor, mercado, disposição para mudança, concorrência substituta.
• Produto: solução, UX, confiabilidade, preço, retenção.