Compreendendo o Produto Mínimo Viável (MVP) no Scrum: Resultado vs. Entrega

O que é um Minimum Viable Product, como trabalhar com ele te leva ao sucesso e quais as enormes vantagens que isso traz para você, sua equipe e seus clientes?

Neste artigo você aprende tudo sobre o MVP e descobre por que a diferença entre Outcome e Output decide sobre o sucesso ou fracasso do seu produto.

Diferença entre Outcome e Output no MVP

Quem desenvolve um produto para seus clientes deveria, em primeiro lugar, se perguntar quais necessidades esses clientes realmente têm e quais problemas o produto deve resolver. Uma vez esclarecidas essas questões, o desenvolvimento do produto pode começar, pois só então fica claro qual resultado (Outcome) os clientes desejam. Se o resultado desejado for, por exemplo, que os clientes possam se deslocar mais rapidamente de A para B, o produto (Output) poderia ser um carro. Mas não precisa ser, pois um skate também entregaria o Outcome desejado – e ainda seria mais barato e mais rápido de desenvolver do que o carro.

Curiosamente, a maioria das empresas nem sequer se preocupa com o Outcome para os clientes antes do desenvolvimento do produto: elas partem de uma ideia de produto fixa e se concentram apenas em entregar exatamente esse Output com os respectivos pacotes de trabalho ou features.

O foco exclusivo no output – um risco empresarial

Por que essa abordagem é tão arriscada e por que o foco exclusivo no output pode ter consequências fatais para uma empresa?

Quem trabalha com uma abordagem Big-Bang quer primeiro finalizar seu produto 100% antes de entregá-lo ao cliente. Isso pode levar a:

• a empresa investiu tempo e dinheiro demais no desenvolvimento,

• os clientes não precisam mais do produto porque, durante o longo período de desenvolvimento, um concorrente lançou uma versão melhor,

• o mercado para o produto não existe mais porque as circunstâncias e necessidades mudaram,

• ninguém compra o produto porque ele foi desenvolvido completamente fora do gosto e das necessidades dos clientes,

• o produto ficou tão superdimensionado, complexo e caro que os clientes preferem uma versão mais simples e barata da concorrência.

Resumindo: o risco é grande de que empresas vinculem todos os recursos a uma ideia de produto rígida por um período muito longo, mas depois o produto não seja comprado. Como contornar esse problema de forma simples e ágil? A solução é: Minimum Viable Product.

Qual solução o Produto Mínimo Viável oferece no Scrum?

Se você e sua empresa já trabalham com Scrum, talvez já tenha ouvido falar: Minimum Viable Product (MVP) significa produto mínimo viável. Se você trabalha, por exemplo, como Product Owner na sua empresa, deve sempre focar no outcome baseado na necessidade do cliente – no exemplo acima, isso significa chegar mais rápido do ponto A ao ponto B.

O que exatamente pode ser um produto mínimo viável no contexto dessa necessidade do cliente é mostrado na imagem a seguir, do blog da Crisp:

Naturalmente, o carro serve apenas como metáfora para o produto que o cliente originalmente desejava: a necessidade dele é chegar mais rápido do ponto A ao ponto B, e ele acha que precisa de um carro como solução para isso.

Ao trabalhar com o Minimum Viable Product, você como Product Owner garante que você e seu time Scrum entreguem os menores produtos viáveis (MVPs) ao cliente em iterações rápidas e pequenas. O importante aqui é que você mantenha sempre o outcome desejado em mente e entregue MVPs com os quais o cliente já consiga satisfazer sua necessidade pelo menos em linhas gerais:

A linha superior da imagem mostra que não faz sentido simplesmente vender ao cliente as primeiras peças prontas do carro – com elas, ele certamente não conseguirá se mover mais rápido do ponto A ao B. A linha inferior, por outro lado, mostra que tanto um skate quanto uma patinete, uma bicicleta e uma moto podem ser entregues ao cliente como MVPs, pois uma locomoção mais rápida é possível com cada uma dessas soluções.

Quais são as vantagens de um MVP?

Entregar MVPs para clientes, testadores e early adopters tem as seguintes grandes vantagens:

• Você recebe feedback muito cedo no processo de desenvolvimento: Esta primeira versão do produto já atende aos desejos do cliente? Funciona como esperado? O design está adequado? Talvez existam outros desejos ou desejos adicionais por trás da necessidade original do cliente?

• Aprendizado rápido gera grande progresso: Se você já sabe após o primeiro feedback do MVP o que é importante para o cliente e do que ele pode abrir mão, a segunda iteração já vai mostrar uma grande melhoria.

• Ajustes são possíveis a qualquer momento: O desenvolvimento iterativo proporciona alta flexibilidade – em vez de ter que redesenhar com dificuldade um produto final pronto após 3 anos de desenvolvimento, você pode fazer alterações após cada iteração sem grande esforço.

• Você gera receita antecipadamente: Como você já pode cobrar dinheiro pelos seus primeiros MVPs, você minimiza consideravelmente o risco empresarial

• Clientes encantados através da redução do preço de compra e tempo de desenvolvimento: Se no nosso exemplo acima ficar claro que o cliente já está completamente satisfeito com a bicicleta, porque ela atende à sua necessidade, você como Product Owner interrompe o desenvolvimento do produto exatamente neste ponto. Como você desenvolveu a bicicleta 1. mais rápido e 2. mais barato do que um carro, você pode oferecer ao cliente antecipadamente uma solução satisfatória que custa menos para ele.

Um exemplo típico de Produto Mínimo Viável

Um bom exemplo de MVP é o túnel da autoestrada A1 em Colônia: em vez de se concentrar nas necessidades dos moradores em relação à redução de ruído e primeiro entregar medidas menores e relativamente econômicas como limite de velocidade, asfalto silencioso e barreiras acústicas como Minimum Viable Product, construindo sobre o feedback dos moradores, os responsáveis tinham apenas o output em vista: um túnel de proteção acústica de última geração!

Após longos anos de construção e os consequentes congestionamentos de trânsito, surgiu um chamado túnel de proteção acústica que custou 200 milhões de euros. Como o feedback forçosamente tardio dos moradores agora mostra, o túnel não resolveu o problema – pelo contrário, intensificou ainda mais a situação de ruído.

Por que vale a pena trabalhar com o método MVP?

Especialmente quando o produto real ainda não está completamente claro e não está empiricamente assegurado que os clientes vão comprá-lo dessa forma e não de outra, é decisivo para o sucesso pensar em Outcomes e necessidades dos clientes e aproximar-se delas através de MVPs.

E mesmo em produtos onde você já conhece o panorama completo, como por exemplo um caminhão, a entrega incremental de Minimal Viable Products pode valer a pena. Pois eventualmente o seu cliente percebe que também fica satisfeito com muito menos funcionalidades do que originalmente pensava. E um cliente que recebe a solução do seu problema mais rápido por menos dinheiro é um cliente extremamente satisfeito.

Você quer mais fatos interessantes sobre o trabalho com Scrum e informações sobre como o trabalho ágil deixa os seus clientes mais satisfeitos e a sua empresa mais bem-sucedida? No nosso Scrum Guide você encontra tudo o que precisa para entender os fundamentos. Nos nossos treinamentos certificados de Scrum, você aprende como aplicar Agile na prática.

O que é um produto?

Leia o que é realmente um produto no Scrum e como você pode criar uma definição de produto.
=> O que é um produto?

Assim o Refinement será um sucesso!

Como Product Owner, defina o resultado esperado para o próximo Sprint e melhore os resultados do Refinement com estas dicas.
=> Product Backlog Refinement

Como desenvolver uma visão de produto?

Descubra como você, como Product Owner, pode desenvolver uma visão de produto em 3 passos simples.
=> Desenvolver visão de produto