Quase todo time que eu acompanho trata o MVP de startup como a versão menor do produto inteiro. Aí nada fica pronto, porque o produto inteiro nunca cabe no prazo. Vi isso de novo em uma reunião de acompanhamento esta semana.
Era uma plataforma de aprendizado em construção, um SaaS em que o aluno entra e estuda. Um parceiro ia fazer um lançamento e queria aproveitar a divulgação para levar gente lá para dentro.
A janela que define o MVP
Comecei pelo calendário. Eu disse para o time: “Um parceiro vai fazer um lançamento, e ele falou para gente se a gente teria alguma versão, alguma coisa para ele começar a levar usuários, porque como ele vai fazer um lançamento, ele já queria divulgar alguma coisa na plataforma.”
Na mesma conversa, emendei: “Então, se a gente conseguir ter alguma coisa antes, seria o ideal, entendeu? Se não conseguir, eu já tinha que saber. Aí a gente já fala com ele ali em expectativa.”
Saber cedo que não dá também serve. Com o parceiro a gente combina outra coisa. Ruim é descobrir na véspera. Gente entrando de verdade vale mais que tela a mais, e é por isso que eu insisto que startup precisa de cliente antes de precisar de investimento.
Primeiro ver o que já funciona
Pedi: “É isso que eu quero ver, o que está funcional, como está esse banco de dados, esse login, porque é um SaaS, a pessoa vai fazer login, aí tem a conta da outra e aí tem que ter todas as IDs de usuário. Vamos objetivo hoje.”
E segui: “Quero ver tudo funcional, a gente usando a plataforma e sendo salvo no banco de dados, o que já está funcional, o que falta fazer e o que você acha que não vai dar para fazer aí dentro, que de repente a gente vai ter que levar o código para fazer na mão. Vamos entender as limitações, vamos ver tudo que a gente puder hoje.”
Completei: “Então, o objetivo é ficar tranquilo que a gente vai conseguir desenvolver aí ou saber se a gente vai ter que trazer algum programador, alguma coisa para poder desenvolver.”
O time estava montando tudo em uma ferramenta que gera código com IA. Perguntei: “Se a gente tivesse feito direto na outra ferramenta, você acha que teria sido tão bom quanto ou melhor?”
E logo comentei: “É que, enfim, estamos evoluindo. Um parceiro inclusive passou uma outra ferramenta, ele desenvolve app e parece que ela é mais assertiva, vai mais incisiva nas alterações. Depois nós vamos testar. Talvez nesse primeiro que a gente está fazendo tem uma curva de aprendizado.”
No meio disso apareceu uma coisa boa. Falei na hora: “Gostei que a ID está em hash. Isso é positivo para escala? Para uma plataforma que pensa em ficar gigante.”
Tela dá para cortar. Login e banco, não, porque é por ali que entra a gente do lançamento.
O corte do MVP de startup
Aí veio a pergunta que mudou a reunião. Perguntei: “Me ajudem a entender uma coisa. O usuário vai em meus cursos, aí ele vai ter o curso que ele comprou. Aí entra em um curso, entra em um módulo, mas isso já vai ter, talvez não no lançamento.”
Na sequência: “Aí tem a aula, pode ter as questões que ele pode estudar, pode criar uma anotação, criar um flash card, tem a transcrição. Se não tiver curso nessa versão inicial, o que vai ter? Os artefatos para ele estudar. Então o parceiro tem que trabalhar na criação de artefato agora para ele poder lançar.”
Artefato era o nome que o time dava para o material de estudo, como questão e flash card.
Eu disse: “Aí que que a gente faz? A gente tira desse MVP. Não vai ter meus cursos, não vai ter grupo de estudo, não vai ter estatística. A gente só deixa essa parte de artefatos que vai estar cadastrada.”
E completei: “Ele vende, sei lá o que ele vai fazer, se ele vai dar acesso gratuito nessa primeira versão, alguma coisa assim. A pessoa entra aqui e ela tem acesso a todos os artefatos para ela poder estudar. E aí é debater com ele que tipo de artefato, como que ele vai cadastrar.”
Ninguém ali defendeu tela por tela, que é o jeito da fábrica de funcionalidade que trava time de produto. A régua foi uma só: o aluno entra e estuda no dia da divulgação?
Começar pelo lado de quem alimenta
O time tinha acertado uma coisa sem eu pedir. Falei para eles: “Eu acho que você começou certinho, você começou pela criação de artefatos. A gente tendo isso do lado do admin, a gente permite que o parceiro comece a criar os artefatos agora. Então, continua terminando isso.”
Dentro desse pedaço pequeno eu quis o atalho que poupa trabalho do parceiro. Expliquei: “Na hora de criar questão, ao invés da pessoa digitar qualquer questão, ela vai clicar em um botão que vai chamar o cenário de automação. Ela vai poder preencher manual, como está agora, só que vai ter um botão gerar com IA.”
E segui: “Na hora de clicar em gerar com IA vai chamar o cenário, que usa o prompt do parceiro, os e-books que vão estar todos configurados lá, e retorna já com a questão pronta aqui. Aí preenche o resto automaticamente. Na hora que clicar no botão tem que mandar o ID do usuário. O cenário cria a pergunta, salva no banco de dados já com o ID do usuário que solicitou.”
No fim, resumi o que ia levar ao parceiro: “Então, no lançamento, o que nós vamos ter? Cadastro de usuário, o usuário entra, vai ter os artefatos que vocês vão cadastrar e ele vai poder estudar com os artefatos, seja um flash card, seja uma questão, seja tal coisa.”
E fechei: “Então vamos tentar botar isso para a gente finalizar até o lançamento. Vocês acham que dá?”
Se você está montando um MVP agora, pega a data mais próxima em que alguém vai mandar gente para o seu produto e vê o que fica pronto até lá. É assim que a gente trabalha quando ajuda a validar um negócio com usuário de verdade.
Qual é a data que está definindo o seu MVP?
