O que é um MVP e o que deve (e não deve) incluir

Quem tem uma ideia para uma app ou para um software ouve cedo a palavra MVP. O problema é que a sigla é usada para coisas muito diferentes: uma versão barata, uma demonstração para investidores, uma app com metade dos ecrãs. E cada uma destas leituras leva a decisões diferentes sobre o que construir primeiro.

A resposta curta: um MVP (produto mínimo viável) é a versão mais pequena de um produto que permite testar, com clientes reais, a hipótese mais importante do negócio: que o problema existe e que a sua solução o resolve ao ponto de alguém a usar ou pagar por ela. Deve incluir só o percurso principal do utilizador, feito com qualidade suficiente para ser usado a sério. Deve deixar de fora tudo o que não ajuda a responder a essa pergunta.

De onde vem a ideia de MVP

O termo ficou conhecido com Eric Ries, autor do método Lean Startup. Num texto de 2009, Ries define o MVP como a versão de um produto novo que permite à equipa recolher o máximo de aprendizagem validada sobre os clientes com o mínimo de esforço.

Duas consequências desta definição costumam perder-se:

• O objetivo é aprender, não poupar. O próprio Ries avisa que o nome engana: um MVP não é uma forma de construir um produto amputado. Se a funcionalidade cortada era precisamente a que ia mostrar se a ideia funciona, o MVP falhou, por muito barato que tenha sido.
• Nem sempre é preciso. Se já sabe que há procura (por exemplo, porque vai substituir um processo interno que hoje vive em folhas de Excel), não há uma hipótese de mercado para testar. Nesse caso faz mais sentido falar de uma primeira fase do projeto do que de um MVP.

MVP, protótipo e primeira versão: qual é a diferença

Na prática, muitos projetos passam pelos três: um protótipo clicável para afinar a ideia, um MVP para a testar no mercado e uma versão 1 para crescer. Saltar o protótipo é comum; saltar a validação costuma sair caro.

O que um MVP deve incluir

Uma hipótese escrita

Antes de qualquer ecrã, escreva numa frase o que quer provar. Por exemplo: "os ginásios pequenos pagam uma mensalidade para os clientes marcarem aulas no telemóvel em vez de ligarem". Tudo o que entra no MVP tem de servir para confirmar ou desmentir esta frase.

O percurso principal, do princípio ao fim

O utilizador tem de conseguir fazer a tarefa que justifica o produto, sem becos sem saída. Numa app de marcações, é escolher uma aula, marcar e receber a confirmação. Se esse percurso não funciona de ponta a ponta, não está a testar o produto, está a testar a paciência das pessoas.

O que é obrigatório para usar a sério

Há coisas que não dão valor ao cliente mas sem as quais o produto não pode ser usado:

• Contas e acesso seguro, se o produto guardar dados de pessoas;
• Proteção de dados pessoais: política de privacidade, consentimentos quando forem necessários e cuidado com o que se recolhe (o RGPD aplica-se desde o primeiro utilizador, não a partir de um certo tamanho);
• Pagamentos, se a hipótese for "as pessoas pagam por isto";
• Uma forma de pedir ajuda, nem que seja um endereço de email.

Uma forma de medir

Defina antes de lançar o que conta como sucesso e como o vai saber: quantas pessoas completam o percurso principal, quantas voltam na semana seguinte, quantas pagam. Sem medição, o MVP é só uma app pequena.

O que um MVP não deve incluir

• Funcionalidades "para mais tarde" que não ajudam a testar a hipótese: painéis de estatísticas, vários idiomas, integrações com tudo, temas personalizáveis.
• Todas as plataformas de uma vez. Se os seus clientes estão sobretudo num tipo de telemóvel, ou se uma app web chega para testar, comece por aí. Explicamos as diferenças em app web ou app nativa.
• Automatizar o que pode ser manual. No início, pode ser alguém da equipa a aprovar pedidos, a enviar relatórios ou a tratar exceções à mão. Só se automatiza quando se sabe que o passo é necessário e frequente.
• Infraestrutura pensada para milhões de utilizadores. Deve ser possível crescer, mas não vale a pena pagar hoje por um volume que ainda não existe.

O que não deve ficar de fora é a qualidade do que entra. Um percurso principal cheio de erros não prova que a ideia é má; prova só que o produto não funcionava.

Como decidir o que fica de fora

Um método simples para uma reunião de uma hora:

1. Liste tudo o que imagina que o produto vai ter.
2. Para cada funcionalidade, pergunte: "se isto não existir, consigo saber se a ideia funciona?" Se a resposta for sim, sai do MVP.
3. Do que sobra, pergunte: "isto pode ser feito à mão durante uns meses?" Se sim, fica fora do software e passa a ser um processo interno.
4. Ordene o resto pelo percurso do utilizador e confirme que não há buracos entre um passo e o seguinte.

Se a lista final ainda for longa, normalmente é sinal de que a hipótese está demasiado larga e convém dividi-la em duas.

Um MVP de app nas lojas: o que convém saber

Se o MVP for uma app para iPhone ou Android, as regras das lojas também contam:

• A Apple não aceita demos nem versões beta na App Store. As versões de teste distribuem-se pelo TestFlight. O que vai para a loja tem de ser uma versão final, sem conteúdo provisório, e com funcionalidades que vão além de um site embrulhado numa app (diretrizes 2.1, 2.2 e 4.2 da Apple).
• O Google Play tem faixas de teste interno, fechado e aberto antes da publicação. As contas de programador pessoais criadas depois de 13 de novembro de 2023 só podem publicar depois de um teste fechado com pelo menos 12 testadores durante 14 dias seguidos.

Conte com estes passos no calendário. E lembre-se de que uma app publicada tem custos que continuam, mesmo sendo pequena: falamos deles em quanto custa manter uma app depois de lançada.

Como saber se o MVP resultou

O MVP termina quando responde à pergunta, não quando acaba o orçamento. Há três desfechos possíveis:

• A hipótese confirma-se: as pessoas usam, voltam ou pagam. Passa-se à versão 1, agora com prioridades baseadas no uso real.
• Confirma-se em parte: o problema existe, mas a solução tem de mudar (outro público, outra funcionalidade principal, outro preço). Ajusta-se e testa-se outra vez.
• Não se confirma: é uma má notícia barata. Saber isto com um MVP custa muito menos do que saber depois de construir o produto completo.

Por isso vale a pena pedir que o código do MVP seja feito para ser aproveitado, e não deitado fora, quando a hipótese se confirmar. É uma das perguntas a fazer quando pedir orçamento para uma app ou um software.

Resumo

• Um MVP é a versão mais pequena de um produto que permite testar, com clientes reais, se a ideia resolve um problema.
• O objetivo é aprender com pouco esforço, não fazer um produto mal acabado.
• Deve incluir uma hipótese escrita, o percurso principal completo, o mínimo obrigatório para uso real e uma forma de medir.
• Deve deixar de fora tudo o que não ajuda a responder à hipótese, incluindo o que pode ser feito à mão no início.
• Se a ideia for uma app, conte com as regras de teste e publicação da Apple e da Google.

Se ainda está a decidir que tipo de app faz sentido para a sua ideia, o guia sobre como criar uma app compara os caminhos possíveis. E pode ver como trabalhamos em desenvolvimento de apps.