Desde que iniciamos o Zeppelin Labs, ajudamos fundadores e partes interessadas a criar seus produtos digitais.

Em muitos casos, o objetivo era construir o famoso MVP (Minimal Viable Product). Digo famoso porque é um velho amigo do mundo do Desenvolvimento de Produtos, e não vou defini-lo neste artigo.

Mas quando você começa a pensar no que precisa ou não ser incluído no MVP, é quando a catástrofe pode ocorrer.

Deixe-me compartilhar com você cinco erros comuns que cometemos no Zeppelin e como aprendemos a evitá-los.

Falta de um objetivo claro para o MVP

Um objetivo claro e inequívoco para nosso MVP pode nos ajudar a tomar melhores decisões sobre o que incluir e o que não incluir ao definir nosso MVP. Quando não sabemos qual é o nosso objetivo e qual o resultado que buscamos, toda ideia pode ser uma boa ideia para nossa versão mínima.

Usar frameworks como OKRs (Objectives and Key Results) é uma ótima maneira de alinhar os stakeholders e a equipe no que queremos do nosso MVP, para que possamos defini-lo e garantir que não excedamos o escopo. Cada quantidade extra de escopo pode ser potencialmente prejudicial em termos de custo (dinheiro e tempo).

Criando o MVP com base no que as partes interessadas desejam

Esse equívoco está diretamente relacionado a um dos erros mais críticos na hora de criar um produto: construí-lo inteiramente para a concepção das necessidades do usuário pelos stakeholders ou equipe, e não apoiar essa análise com contato direto e aprendizado com os usuários.

Como em todos os outros marcos do nosso produto, você precisa ter empatia com os usuários, pesquisar e aprender com o que eles precisam e desejam. Mas se você está construindo um MVP e esperando para testá-lo com os usuários quando já estiver construído, você está trilhando um caminho perigoso, meu amigo.

Não experimentar antes de fazer o MVP

Acredito que esse seja o erro mais comum, pois a ideia de fazer um MVP pode induzi-lo a pensar que não precisa experimentar. É comum pensar que se você faz o MVP, já está experimentando.

As partes interessadas e o pessoal do produto também costumam acreditar que, se você está conversando com os usuários, enquanto faz o MVP, está experimentando. Isso não é experimentar!

Você precisa experimentar antes de tentar fazer um MVP. Isso ajudará você a aprender com um custo muito menor (dinheiro e tempo). Sempre recomendo visitar o conceito MVT* (Minimum Viable Tests), para entender melhor como você pode experimentar antes mesmo de pensar em fazer um MVP.

*Se você não está familiarizado com MVTs, recomendo que leia o artigo de Gagan Biyani “ O Processo de Teste Mínimo Viável para Avaliação de Ideias de Startup ”.

Não ter um limite claro entre MVP e MMP

No início, não sabíamos o que era um MMP (Minimum Marketable Product) e qual era a diferença entre um MVP.

Se você está mais preocupado em receber quando tiver mil usuários do que em ter os primeiros, você deve se questionar se está realmente construindo o produto mínimo viável para testar no mercado ou se está construindo o produto mínimo vender.

Ter uma distinção clara entre ambos é importante. E se você está tentando fazer um MMP sem pensar em testar primeiro o produto no mercado, é provável que esteja investindo muito em algo que não é validado o suficiente.

Acreditar que não existe um MVP menor

Ouvimos muitas partes interessadas antes: se o custo de fazer o MVP é relativamente pequeno, então é um bom MVP.

Essa variável não é boa o suficiente para considerar se um MVP é bom. Você precisa considerar outros aspectos como: Qual é o objetivo do MVP? Podemos obter o mesmo resultado por meio de um pequeno experimento se o definirmos como um MVT? Podemos fazer protótipos e pesquisas para ter uma resposta para o que precisamos aprender?, etc.

Resumindo

Lançar um MVP sempre parece desconfortável para as partes interessadas e para a equipe, porque é uma pequena parte do que poderia ser. Mas lembre-se, como alguém disse uma vez: se você está confortável com seu MVP, então esperou muito para lançá-lo.

Para fazer um MVP real, você precisa estar confortável em fazer concessões ao longo do caminho e criar uma versão simplificada. Caso contrário, você se engana e desperdiça recursos como tempo, dinheiro e energia da equipe.

Se você deseja uma abordagem prática para definir um MVP para maiores chances de sucesso, recomendo este artigo escrito por Martin Ganón , nosso Chief Product Officer aqui na Zeppelin.

Espero que este artigo tenha agregado algum valor!

No Zeppelin Labs, ajudamos fundadores e empresas em crescimento a experimentar e construir produtos digitais diferenciados que impulsionam o crescimento. Você pode nos encontrar aqui . Ou aqui . Ou aqui .

Se você gostaria de se juntar à nossa equipe, envie um email para [email protected]

Gostaria de fazer parceria? envie-nos um e-mail para [email protected]

Subscreva a nossa Newsletter aqui .