Manoel Netto

Designer de Produtos Digitais

MVP não é protótipo

Há muita confusão no mercado, principalmente em ambientes onde se está experimentando uma transformação de outros métodos para o Lean / Agile, quanto se fala em MVP e protótipo.

Há muita confusão no mercado, principalmente em ambientes onde se está experimentando uma transformação de outros métodos para o Lean / Agile, quanto se fala em MVP e protótipo. E geralmente a confusão acontece quando se associa ao termo “validação”.

Existe todo tipo de validação de produto. Podemos validar experiência, funcionalidade, efetividade, performance, aderência de mercado, potencial de monetização, etc. Para cada tipo de validação, existem testes que podem ser feitos. Não podemos, por exemplo, validar funcionalidade e ausência de bugs em testes com usuários – porque afinal em utilização normal não teríamos a amplitude necessária para validar todas as possibilidades e alternativas. Assim como não dá para avaliar experiência de uso com testes automatizados. Para cada validação, seu teste.

Protótipos são ferramentas que validam muito bem a experiência de uso – fluxos, usabilidade, arquitetura da informação, acessibilidade e até mesmo interface – quanto mais fidelidade, mais ítens podem ser validados, quanto menos fidelidade, mais rápido podemos validar determinadas coisas. Protótipos raramente servem para validar aderência de mercado. Raramente. Raríssimo!

Para validar se um produto vai ter aderência, testar o potencial de rentabilizar, as possibilidades de “dar certo”, usamos um MVP. Mas é importante lembrar que um MVP não é uma ferramenta de validação meramente. Utilizamos o MVP (Produto Mínimo Viável) para lançar um produto mais rápido, começar logo, começar a ser útil antes, obter retorno do desenvolvimento mais rápido.

Diferença entre teste com usuários e teste de usabilidade (The UX Blog Medium)

Quando utilizamos um protótipo?

Em linhas gerais, quando podemos “simular, testar e jogar fora” o que criamos. Protótipos precisam ser o mais baratos e descartáveis o quanto possível, para que possamos testar rápido alguma hipótese antes de começar a desenvolver qualquer coisa. Protótipo a gente aproveita apenas os aprendizados na construção de um MVP. Alguns exemplos onde o uso de protótipo é recomendado:

  • Verificar se aquela ideia sensacional é fácil de ser colocada em prática.
  • Testar se a forma como organizamos informações numa tela / painel / mídia é facilmente entendida pelo usuário / cliente / consumidor.
  • Validar se a interface que desenhamos é de fácil uso por diferentes perfis de pessoas.
  • Comprovar o feeling de alguém do time que desconfiou que determinada mensagem pode não ser compreendida pelo público alvo ou até mesmo ofensiva.

Quando optar por desenvolver um MVP?

Há quem acredite que dá para evoluir de um protótipo para um MVP. Eu mesmo já ouvi em experiências de empresas passadas termos como “amarrar com barbante” e associar isso incorretamente a protótipo. Lembrem-se: gambiarras não são protótipos, se você não tem o objetivo de usar isso pra teste e jogar fora. Se sua intenção é criar uma gambiarra e depois fazer ela escalar (“colocando mais barbantes”) você só está fazendo um MVP de uma forma muito errada e não sustentável.

Um MVP não precisa ser um produto lindo, perfeito, cheiroso e pronto. Longe disso. Mas também não precisa ser uma bela porcaria, pois dessa forma você pode estar inviabilizando uma validação real de demanda, de aceitação, muitas vezes até de funcionalidade. “Mínimo” não quer dizer que não funciona direito.

Quando partir para o MVP?

  • Você já testou (de alguma forma) uma ideia e precisa validar se o mercado tem interesse.
  • Você tem uma demanda grande de produtos / funcionalidades que é muito urgente mas não tem como lançar tudo rápido. Lança o mínimo que dê valor ao seu usuário e incrementa aos poucos.
  • Seu produto tem um público certo, mas não tem investimento. Lance rápido uma parte que traga valor e rentabilize, use o dinheiro que entra para melhorar e ampliar o produto.
  • É preciso reformular um determinado processo, mas automatizações necessárias levarão tempo para serem implementadas. Use planilhas, papel, ligações, coloque pessoas para fazer manualmente o que ainda não está pronto, mas aplique o novo processo. Finja que é automático até que possa ser.

É preciso saber identificar bem quando usar uma coisa ou outra, para evitar confusões, atrasos, grandes problemas de experiência e até mesmo enormes dores de cabeça de produto, tecnologia e processos. Posso ajudá-lo também a capacitar sua equipe para esse e outros desafios.

Compartilhe esse texto via:

WhatsApp
LinkedIn
Facebook
Email

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *