O que é MVP?

Frank Robinson usou o termo Minimum Viable Product no contexto da SyncDev no início dos anos 2000, buscando equilibrar retorno e risco para fornecedor e cliente. Eric Ries ampliou sua difusão em Lean Startup e enfatizou aprendizagem validada com o menor esforço possível; seu livro de 2011 tornou essa leitura popular. As duas formulações são relacionadas, mas não idênticas. O verbete explicita ambas e se concentra no MVP como instrumento de aprendizagem em produto.

MVP significa Produto Mínimo Viável. O termo ficou popular e passou a nomear qualquer primeira versão, mas sua finalidade é mais específica: obter evidência sobre uma hipótese importante com investimento limitado. Imagine alguém pensando em abrir uma padaria de pães especiais. Construir a loja inteira antes de descobrir se pessoas comprarão aquele pão torna o erro caro. Oferecer uma pequena produção de qualidade a um público escolhido pode mostrar demanda, preço e problemas de entrega. O “mínimo” depende do que precisa ser aprendido; “viável” depende de oferecer experiência suficiente para que a resposta tenha significado.

Comece pela incerteza. Pergunte o que a equipe ainda não sabe e que decisão depende dessa resposta. O problema existe? Quem o sente? A solução ajuda? Pessoas retornam? O serviço consegue operar com segurança? Misturar todas as perguntas num lançamento grande dificulta aprender. Escolha uma hipótese de alto risco e torne-a verificável. Uma frase como “clientes gostarão da ideia” não define que comportamento observar. “Pessoas que hoje ligam para agendar conseguem e escolhem completar a tarefa no novo canal” já orienta um teste.

Segmente o público. Um MVP não precisa atender todos os tipos de cliente no início. Um grupo menor e claramente definido ajuda a oferecer experiência coerente e interpretar respostas. Quem foi convidado importa: colegas da empresa podem ser mais pacientes e favoráveis que clientes desconhecidos. Registre como participantes foram escolhidos e que diferenças podem limitar a generalização. Segmentar não significa ignorar acessibilidade ou segurança. Significa declarar para quem a primeira versão funciona e quem ainda não está coberto.

Desenhe a aprendizagem antes de construir. Defina que sinal apoiaria, enfraqueceria ou não responderia a hipótese. Se a pergunta é se alguém consegue resolver a tarefa, conte conclusões sem ajuda e observe onde a pessoa para. Se é disposição para pagar, cliques numa página de interesse não são a mesma evidência que uma compra. Uma métrica pode ser afetada por preço, canal, comunicação ou seleção de participantes. Planeje como coletar dados e conversas complementares, e estabeleça critérios de decisão antes de ver o resultado para evitar justificativas convenientes.

Escolha o menor experimento adequado. Um protótipo pode servir para testar compreensão ou usabilidade sem implementação de produção. Um serviço concierge, feito manualmente nos bastidores, pode testar se a proposta entrega valor antes de automatizar. Uma versão limitada do produto pode observar comportamento em uso real. Nem todo experimento é um MVP no sentido estrito, mas todos podem fazer parte de uma sequência de Product Discovery. Chamar uma landing page de MVP sem esclarecer o que ela mediu produz confusão. Diga o que foi colocado nas mãos das pessoas e que conclusão é permitida.

Viabilidade inclui qualidade. Mínimo não significa quebrado, inseguro ou enganoso. Se usuários reais dependem de um serviço, ele precisa cumprir o propósito prometido com proteção proporcional ao risco. Um pagamento, um dado de saúde ou uma decisão financeira exigem cuidados próprios, mesmo em piloto. É aceitável que muitas funcionalidades futuras faltem, desde que o recorte atual tenha uma experiência completa para a tarefa testada. Um botão que não funciona pode medir curiosidade sobre texto, mas não mede adoção de um serviço funcional.

Recorte vertical. Um primeiro produto útil atravessa as camadas necessárias para entregar uma tarefa, ainda que para poucas pessoas e casos. Construir só a base técnica ou apenas telas bonitas pode ser trabalho preparatório, mas não permite observar valor em uso. A Lean Inception pode ajudar o grupo a alinhar público, jornada, capacidades e resultado esperado. O canvas de MVP é um registro da decisão, não substituto da experiência real. Ao escolher o recorte, inclua operação e suporte necessários para cumprir a promessa.

Construir, medir, aprender. Eric Ries associou MVP ao ciclo de Lean Startup. A ordem da execução começa por decidir o que se quer aprender e como medir, depois criar o recorte e observar seu uso. Uma entrega sem hipótese ou sem coleta de evidência pode ser uma versão inicial válida, mas não é um experimento bem desenhado. A equipe analisa o que aconteceu, considera vieses e escolhe perseverar, mudar ou encerrar a aposta. Um resultado negativo é útil se evita investimento maior numa direção inadequada.

Diferencie problema e solução. Um MVP pode mostrar que uma proposta não funciona, mas talvez o problema continue importante. Se participantes não usam um agendamento digital porque precisam primeiro confirmar cobertura, a equipe não deve concluir imediatamente que ninguém quer agendar. Investigue onde a hipótese falhou. Também pode ocorrer o contrário: pessoas usam uma versão inicial por incentivo temporário, sem necessidade duradoura. A interpretação pede observação, entrevistas e atenção ao contexto.

Critérios de avanço. Combine antecipadamente que informação justifica ampliar público, automatizar uma operação manual ou investir em novas capacidades. Um grupo pequeno não prova que a solução escalará, mas pode revelar obstáculos. A progressão deve ser gradual e acompanhada por medidas de produto, qualidade e custo operacional. Se um piloto depende de esforço extraordinário de funcionários, sua experiência pode ser excelente e sua operação inviável. O aprendizado deve incluir a capacidade de repetir o serviço.

MVP não é prazo fixo. Dizer que todo MVP leva um número padrão de dias ignora complexidade e risco. O custo de aprender precisa ser menor que o de construir sem evidência, mas alguns testes exigem revisão legal, integração ou recrutamento cuidadoso. Também é possível gastar meses por indecisão e chamar isso de prudência. A pergunta útil é qual menor caminho seguro para responder a hipótese, não qual menor prazo para apresentar uma tela. Marque uma data de revisão e explique o que será possível concluir nela.

Quando usar. A abordagem faz sentido quando existe incerteza importante sobre problema, solução ou modelo e é possível obter informação com um recorte menor. Para corrigir um defeito conhecido ou cumprir obrigação regulatória clara, talvez o trabalho peça implementação direta e controle de qualidade, não um MVP. Em produto já estabelecido, uma funcionalidade nova ainda pode ser testada em público limitado. O nome não deve ser imposto a todo item de backlog.

Riscos éticos. Não engane pessoas sobre o que o produto faz, especialmente em serviços sensíveis. Se há atendimento manual, deixe claro o que é necessário para confiança e consentimento. Proteja dados e ofereça suporte adequado. Um teste barato para a empresa pode transferir custos altos a clientes se falhar. A visão original de Frank Robinson considerava risco para fornecedor e cliente; a releitura de Ries enfatiza aprendizagem validada. Ambas apontam que “mínimo” não é licença para prejudicar quem participa.

Dados e decisão. Métricas de vaidade, como visitas brutas, podem dar sensação de sucesso sem mostrar valor. Defina ação relevante, intervalo de observação e um grupo comparável. Em serviços de uso eventual, retenção semanal talvez seja inadequada; em tarefa diária, pode ser central. Considere feedback qualitativo para explicar números. Documente decisões: que evidência levou a seguir, pivotar ou parar? Isso impede que a equipe reinterprete cada teste conforme a solução preferida.

Alinhamento entre áreas. Um experimento de produto pode depender de marketing, suporte, jurídico, dados e tecnologia. Antes do lançamento, combine que promessa será feita ao público, quem atenderá dúvidas e quem interromperá o teste se aparecer um problema. Sem esse acordo, o grupo pode obter uma taxa de uso atraente enquanto outra área absorve custos invisíveis. A comunicação interna deve explicar que o MVP testa uma hipótese e tem limites definidos. Isso ajuda interessados a avaliar o resultado sem exigir que toda funcionalidade imaginada entre antes do aprendizado.

Aprendizado acumulado. Documente hipóteses, decisões, dados, entrevistas e limitações em linguagem que outra pessoa consiga entender. Uma planilha de conversão sem contexto de recrutamento pode ser reinterpretada meses depois como prova forte demais. Registre também por que uma opção foi descartada. A memória do experimento reduz repetição de testes e permite comparar a evolução da proposta. O documento não precisa ser extenso; precisa preservar a lógica da decisão.

A sequência depois do primeiro MVP. Uma hipótese respondida revela outras. Talvez pessoas concluam a tarefa, mas o custo de atendimento seja alto; talvez o público de teste seja pequeno demais para sustentar a operação. Planeje o próximo experimento conforme a incerteza restante. Um MVP não precisa ser descartado por princípio nem virar automaticamente produto permanente. A arquitetura, a experiência e a operação podem evoluir. O que deve continuar é a disciplina de aprender antes de ampliar o investimento.

Produto digital. Imagine uma equipe hipotética que quer oferecer agendamento online. Antes, planeja 22 funcionalidades, incluindo histórico, lembretes, integração com todos os convênios e relatórios. A primeira hipótese é mais simples: pessoas de um segmento conseguiriam escolher e confirmar um horário sem telefonar. O time entrega busca de horários, escolha e confirmação para uma única unidade, com suporte humano nos bastidores. Entre 50 pessoas convidadas, 31 iniciam e 18 concluem sem ajuda. Os números são ilustrativos. Observações mostram que algumas param porque não encontram informação de cobertura. O time testa essa informação antes de ampliar a lista de funcionalidades. Não afirma que 18 conclusões comprovam sucesso nacional.

Serviço fora de TI. Imagine uma cooperativa considerando entrega de cestas de alimentos para um bairro. Em vez de construir aplicativo, frota e centro de distribuição, conversa com moradores e oferece um piloto de quatro semanas a 30 famílias, com pedidos por um canal simples e montagem manual. A hipótese é que haveria demanda recorrente por uma cesta com composição flexível. Das 30 famílias hipotéticas, 17 fazem um segundo pedido. A equipe investiga qualidade, preço, substituições e custo real de montagem. Antes, o plano se concentrava na plataforma; depois, a operação e o valor recebido conduzem a decisão. Um piloto manual não prova que o negócio escalará, mas pode evitar automatizar um serviço mal compreendido.

Produto interno. Imagine uma empresa com 200 funcionários que pensa em construir um portal de orientação sobre benefícios. Primeiro testa um serviço assistido para 20 pessoas recém-contratadas, com respostas verificadas pela equipe de RH. A hipótese é que elas conseguem encontrar respostas sem abrir chamados repetidos. No cenário fictício, 12 de 20 resolvem suas dúvidas no primeiro contato, mas 5 encontram uma regra desatualizada. O resultado exige corrigir conteúdo antes de automatizar. Um protótipo visual poderia testar navegação, mas não confiabilidade da resposta. O MVP escolhido precisa responder a pergunta que realmente ameaça o valor.

Caso de falha útil. Imagine que um time oferece a 40 profissionais um recurso de resumo automático e apenas 4 o usam uma segunda vez. Conversas revelam que as respostas não citam fontes, requisito central para aquele trabalho. Em vez de considerar os 36 ausentes “resistentes à inovação”, o time testa uma versão com referências e verificação. Se o uso continuar baixo, pode encerrar a aposta. A descoberta cedo economiza trabalho e preserva confiança. Os números são didáticos, não representam caso real da K21.

Em cada contexto, a pergunta, o público e a forma de evidência mudam. Antes de construir, a equipe precisa dizer que decisão o teste apoiará. Depois, precisa aceitar que o resultado pode contrariar sua ideia favorita.

Cursos K21 recomendados