Como melhoramos nosso processo de construção de MVP em 300%

Os "300%" é só para fazer um título bonito. Na prática, nunca medimos nosso ganho de eficiência, mas sei que foi grande! :)

O conceito de "Lean Startup" passou de uma metodologia para quase que uma regra nas startups. Alguns chegam a tratar as teorias como verdadeiras receitas de bolo para se chegar ao sucesso, apesar deste não ser o objetivo do autor.

Como cofundador de uma startup (Convenia) sempre estivemos atentos a todas as metodologias que pudessem nos ajudar a crescer em uma velocidade cada vez maior e isso significa ter um produto ideal.

Na busca do desenvolvimento de produto mais assertivo possível, o conceito de MVP (Minimum Viable Product) nos parecia ser o ideal. Afinal de contas tudo fazia muito sentido: construa rápido, para aprender rápido e iterar para um novo produto / funcionalidade com base no que foi aprendido.

Fluxo da Lean Startup

Porém, passamos algum tempo (anos) sem conseguir emplacar um bom processo de construção de MVP. Por algum motivo, que não conseguíamos sequer identificar qual, nossos MVPs se tornavam grande demais (o que levava tempo para construí-lo) ou, quando pronto, não serviam para aprendermos nada. Eram inócuos no objetivo básico de ajudar-nos a andar mais rápido.

Onde estava o nosso erro?

O tempo todo buscávamos entender o que, no nosso processo, estava errado. Cogitamos várias hipóteses:

  1. Nosso time de desenvolvimento produz pouco. — A primeira hipótese é sempre essa. :)
  2. O produto / funcionalidade foi mal desenhado ou projetado.
  3. Nós não somos disciplinados o suficiente para analisar dados.

…e assim por diante…

Nada disso tinha problemas.

Ocorre que estávamos olhando o problema pelo espectro errado: a construção do produto — ou o "build" do fluxo.

Nosso fluxo era:

  1. Construir algo
  2. Medir
  3. Aprender

O problema é que se você não sabe o que MEDIR e o que quer APRENDER, você só sobra com uma coisa: CONSTRUIR. E aí construíamos, não aprendíamos e construíamos de novo… Era enxugar gelo.

Sempre que iniciávamos o processo de construção de uma nova funcionalidade (MVP) começávamos pelo protótipo do que seria feito. ERRADO! Na verdade, deve-se começar pelo aprendizado ("Learn"), ou seja, o que você quer aprender?

Se você quiser sair com um único conceito deste texto, que seja: o importante não é construir bem, mas sim, definir bem a hipótese que deseja testar.

De certa forma, isso parece óbvio mas, na verdade, é muito difícil definir bem uma hipótese. MUITO!

Nosso processo ideal de MVP

Se eu disser que já atingimos o ideal, estaria mentindo. Até hoje nos pegamos deslizando e definindo mal (ou muitas vezes sequer definindo) uma hipótese. Porém, já melhoramos muito e temos visto alguns resultados práticos.

Passo 1) Qual é a dor grande?

A primeira etapa é escolher uma dor grande para se trabalhar. Identifique as dores que o seu produto resolve (ou pretende resolver). Liste as maiores — ou seja, do ponto de vista do seu usuário, quais tem o maior impacto.

Escolha uma delas. Há maneiras de se definir isso através de pesquisas e observação de clientes. Mas, na pior das hipóteses, use seu feeling.

Uma boa maneira de perguntar para seus consumidores é dar opções de dores relacionadas a um tema principal. Nunca faça uma pergunta do tipo "O problema XYZ é uma dor sua?" — Ele sempre dirá que sim. Ao invés disso, pergunte: "Entre as dores 1, 2 e 3, qual você prefere que a gente ataque primeiro?".

Passo 2) Quais são as hipóteses para resolver essa dor?

O segundo passo é listar as opções que você tem para resolver este problema. Note que o seu consumidor não necessariamente sabe as melhores hipóteses para resolver um problema. Ele pode saber identificar uma dor, mas você precisará ser especialista o suficiente para saber listar as maneiras mais inteligentes, inovadoras e eficientes de resolver o problema.

Passo 3) Defina o que você quer aprender e como você vai aprender. — O PASSO MAIS IMPORTANTE

Após identificar a dor que resolverá e as possíveis opções de solução, é hora de separar o que você gostará de aprender com este MVP, ou seja, a definição de uma hipótese.

Note que aqui não estamos listando features. Queremos saber aqui qual é o propósito do nosso MVP.

Um outro ponto importante nesta etapa é identificar COMO você vai aprender, ou seja, quais os KPIs (Key Performance Indicators) que utilizará para medir ou validar a sua hipótese. É imprescindível determinar os indicadores nesta fase, pois conforme as suas escolhas, será preciso incorporá-las nos requisitos da funcionalidade, ou seja, o time de desenvolvimento precisará fazer algo para que você consiga medir corretamente.

Passo 4) Faça o protótipo e defina os requisitos básicos

Ainda não partimos para a construção. Aqui é onde o nosso UX/UI designer trabalha para tentar traduzir a nossa hipótese em uma funcionalidade. O resultado desta etapa é um wireframe e uma lista de requisitos de sistema. Quanto mais detalhado melhor.

Você perceberá como nós ficamos tentados a construir algo maior do que precisamos para testar a hipótese.

Um exercício que fazemos e é bem útil: com o wireframe pronto, repassamos tela a tela e nos perguntamos: "essa tela/botão/campo acrescenta algo para respondermos nossa hipótese?"

Se a resposta for "não", ele deve sair do protótipo. Você verá que aqui está o segredo do MVP enxuto.

Passo 5) Construir

É aqui que a maioria dos materiais se concentra. Landing pages, dummy buttons, features por etapas, tudo isso é válido. Aposto que seu time já seja bom nisso! :)

Resumindo…

Antes de sair construindo, defina o que você quer aprender, qual a hipótese você quer validar.

Não trate o fluxo de MVP proposto pela metodologia "Lean Startup" como um fluxo sem começo. No nosso aprendizado, aprendemos que o que mais funciona para nós é (na ordem):

  1. LEARN — Defina o que quer aprender, hipótese.
  2. DESIGN — Faça o protótipo, de modo que ele seja útil apenas para o que você quer validar.
  3. MEASURE — Com o que foi observado, aprenda para o próximo ciclo.

A mudança é sútil, mas nos trouxe grandes ganhos.

Compartilhe comigo as suas experiências de MVP. Consegue fazer de forma eficiente? Tem algo a acrescentar?

Obrigado pela sua leitura. Se você curtiu aperte o "coração" abaixo do texto. Isso vai significar muito para mim e ainda ajudar a fazer este texto chegar em mais pessoas! :)

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.