O fim do MVP? Como a IA muda o ciclo de desenvolvimento de produto

O ponto de partida desta conversa foi o texto "[The Product Life Cycle is Broken](https://blog.ravi-mehta.com/p/master-prototyping)", do Ravi (ex-diretor da Meta, ex-CPO do Tinder, instrutor do Reforge). A tese provocativa: > o processo de desenvolvimento de produto nunca foi feito para construir o melhor produto, e sim para **impedir erros caros**. Mas quando software deixa de ser a parte mais cara do processo, o que sobra do ciclo? [](https://youtu.be/OrFrhWqFRgg) ## Sistema de produto, não ciclo de produto A primeira provocação que joguei na mesa: mais do que defender ou enterrar o ciclo de produto, faz sentido pensar em **sistema de produto**. Quando você usa o ciclo como verdade absoluta, fica de mãos atadas: *"tem essa forma, eu tenho que encaixar meu processo nisso".* Quando você adapta, pula etapa quando faz sentido, retroalimenta uma fase com o output de outra, aí sim o processo serve ao produto. > "As perguntas que a gente quer responder continuam as mesmas: o que os usuários realmente querem, qual a melhor maneira de servi-los, como criar um business sustentável em cima disso…" A diferença prática é **maturidade**. Times mais maduros conseguem absorver mais facilmente uma nova maneira de criar produto, qualquer que seja ela. Quem aprendeu o passo a passo como dogma trava na primeira mudança de paradigma. E vale o disclaimer: empresas não-AI-native não estão na velocidade que as timelines do Twitter e do LinkedIn fazem parecer. A gente está ajudando empresas grandes nessa transição, e mesmo as que estão estruturando o novo jeito de fazer produto provavelmente não vão chegar na velocidade de um Replit ou Cursor. Empresa nova "nasceu preparada" para AI. As outras estão reaprendendo. ## O MVP mudou de tamanho A parte do texto do Ravi que mais ressoou foi essa. O que mais muda no ciclo, hoje, **é a prototipação**. Antes, fazer protótipo era quase tão caro e demorado quanto fazer o produto final, então a galera pulava direto para o produto. Agora, prototipar virou trivial. Qualquer pessoa do time abre um Replit ou um Cowork e gera 4 versões interativas de uma feature em minutos. > *"O minimamente viável de antes era um negócio muito amarrado com barbante, com uma pessoa por trás dos panos fazendo tudo. Hoje, o minimamente viável é um sistema funcional, cheio de integração, que já grava num banco de dados, que tem dashboard."* Isso muda fundamentalmente o cálculo de *"vou fazer MVP ou já vou pro produto final?"*. O MVP de hoje é muito mais perto do produto final do que era 5 anos atrás. Mas continua sendo MVP, com a mesma função: tirar risco antes de comprometer o investimento grande. A sutileza: empresas tradicionais ainda têm fricção para rodar o produto final na velocidade do MVP. Login, segurança, integração com legado, compliance. Por isso o gap entre AI-native e o resto continua existindo, mesmo que todo mundo prototipe rápido. ## Fazer não é mais o problema, o que fazer é A partir do momento em que **velocidade deixa de ser vantagem competitiva** e todo mundo pode ser builder, o que diferencia é [senso de produto](https://open.spotify.com/episode/3ISQhy14KTgTyIWURKarW5?si=cec5b45730b64330). > "Não é porque agora é fácil fazer 12 protótipos ao mesmo tempo que você deveria estar trabalhando com essas 12 versões. Vale a pena fazer? Esse julgamento ainda não morre." Aíquis trouxe uma boa: clareza sobre qual pergunta você está respondendo é o que continua não mudando. Que decisão você ou sua empresa está tentando tomar? Isso informa que tipo de protótipo faz sentido (conceito, design, research, técnico) e quantas variações fazem sentido testar. E, por consequência, virou normal abrir mão de coisa que era "sagrada" antes. Teste A/B para mudar copy, por exemplo. Se duas pessoas razoáveis batem o olho e veem que o copy A é melhor que o B, segue o jogo. Dependendo do tamanho da empresa, não vale gastar duas semanas de experimento para confirmar 0,5% de uplift quando o custo do teste é maior que o ganho. Isso é senso de produto, não preguiça de processo. ## Coordenação dos times e o argumento (corajoso) do presencial Aíquis soltou a bomba do episódio. A reflexão começou em algo que faz sentido: para fazer o shift de "começar pelo protótipo" funcionar, o time inteiro (produto, design, tech, data) precisa estar trabalhando em coordenação fina. E hoje, na maioria dos times, cada pessoa está num momento diferente do ciclo de uma feature diferente. Difícil sincronizar quando ninguém parte do mesmo ponto. > *"Pra esse tipo de coisa, eu acho que funcionar como uma banda de jazz, numa sintonia de banda de jazz, exige um nível de sincronicidade que só o presencial traz."* O ponto não é volta ao presencial 5 dias por semana. É reconhecer que algumas coisas (especialmente shift de paradigma) são mais rápidas com o time na mesma sala. A outra ponta da mesma reflexão: times menores. Coordenação fina escala mal. Banda de jazz tem