Como definir o âmbito de um MVP: reduza a sua primeira versão ao que realmente importa

Quase toda a gente que nos procura com uma ideia de aplicação já construiu a versão completa dela na cabeça. Conseguem descrever o painel, a página de definições, o programa de indicações, o modo escuro. O que normalmente não conseguem dizer é qual a parte concreta desse quadro que, se funcionasse, tornaria o conjunto inteiro digno de ser feito. Definir o âmbito de um MVP é o trabalho pouco glamoroso e um pouco doloroso de encontrar essa única parte — e ter a coragem de deixar o resto para mais tarde.

Já vi muitos primeiros produtos a serem construídos, e os que têm dificuldades quase nunca falham por preguiça da equipa. Falham porque o âmbito estava errado logo na primeira semana. Empacotou-se demasiado na versão um, o orçamento esgotou-se antes de alguém ter aprendido fosse o que fosse e, ao chegar o lançamento, a equipa tinha gasto tudo só para chegar à linha de partida — sem dinheiro para reagir ao que os utilizadores reais de facto faziam.

Por isso, este é o guia que dou às pessoas antes de se escrever uma única linha de código. Não tem a ver com rituais ágeis nem com frameworks sofisticadas. Tem a ver com uma pergunta honesta — qual é a coisa mais pequena que podemos construir para saber se esta ideia é real? — e com a disciplina de continuar a respondê-la enquanto a tentação de acrescentar ‘só mais uma funcionalidade’ volta a surgir. Porque volta sempre a surgir.

O que um MVP é de facto (e o que não é)

A expressão foi gasta pelo uso excessivo, por isso sejamos precisos. Um produto mínimo viável é a versão mais pequena da sua ideia que entrega valor real a um utilizador real e lhe ensina algo que nunca teria aprendido com uma apresentação de diapositivos. A palavra-chave que se esquece é viável. Tem mesmo de funcionar para alguém, de princípio ao fim, mesmo que faça apenas uma coisa.

Eis o que um MVP não é. Não é uma versão a meio do produto completo com cantos partidos por todo o lado. Não é um protótipo que se deita fora. E não é, certamente, ‘a versão barata’ — o baixo custo é um efeito secundário de um bom âmbito, não o objetivo. O objetivo é aprender. Está a gastar o mínimo de dinheiro possível para responder à pergunta mais cara que tem: alguém vai usar isto, e vai usá-lo da forma que penso?

Essa distinção pesa mais do que parece. A mentalidade dos ‘primeiros 20%’ leva a algo que está partido em todas as direções e útil em nenhuma. ‘Uma coisa, bem feita’ leva a algo que uma pessoa pode pegar, usar a sério e formar uma opinião sobre ele. As opiniões são o objetivo inteiro. Não se pode iterar sobre o silêncio.

A armadilha de construir a mais, e porque é tão fácil cair nela

Ninguém se propõe a exceder o âmbito. Acontece uma decisão razoável de cada vez. Acrescenta o início de sessão, porque claro que precisa de contas. As contas implicam um fluxo de reposição de palavra-passe, uma verificação por e-mail e uma página de definições. As definições implicam um perfil, que implica o carregamento de imagens, que implica um sítio onde as guardar. Cada passo é sensato por si só. Empilhados, gastou dois meses e uma fatia do orçamento antes sequer de começar a parte que torna a sua ideia especial.

A outra metade da armadilha é emocional. Cortar funcionalidades parece admitir que a sua ideia é pequena. Não é — é admitir que ainda não sabe quais as funcionalidades que importam, o que é simplesmente a verdade. Cada funcionalidade que constrói antes de ter utilizadores é uma aposta às cegas. Algumas dessas apostas estarão erradas, e as que corta do MVP são as apostas mais baratas para se errar, porque nunca as fez.

Encontre a única tarefa que o seu MVP tem de cumprir

Todo o produto, por maior que acabe por se tornar, tem um ciclo central — a única sequência que um utilizador repete e que cria o valor. Numa aplicação de marcações é encontrar um horário, marcá-lo, ser lembrado. Num marketplace é publicar uma coisa, alguém encontra-a, o dinheiro muda de mãos. Numa ferramenta interna é captar o dado uma vez, usá-lo em todo o lado. Tudo o resto no produto existe para apoiar, decorar ou estender esse ciclo. O seu MVP é o ciclo. Só o ciclo.

Para encontrar o seu, complete esta frase em voz alta: «Um utilizador vem ao meu produto para ______, e fica satisfeito se ______.» O primeiro espaço é a tarefa. O segundo é como saberá que funcionou. Se não conseguir preencher os dois espaços de um só fôlego, ainda não encontrou o núcleo — e não está pronto para definir o âmbito, quanto mais para construir.

Seja implacável com a diferença entre o ciclo central e as coisas que parecem essenciais mas não são. O início de sessão parece essencial. Normalmente não é, na versão um — muitos MVP lançam com uma única ligação partilhada, um convite manual ou sem contas, e aprendem tudo o que precisam antes de construir a maquinaria de autenticação. Os painéis de análise parecem essenciais. Não são; pode ler a base de dados à mão quando tem onze utilizadores. Reduza ao ciclo e ficará espantado com o quanto desaparece.

Distribua cada funcionalidade por tem de, devia e não vai

Depois de nomear o ciclo central, pegue na sua grande lista de funcionalidades e distribua cada uma por três baldes. Os baldes são deliberadamente diretos, porque é a clareza direta que põe fim às intermináveis conversas do ‘mas talvez’.

• Tem de: o ciclo central literalmente não funciona sem ela. Se a retirar, não há produto. Mantenha esta lista chocantemente curta — normalmente três a seis itens.
• Devia: torna o produto melhor, mas o ciclo continua a funcionar sem ela. Tudo o que está aqui espera pela versão dois. Sem exceções na primeira versão.
• Não vai (ainda): as funcionalidades que escolhe conscientemente não construir agora. Escrevê-las importa — é assim que se tranquiliza a si, e à sua equipa, de que a ideia não está a ser abandonada, apenas sequenciada.

O truque que faz isto funcionar é o terceiro balde. A maioria das pessoas só discute entre tem de e devia, o que é extenuante e nunca acaba. A lista do ‘não vai ainda’ é onde mora o alívio — é uma promessa ao seu eu futuro de que a ideia gira está segura e agendada, só que não para já. Quando as pessoas confiam que nada está a ser deitado fora, deixam de lutar para manter tudo na versão um.

Defina o âmbito por tempo e dinheiro, não por lista de funcionalidades

Eis uma mudança discreta que muda tudo: pare de definir o âmbito por ‘o que queremos’ e comece a defini-lo por ‘o que cabe no orçamento e no prazo’. Decida primeiro quanto dinheiro e quantas semanas está disposto a gastar para responder à sua pergunta central. Depois faça a lista de funcionalidades caber dentro dessa caixa. Soa ao contrário, mas é a restrição mais útil que se pode dar, porque força a priorização que de outro modo evitaria.

Uma caixa fixa também faz algo psicológico. Quando o orçamento é em aberto, toda a funcionalidade é discutível e a lista só cresce. Quando a caixa é fixa — digamos, oito semanas e um montante definido — a conversa inverte-se. Deixa de ser ‘devíamos acrescentar isto?’ e passa a ‘o que sai se isto entrar?’. Essa segunda pergunta é a que constrói bons MVP. Os compromissos ficam visíveis em vez de escondidos, e a equipa fá-los de propósito.

Um exemplo real: reduzir o âmbito de uma ideia de gestão de trabalhos

Deixe-me tornar isto concreto com um caso em que trabalhámos — anonimizado, mas fiel à forma como estas coisas correm. Uma pequena empresa de aquecimento e canalização procurou-nos a querer uma aplicação para a sua equipa de terreno. O briefing, no papel, era enorme: agendamento de trabalhos em tempo real, localização por GPS das carrinhas, um portal de clientes, faturação automatizada, inventário das peças em cada veículo, um gerador de orçamentos, documentação fotográfica e um conjunto de relatórios para o dono. Um produto genuinamente útil, a prazo. Como primeira versão, uma forma garantida de gastar o orçamento de um ano antes de aprender fosse o que fosse.

Então fizemos o exercício. Colocámos ao dono a frase: ‘Um utilizador vem a isto para ______, e fica satisfeito se ______.’ Após algum vaivém, a verdadeira resposta veio à tona. A maior dor diária dos técnicos não era o agendamento nem a faturação — era o vaivém da papelada. Acabavam um trabalho, rabiscavam horas e peças numa folha, conduziam de volta, e alguém no escritório voltava a digitar tudo no sistema de contabilidade, muitas vezes dias depois, muitas vezes com erros. O ciclo central era simplesmente: captar o que aconteceu no trabalho, uma única vez, no local, para que ninguém volte a digitá-lo.

O que entrou — e o que não entrou

Tudo foi distribuído. O balde tem de reduziu-se a quatro coisas: uma lista dos trabalhos do dia para cada técnico, um formulário simples para registar horas e peças usadas por trabalho, um anexo de fotografia, e uma forma de o escritório ver esses dados no momento em que eram submetidos. Esse era o MVP inteiro. Sem GPS, sem portal de clientes, sem gerador de orçamentos, sem relatórios sofisticados — tudo isso estacionado, explicitamente, na lista ‘não vai ainda’ com uma nota de que viria a chegar.

Construímos esse núcleo numa mão-cheia de semanas em vez da maior parte de um ano. E eis a parte que justifica toda a abordagem: uma vez no ar, as prioridades reais da equipa revelaram-se diferentes do briefing. O dono tinha assumido que a localização por GPS seria a seguir; os técnicos mal a mencionaram. O que queriam, em alto e bom som, era enviar ao cliente por mensagem uma janela de chegada a partir de dentro da aplicação — uma funcionalidade que nem sequer constava da lista original. Como o MVP era pequeno e barato, sobrou orçamento para construir aquilo que realmente queriam, em vez daquilo que tinham adivinhado meses antes.

Os erros que arruínam em silêncio o âmbito de um MVP

Até as equipas que aderem ao ‘mantém pequeno’ tendem a tropeçar nas mesmas poucas coisas. Nenhuma é dramática. São fugas lentas que voltam a inchar o âmbito enquanto não está a olhar, até que um dia o produto ‘mínimo’ tem outra vez trinta ecrãs e um prazo de seis meses.

• Polir os bordos em excesso: passar dias a aperfeiçoar um painel de administração que só você verá, enquanto o ciclo central ainda está em bruto. Pula o que os utilizadores tocam; deixe a retaguarda feia e funcional.
• Construir para uma escala que não tem: arquitetar para um milhão de utilizadores quando precisa de provar que os primeiros dez voltarão. Resolva o problema da escala quando tiver o bom problema da escala.
• Confundir ‘indispensável’ com ‘padrão do setor’: só porque cada concorrente tem a funcionalidade X não significa que o seu MVP precise dela para testar a sua ideia central. Não está a lançar um produto acabado, está a fazer uma experiência.
• Desenhar todos os casos extremos à partida: tratar as entradas raras e estranhas antes de saber se alguém usa o caminho comum e normal. Deixe o uso real dizer-lhe quais os casos extremos que sequer são reais.
• Sem definição de concluído: sem uma linha escrita que descreva como é ‘terminado’, a construção nunca acaba. O alargamento do âmbito adora um projeto sem linha de chegada.

Se só se proteger de um deles, que seja o último. Uma definição de concluído clara e escrita — ‘um técnico consegue registar as horas e peças de um trabalho no telemóvel, e o escritório vê isso de imediato’ — é a ferramenta mais poderosa para manter o âmbito honesto. Cada acréscimo proposto é confrontado com essa frase. Se não serve a frase, é uma ideia de versão dois, por melhor que seja.

Um processo simples para definir o âmbito do seu MVP

Juntando tudo, eis a sequência que percorreria com qualquer pessoa antes de começar uma primeira versão. É deliberadamente pouco técnica — a maior parte pode fazê-la com um documento e uma conversa honesta, muito antes de precisar de um programador na sala.

1. 1
   Nomeie o ciclo central

   Complete a frase: ‘Um utilizador vem para ___, e fica satisfeito se ___.’ Se não conseguir, não está pronto para definir o âmbito — continue a falar até a verdadeira tarefa emergir.
2. 2
   Despeje cada funcionalidade e depois distribua

   Tire toda a lista de desejos da cabeça e ponha-a no papel. Distribua cada item por tem de, devia ou não-vai-ainda. Mantenha a lista ‘tem de’ brutalmente curta.
3. 3
   Fixe a caixa

   Decida o orçamento e o prazo antes de finalizar a lista de funcionalidades. Faça a lista caber na caixa, não o contrário.
4. 4
   Escreva a definição de concluído

   Uma frase concreta a descrever o ciclo central a funcionar. É o seu escudo contra o alargamento do âmbito durante o resto do projeto.
5. 5
   Construa, lance, observe e depois decida

   Ponha o núcleo à frente de utilizadores reais. Observe o que de facto fazem. Deixe o comportamento deles — e não as suas suposições anteriores — escolher o que sai a seguir da lista ‘devia’.

Repare que o último passo o devolve ao início. Um bom MVP não é um acontecimento único, é a primeira volta de uma roda. Define um âmbito pequeno, lança, aprende, e o que aprende redefine o âmbito da versão seguinte. As equipas que vencem não são as que planearam o produto perfeito à partida — ninguém o faz. São as que puseram algo real à frente dos utilizadores depressa o suficiente para que a realidade ainda os pudesse orientar.

Perguntas frequentes