O Dado Mínimo Viável não precisa substituir o protótipo. Pode ser o que transforma uma primeira versão funcional em aprendizado.
Um vídeo de Bruno Faggion sobre “o fim do MVP e a nova era do MVD” provocou uma boa discussão por aqui.
Na LAB³, quase tudo começa com um protótipo. É quando a ideia deixa o campo da intenção e encontra o mundo. Por isso, a proposta de substituir o Mínimo Produto Viável (MVP) pelo Mínimo Dado Viável (MVD) nos pareceu, num primeiro momento, uma inversão do processo.
Afinal, como definir a viabilidade do dado antes de existir uma experiência capaz de produzi-lo?
Olhando melhor, porém, talvez o problema não esteja no MVD, mas no que passamos a chamar de MVP. O conceito foi reduzido a uma versão menor, mais barata e incompleta de um produto. Só que o “mínimo” nunca deveria significar apenas menos funcionalidades. O MVP existe para iniciar um ciclo de aprendizado.
O produto mínimo não é o destino. É o instrumento do experimento.
Isso o aproxima do protótipo, embora não sejam exatamente a mesma coisa. Um protótipo pode testar uma interface, uma dinâmica ou uma tecnologia. Um MVP precisa entregar valor suficiente para que alguém o use de verdade. Nos dois casos, há uma pergunta que vem antes de qualquer métrica: o que queremos aprender?
Sem essa pergunta, acessos, cliques, cadastros e tempo de permanência podem produzir um painel bonito e nenhuma decisão útil.
Foi o que aprendemos em projetos da LAB³ que precisaram entrar em operação ainda durante o programa. Quando uma plataforma registra acessos, avanços, conclusões e respostas, ela não está apenas funcionando. Está revelando onde as pessoas seguem, onde param e o que precisa ser revisto.
Nesse caso, o dado não substitui o protótipo. O dado nasce dele.
Mas o contrário também é verdadeiro: construir primeiro e pensar depois no que será medido pode tornar o experimento inútil. Um sistema pode funcionar perfeitamente e ainda assim não registrar o que precisamos para entender seu uso.
É nesse ponto que o MVD faz sentido. Não como substituto do MVP, mas como parte do mesmo desenho. O protótipo materializa a hipótese. O MVP oferece valor suficiente para testá-la. O MVD define a evidência mínima necessária para decidir o próximo passo.
Há alguns anos, saber informática era um diferencial no currículo. Hoje, é quase uma competência implícita. Nas campanhas digitais aconteceu algo parecido: mesmo uma ação orgânica já nasce acompanhada de alguma expectativa de alcance, interação e conversão. A régua subiu.
Só que existe um risco nessa evolução. Se passarmos a exigir dados consistentes antes de permitir o primeiro teste, criaremos um paradoxo: pedir antes do protótipo a evidência que o próprio protótipo deveria produzir.
Subir a régua não deveria significar retirar os primeiros degraus.
O que precisa existir antes da construção não é o dado pronto, mas uma hipótese observável. Precisamos saber o que estamos testando, qual comportamento merece atenção, o que será registrado e que decisão poderá ser tomada a partir disso. O planejamento vem antes. A evidência vem com o uso.
Por isso, não vemos razão para declarar a morte do MVP. O MVD é valioso quando nos obriga a criar protótipos observáveis desde o início, capazes de produzir evidência útil sem exigir uma estrutura desproporcional ao estágio da ideia.
Talvez a unidade mínima de inovação já não seja apenas um produto. É um pequeno sistema de aprendizagem: uma hipótese clara, uma experiência real, evidência suficiente e uma decisão possível.
O protótipo continua sendo o primeiro passo prático. O MVD impede que esse passo seja dado no escuro.
No fim, a pergunta mais útil não é “MVP ou MVD?”. É outra:
Qual é a menor experiência que podemos colocar no mundo — e qual é a menor evidência de que precisamos para decidir o que fazer depois?
Referências: