Concrete Logo
Hamburger button

MVEP não é MVP!

  • Blog
  • 26 de Março de 2013
Share

Quando se pensa em Lean Startup, o primeiro passo é achar um problema que vale a pena ser resolvido.

É indispensável sair do escritório para iterar sobre seu modelo de negócios e aprender mais sobre os seus clientes.

Um contato direto com os clientes é fundamental para encontrar um modelo de negócio escalável e rentável.

Hora de criar o MVP!

O MVP (minimum viable product) é uma versão do produto que possibilita o time a coletar o máximo de aprendizado validado sobre os seus clientes com o mínimo de esforço e de tempo de desenvolvimento. (Eric Ries)

Minimum Viable Product

Não é necessário de fato lançar o seu produto para atingir os objetivos do MVP. Algumas startups validaram suas hipóteses de valor com soluções ainda mais simples como uma landing page, um vídeo ou até um MVP concierge!

Steve Blank vai além e separa este conceito em MVP de baixa fidelidade e de alta fidelidade.

O primeiro tem o objetivo de validar o encaixe entre o problema e a solução na etapa de Customer Discovery. Já o segundo, é usado na etapa de Customer Validation para testar as funcionalidades principais da solução nas mãos dos clientes.

Vamos falar de um caso que pode ser familiar…

Quando seu MVP é substituído por um MVEP

Você já sabe como obter métricas para testar as suposições mais arriscadas no seu modelo de negócios através de um MVP bastante enxuto.

Mas quando você está com seu time pronto para começar a desenvolver as primeiras funcionalidades do MVP, alguém diz com empolgação:

“Peraí! Existe um produto (framework / ferramenta / Software as a Service) que faz quase tudo que consta no seu MVP e ainda possui umas funcionalidades extras super legais!”.

Vou chamar este produto de MVEP.

Err… MVEP?!

O MVEP (maximum viable existing product) é aquele produto já existente em um contexto parecido. Ele é o produto disponível que possui o máximo de funcionalidades em comum com seu MVP.

Maximum Viable Existing Product

Normalmente, a descoberta de um MVEP contagia imediatamente o empreendedor com grandes esperanças. Encontre os 7 erros:

“Usando este produto existente poderemos aproveitar as funcionalidades principais que ele já possui! Precisaremos apenas customizar o visual para que fique com a nossa cara! Além disso, haverá um pequeno esforço para integrar com os nossos sistemas… Mas o importante é que adicionando apenas uma camada de software em cima dele, a gente desenvolve aquela funcionalidade especial que é super importante para conseguirmos validar as hipóteses sobre a nossa proposta única de valor! Mas é coisa rápida e logo estará no ar! Ainda ganharemos outras funcionalidades de graça! Além disso, o tempo para chegarmos ao mercado será reduzido pela metade!”

Quem tem medo da Dietzler’s Law?

Quando a Concrete Solutions apoiou o Agile Brazil 2012 eu tive a oportunidade de assistir a apresentação do Neal Ford onde ele fala sobre a Dietzler’s Law:

Um projeto baseado em uma ferramenta contextual irá falhar.

80% do que o usuário quer é rápido e fácil de criar. 10% é possível com uma certa dificuldade. Já o restante é impossível pois não se pode ir muito além dentro das abstrações existentes.

Usuários sempre querem 100% daquilo que querem.

Dietzler's Law

De maneira similar, usar um MVEP limita o seu desenvolvimento a abstrações pré-existentes do produto utilizado.

Aquela funcionalidade fundamental para validar com seus usuários se o seu produto inovador realmente gera valor pode não ser tão fácil de adicionar quanto parece. Essa quebra de expectativas gera uma grande frustração em todo o time.

Pior ainda se você descobrir que ela está na parte impossível deste espectro…

Habemus, Deva’s Law!

Na minha experiência, descobri que o problema não se limita à dificuldade em dar aos usuários o que eles querem. É ainda mais complicado atender aquilo que os usuários não querem e o MVEP possui!

Faço minha contribuição com a Deva’s Law:

Criar um MVP baseado em um produto existente (MVEP) não é sustentável. Com um MVEP, além de ser mais difícil do que parece criar aquilo que os usuários querem, o maior perigo encontra-se naquilo que os usuários não querem e o MVEP possui.

80% do que o usuário não quer é rápido e fácil de tirar. 10% é possível esconder com um pouco de gambiarra. Já o restante é impossível pois não se pode ir muito além dentro das abstrações existentes.

Usuários sempre não querem 100% daquilo que não querem.

Deva's Law

Vale ressaltar também que o custo de manutenção daquelas inúmeras funcionalidades do MVEP que não importam para os seus usuários será grande. Será um desperdício.

Menos é melhor

Christopher Hsee (Universidade de Chicago) conduziu experimentos que demonstram o efeito less-is-better. Entre eles:

Um aparelho de jantar com 24 peças intactas é mais bem avaliado do que um com 31 peças intactas (incluindo as mesmas 24) mais algumas peças quebradas.

Ou seja, adicionar funcionalidades quebradas pode diminuir o valor do seu produto, mesmo que você esteja ofereçendo mais coisas!

O que vale mais: um produto mínimo viável ou um produto existente máximo viável adaptado ao seu modelo de negócios (na medida do possível)?

MVP vs MVEP

Além disso, mesmo que a utilização de um MVEP aparentemente possua um custo menor, não é nada lean começar um MVP com um grande escopo.

Como escreveu o Ash Maurya (olha a gente no BizAgility):

“O primeiro passo é reduzir o escopo do seu MVP à sua essência, de maneira a construir o menor possível”.

Efeitos colaterais do MVEP

Atente-se ao apoiar seu MVP em um produto já existente. A sensação de ganhar funcionalidades extras “de graça” é tão perigosa quanto convidativa.

Atraso no lançamento do seu MVP

Apesar de parecer contra-intuitivo inicialmente, o lançamento está atrasado. A Dietzler’s Law e a Deva’s Law aconteceram! Algumas funcionalidades são difíceis de implementar. Outras são difíceis de esconder. Isso causará uma demora tal que já superou as estimativas de um MVP customizado.

Lançamento prematuro

Após desistir daquelas funcionalidades impossíveis, você decide lançar logo o MVEP para acalmar os stakeholders. Aquilo que vocês tinham combinado sobre lançar o produto sem divulgação de marketing não cabe mais frente à ansiedade de todos. Acabam gastando uma grana com uma super empresa de marketing e relações públicas, já que compartilham de uma suposição de que o produto será um grande sucesso.

Interrupções nos ciclos de build-measure-learn

Enquanto o time ainda está ocupado fazendo algumas correções pós-lançamento: BOMBA. Várias coisas inesperadas acontecem:

  • Os papéis dos usuários são diferentes do que você precisava! Vai ser nessário distorcer um pouco o que cada um deveria fazer e tomar uns cuidados extras…
  • Alguns relatórios sensíveis que só os administradores deveriam ter acesso são visíveis para qualquer um! Vamos precisar escondê-los da maneira mais dura…
  • O MVEP tem uma limitação que te impede de sequer acompanhar a sua métrica chave!
  • Existem muitas maneiras de autenticação e os usuários estão confusos!
  • A UX do MVEP não previa um número tão grande de itens nessa listagem! Não tem como fazer paginação… Essa página vai demorar bastante para carregar.

Não há tempo de iterar pelas hipóteses, esses problemas viram prioridade.

Danos irreparáveis

Putz! Ele também possui um sistema de segurança que depois de duas semanas deleta informações cruciais para os seus usuários, e você só descobriu agora que já não dá mais para recuperar! Não era fácil enxergar…

Dificuldade de pivotar

Você então descobre que aquele MVEP não é tão compatível com o seu modelo de negócios. Só que o custo de pivotar depois de apresentar aquele escopo enorme de funcionalidades pros seus usuários é muito alto. “Agora é tarde demais” é o que vão dizer.

Alta taxa de débito técnico

Então você decide perseverar com aquele modelo de negócios que você não conseguiu validar construindo seu produto em cima do MVEP. O seu time estará desmotivado. O código precisará ser remendado para forçar aquelas funcionalidades que não caem tão naturalmente. O seu produto vira uma mistura de confusão com débito técnico.

MVEP é sempre ruim?

O MVEP é bastante perigoso em um ambiente de Lean Startup. Muitas incertezas fazem com que a flexibilidade para iterar de maneira rápida e mudar de rumo seja fundamental.

Mas fora do contexto de startups, o MVEP pode ser uma facilidade muito conveniente para prover uma base sólida ao seu produto. Mas é preciso estar atento a sinais de dissonâncias entre a sua utilização do MVEP e como ele foi feito para ser usado.

Ou seja, se você está querendo apenas uma loja, que tal o Spree? Vai precisar de um blog? Usa WordPress. Sua startup precisa de um help-desk? Usa o Zendesk! Não reinvente a roda.

O importante é não ser otimista. Se a sua utilização daquele produto existente for um pouco diferente da esperada, os efeitos colaterais poderão aparecer!

Seja lean!

Ter a propriedade de suas próprias abstrações é um ativo muito valioso. Quando chegar a hora, faça um MVP enxuto e não se preocupe com as leis de Dietzler e Deva!

Precisa de ajuda? Entre em contato com a Concrete Solutions e nós usaremos nossa expertise para maximizar as suas chances de sucesso!

Bônus: Cheat Sheet (em inglês)

Cheat Sheet

Junte-se à conversa!

Já se deparou com um MVEP? A Dietzler’s Law se manifestou? E a Deva’s Law? O que deu certo? O que deu errado?

Se você fosse o fundador do Twitter, desejaria que ele fosse construído em cima do WordPress?