MVP: o que entra na primeira versão (e o que fica para depois)

MVP, ou produto mínimo viável, é uma das ideias mais citadas e mais mal interpretadas no desenvolvimento de software. Não se trata de entregar algo mal feito, mas de entregar pouco, bem feito, para aprender rápido.

Comece pela pergunta, não pela lista de funcionalidades

Antes de listar telas, responda: qual é a principal hipótese que precisa ser testada? Por exemplo:

• clientes aceitam fazer pedidos sozinhos, sem falar com um vendedor;
• profissionais pagam uma assinatura para organizar a agenda;
• a equipe de campo usa um aplicativo em vez de ligar para o escritório.

O MVP deve conter apenas o necessário para confirmar ou descartar essa hipótese.

O que normalmente entra

• O fluxo principal, do começo ao fim. Se o produto é um portal de pedidos, o cliente precisa conseguir montar e enviar o pedido.
• Cadastro e acesso. O mínimo para identificar quem está usando.
• Uma forma de medir o uso. Sem dados, não há aprendizado.
• Um canal de contato. Os primeiros usuários vão encontrar problemas e precisam de um jeito fácil de avisar.

O que normalmente pode esperar

• painéis administrativos completos (uma planilha ou tela simples resolve no início);
• automações de casos raros;
• personalização visual avançada;
• integrações que podem ser feitas manualmente nas primeiras semanas;
• aplicativo nativo, quando uma aplicação web responsiva atende.

Sinais de que o escopo cresceu demais

• a primeira versão leva mais de alguns meses para ficar pronta;
• toda funcionalidade é "essencial";
• ninguém consegue dizer qual hipótese o MVP testa.

Depois do lançamento

O trabalho de verdade começa quando os primeiros usuários entram. Acompanhe o uso, converse com eles e priorize a próxima versão a partir do que acontece na prática, não do que foi imaginado no início.

Se você tem uma ideia e quer transformá-la em uma primeira versão, conheça como trabalhamos com MVP e produtos digitais ou faça o teste de prontidão para MVP.