O objetivo de um produto mínimo viável (MVP), conforme definido por Eric Ries, é aprender sobre a necessidade dos consumidores, gastando pouco dinheiro e esforço. No post "O problema com uma Lean Statup: o produto mínimo viável, Paul Kortman compartilha suas experiências desenvolvendo produtos mínimos viáveis. Começa explicando brevemente o que é lean startup:
O básico da filosofia lean startup é receber retorno dos usuários, fazer testes envolvendo os usuários e com isso descobrir se as pessoas estariam dispostas a usar e pagar pelo produto sendo criado, antes e durante o processo de criação.
O movimento Lean Startup tem a intenção de tornar a organização mais eficiente, identificando facilmente se há a necessidade para um produto que se deseja desenvolver. Porém, organizações algumas vezes consideram muito difícil definir um produto viável mínimo:
Todos entendemos o que significa Produto, e "Mínimo" faz sentido, quando questionamos o que é estritamente necessário e o que se pode começar a eliminar.
Paul Kortman descreve os questionamentos que tiveram durante a tentativa de desenvolver um produto mínimo viável:
Em que ponto o nosso produto se torna viável?
- Quando é atingida a massa crítica?
- Quando terminam as outras funcionalidades a serem construídas?
- Quando começa a gerar receita?
- Quando começa a gerar lucros?
No artigo publicado na Forbes "Os tempos estão mudando: a evolução do software na empresa", o diretor de estratégia da Yammer, Brian Murray, descreve o que está mudando no desenvolvimento de software corporativo com o lean startup, e por que essas mudanças são necessárias:
A ineficiência desenfreada no desenvolvimento tecnológico tradicional das empresas vem da tentativa de construir o produto perfeito antes do lançamento para os clientes. ... Equipes de desenvolvimento estão se concentrando agora na construção de MVPs sempre que possível. Isso permite que os provedores de serviços testem de forma eficiente suas hipóteses e ao final possam criar um produto que, de forma lenta e contínua, evolui para o que deveria ser, não para o que as pessoas pensam que deve ser.
No post Produto viável mínimo comparado ao produto mínimo "encantador", Adam Berrey apresenta sua opinião sobre como deve ser um produto mínimo viável:
Um sistema empresarial normalmente ganha na inovação tecnológica básica, funcionalidades, vendas e marketing. Se há funcionalidades suficientes para começar a vender, então se tem algo viável. É um ótimo começo.
Jesus Rodriguez explica, no texto O produto viável mínimo: foco no viável no lugar do mínimo, como o desenvolvimento de software nas empresas é diferente do desenvolvimento de produtos para consumidores, no que se refere a produtos viáveis mínimos. Para o mercado consumidor, o usuário do software também é o comprador. Esse raramente é o caso no mundo corporativo:
Quem testa o MVP raramente é quem toma a decisão final de aquisição. ... Startups de software empresarial precisam ser capazes de avaliar cuidadosamente o retorno ou feedback recebido sobre um MVP, filtrando o ruído das características que tornam o produto mais relevante para os potenciais clientes
Outro desafio para o conceito de produtos viáveis mínimos para softwares nas empresas é a forma como empresas baseiam suas decisões de compra em funcionalidades. Jesus Rodriguez descreve isso como uma "cultura do excesso de funcionalidades":
Por décadas, o desenvolvimento de software nas empresas evoluiu em meio a uma cultura que valoriza o número de funcionalidades ao invés da simplicidade e utilidade de um produto. Ao apresentar uma versão MVP do seu produto para empresas, pode-se esbarrar em preconceitos que tendem a associar o número de funcionalidades de um produto com a sua capacidade e adequação para uso em empresas.
O post lições sobre Agile - o produto viável mínimo por Sam Palani, descreve porque foi usado o produto mínimo viável para uma iniciativa complexa em sua empresa:
Estávamos trazendo toneladas de dados, escrevendo ETLs complexos e interfaces para extrair e manipular os dados, mas a real funcionalidade do negócio só era lançada em versões futuras e sprints posteriores. Num mundo ideal, ainda poderíamos ter sucesso com nossa abordagem de planejamento atual; no mundo real já sentíamos a paciência dos clientes se esgotando.
Palani explica como vê um produto viável mínimo, e como é possível usá-lo para desenvolver e entregar um produto desejável mínimo (MDP):
Um MDP vai além da viabilidade; inclui escopo maior e mais funcionalidades do documento de requisitos ou de escopo. Idealmente, deve-se planejar uma entrega ágil ou sprints com um MVP, que progressivamente muda para o estado de um MDP nas iterações seguintes, e que seja capaz de entregar o máximo benefício para o negócio além de real satisfação para o cliente.
Sam Palani descreve um processo de cinco passos para identificar e definir um produto mínimo viável nas empresas. Os passos são: identificar as partes interessadas; identificar o escopo; determinar a dependência entre as funcionalidades; realizar a prototipagem; e alinhar o produto mínimo viável com as necessidades do negócio. Palani recomenda:
Limite o número de funcionalidades interdependentes que pretende incluir em seu MVP. Concentre-se no viável, mas mantenha o mínimo em mente. Ter muitas funcionalidades interdependentes limita a capacidade de gerar um bom MVP.