MVP: O que é, pra que serve e como o PO pode contribuir?

Neste artigo, vamos apresentar o que é (e o que não é) o MVP em sua totalidade, descobrir as vantagens de utilizar esse método e como o PO pode contribuir para um bom Produto Mínimo Viável com base em suas habilidades, características e responsabilidades.

Quando uma Startup ou alguma empresa já existente está tentando colocar um novo Produto, uma nova ideia ou serviço no mercado, é normal aparecer aquela velha questão: Será que os meus usuários/clientes estarão satisfeitos com este Produto? Será que irei resolver os seus problemas, dores e necessidades?

Existem diversas questões que podem ser levantadas quanto à real resposta do Produto frente aos problemas levantados. Para isso, temos o conceito do MVP – Minimum Viable Product (Produto Mínimo Viável), do qual permitirá responder a essas questões em curto espaço de tempo e validar as hipóteses de soluções levantadas, permitindo o colhimento de reais de feedbacks.

MVP: O que é, pra que serve e como o PO pode contribuir?

O que é o Minimum Viable Product?

O MVP é a menor versão do Produto, da qual pode ser entregue aos usuários com o mínimo esforço possível, porém com o devido valor de negócio atrelado e solucionando as dores e necessidades primárias sem muita complexidade. É a versão de testes de um produto que permite colher feedbacks rápidos dos usuários quanto à sua aceitação e reação do público.

O MVP permite a validação ou invalidação da ideia o mais rápido possível, de modo que a melhor estratégia possa ser adorada e/ou o produto ser abortado. O Produto Mínimo Viável vai permitir que seja validado, além da ideia e solução do problema, canais de distribuição, percepção do público e, inclusive, se existe um público e demanda.

Eric Ries traz uma definição muito boa e sucinta quanto ao conceito do MVP:

… o produto mínimo viável (MVP) é um produto com recursos suficientes para satisfazer os primeiros clientes e fornecer feedback para desenvolvimento futuro …

Essa definição nos ensina alguns valores importantes a serem estudados:

Recursos suficientes…

Uma vez que o Backlog do Produto esteja devidamente priorizado de acordo com o Valor de Negócio, o Product Owner deve ter a capacidade de compreender os recursos suficientes para que essa versão mínima possa entregar o devido valor de negócio de uma forma enxuta.

O PO precisa saber que O MVP é o produto do tamanho certo. Deve ser grande o suficiente para causar adoção, satisfação e vendas, mas não tão grande que seja inchado e arriscado.

Satisfaz os primeiros usuários…

O MVP não é um produto feito “nas coxas” e sem qualidade. Essa primeira versão deve receber o mesmo nível de qualidade do produto final, porém como o seu objetivo é testar hipótese, certamente não terá todas as funcionalidades.

Uma das habilidades do Product Owner é o conhecimento do mercado e dos usuários/clientes. Esse conhecimento deve ser muito bem utilizado, pois é esta etapa que vai definir a aceitação (ou não) do Produto pelo seu respectivo primeiro público.

Permite feedback para continuidade no desenvolvimento…

Uma vez que os primeiros recursos foram entregues e já existem usuários interagindo com o Produto, é possível iniciar o processo de colhimento de feedback. Aqui é importante colher o máximo de informações possíveis e, a partir dessas opiniões, verificar se a proposta realmente faz sentido, se a estratégia valeu a pena ou se o produto realmente resolveu os problemas propostos.

O PO precisa elaborar questões e observar o comportamento dos usuários com base em sua expertise. Aqui é possível que ele trabalhe junto ao profissional de UX na realização de pesquisas, entrevistas, entre outras técnicas.

A partir dos Feedbacks recebidos, deve ser possível tomar decisões sobre a continuidade ou não do Projeto, melhorias e ações a serem tomadas, repriorização e reavaliação do Backlog.

O que não é MVP

Até aqui definimos o que é o MVP, seu objetivo e como usar. Porém devemos tomar cuidado com os conceitos equivocados sobre a Versão Mínima do Produto. A seguir uma listinha para deixar bem claro o que não é MVP e como o PO pode se precaver desses equívocos:

• O MVP não é uma fase do Projeto, onde se entrega versões fracionadas desta versão mínima. De fato, utilizando o ágil ou algo semelhante, é possível quebrar em várias entregas, porém não deve ser considerado como uma fase, mas sim uma versão do Produto.
• O MVP não é apenas um protótipo, do qual não tem as reais funcionalidades e serve apenas para ilustrar o produto a ser construído. A versão deve conter features reais e funcionais para validar com um público e no cenário real.
• O MVP não é o produto final. O MVP só será a última versão do produto caso a hipótese de resolução de problema não seja validada e não tenha a devida aceitação do público. Caso contrário, com base nos feedbacks e no Backlog priorizado, deve ser rapidamente transformado em versão mais completa do ideal.
• O MVP não pode ficar sem métrica. Métricas relacionadas à aceitação, taxa de retorno e satisfação, correção ou mitigação do problema, retorno financeiro ou qualquer outra devem ser previamente estabelecidas para testar se a hipótese anteriormente levantada é verdadeira.
• O MVP não pode ser demorado. Como a ideia é validar a ideia no menor tempo possível buscando errar mais cedo e evitar desperdício, é muito importante colocar a menor versão viável do Produto em Produção assim que possível.

Como o Product Owner pode contribuir na construção do MVP?

A utilização do MVP para todo e qualquer Produto é essencial na vida e no dia a dia do Product Owner, pois o resultado do trabalho exercido no início trará consequências que vão refletir por todo o Ciclo de Vida do Produto, podendo essas serem positivas ou negativas.

Por mais difícil e complexo que seja abrir mão de uma ideia que parece incrível, o Dono do Produto precisa ter a autonomia suficiente para recomendar ou não a continuidade no Projeto. Essa autonomia deve ser baseada em fatos e na avaliação do retorno sobre investimento com base nos usuários analisados.

O PO deverá aplicar os seus conhecimentos na maximização do valor para compreender quais as primeiras funcionalidades necessárias para que essa versão esteja disponível ao público, deve ser capaz de gerenciar e priorizar o Backlog com base nos feedbacks colhidos, deve utilizar sua habilidade de comunicação para compreender esses primeiros usuários e por fim, adaptar a estratégia do Produto a cada iteração.