Priorização MoSCoW:80 ideias de funcionalidades, constrói 5

Tens 80 ideias de funcionalidades — 50 tuas e mais 30 sugeridas pelos teus utilizadores. A priorização MoSCoW — Must have, Should have, Could have, Won't have (tem de ter, devia ter, podia ter, não vai ter) — reduz essas 80 ideias às 5 ou menos funcionalidades que realmente testam a tua hipótese. Tudo o resto é distração, e a maior parte pertence ao Won't have.

Além das tuas 80, os concorrentes têm outras 20 funcionalidades que tu não tens. Não as consegues construir todas, nem deves. Eis o método para cortar sem piedade — a pergunta de teste de cada categoria, como é uma boa e uma má priorização em prazos reais, e a regra que te impede de construir coisas que podias simplesmente fazer à mão.

O que é a priorização MoSCoW para MVPs?

O MoSCoW arruma cada funcionalidade num de quatro grupos, cada um com uma única pergunta de teste. Responde com honestidade e a lista de 80 itens desaba por si:

Repara no que chumba no teste do Must have nesse exemplo. Níveis de prioridade? Os utilizadores podem reordenar a lista à mão. Categorias e etiquetas? Simpático, não essencial. Tarefas recorrentes? Podem ser criadas à mão. Uma funcionalidade não é Must have por ser útil — é Must have porque a tua hipótese não pode ser testada sem ela.

Não estás a construir um produto mínimo viável

Estás a construir um produto mínimo testável. Essa mudança de perspetiva muda tudo, porque ancora cada decisão de priorização na tua hipótese e não na tua visão. A visão é para a versão 10. Se não consegues enunciar a tua hipótese numa frase, para e resolve isso primeiro — ela sai diretamente do trabalho de validação que fizeste antes de decidires construir o que quer que fosse.

E é no Won't have que vive a disciplina. Não é um backlog — é uma lista de funcionalidades que estás ativamente a decidir não construir, cada uma com um gatilho escrito para a reconsiderar: depois de 100 utilizadores, depois de a V1 estar provada, ou se os utilizadores a pedirem cinco ou mais vezes. Escrever o gatilho é o que impede a funcionalidade de voltar sorrateiramente ao âmbito na segunda semana.

12 semanasA tua carreira corporativa nunca foi o planoCandidata-te ao Solopreneur Accelerator.Candidatar-me →

A segunda passagem: impacto versus esforço

O MoSCoW leva-te de 80 a uma lista curta. A matriz impacto-versus-esforço leva-te a cinco. Avalia cada funcionalidade sobrevivente em duas dimensões — quanto ajuda o utilizador (1–10) e quantos dias demora honestamente a construir — e surgem quatro quadrantes:

• Vitórias rápidas (alto impacto, baixo esforço): são o teu MVP.
• Grandes projetos (alto impacto, alto esforço): faz estes depois da validação, nunca antes.
• Enchimentos (baixo impacto, baixo esforço): acabamentos, só se houver tempo.
• Desperdícios de tempo (baixo impacto, alto esforço): nunca os construas — o motor de relatórios personalizado que dois utilizadores talvez queiram, a funcionalidade de IA que ninguém pediu, permissões complexas para casos extremos.

Desconfia dos teus próprios números. Os fundadores subestimam sistematicamente o esforço e sobrestimam o impacto — por isso acrescenta uma margem de 50% a cada estimativa, contesta cada nota de impacto de 9 em 10 e mantém o tempo total de construção abaixo das quatro semanas.

Faz à mão antes de construíres

Para cada funcionalidade que sobrevive, faz mais uma pergunta: consigo fazer isto à mão para os primeiros 10 utilizadores? Se sim, não a construas ainda. Envia tu as notificações por email. Faz o relatório semanal numa folha de cálculo. Integra cada utilizador numa chamada pessoal. Fatura à mão. Importa tu o CSV deles.

Começar à mão permite lançar mais depressa, ensina-te o que os utilizadores realmente precisam em vez do que dizem precisar e cria relações com os primeiros utilizadores, que são os que mais contam. E é um teste de procura disfarçado: se não te dás ao trabalho de fazer algo à mão para 10 utilizadores, porque o construirias para 1.000? Só automatizes quando já fizeste a tarefa à mão mais de 10 vezes, ela demora mais de 30 minutos de cada vez, o padrão é consistente e os utilizadores a pedem explicitamente.

Como é uma boa e uma má priorização

A mesma ideia de gestor de tarefas, duas decisões de âmbito. A versão má: tarefas recorrentes, subtarefas, etiquetas e categorias, registo de tempo, partilha em equipa, uma app móvel, vista de calendário, diagramas de Gantt — 90 dias a construir. A versão boa: criar tarefa, definir prazo, marcar como concluída, vista de lista simples e um resumo diário por email enviado à mão aos primeiros 10 utilizadores — 14 dias. Lançado em duas semanas em vez de três meses.

De qualquer forma, o verdadeiro custo não são as funcionalidades cortadas — é a aprendizagem perdida. Um CRM para freelancers, cortado de um plano de oito funcionalidades e 120 dias para cinco funcionalidades (adicionar contacto, adicionar notas, etiquetar o estado, pesquisa simples, exportação manual para CSV), foi lançado em 21 dias, e os utilizadores revelaram algo que nenhum roteiro previa: não queriam gestão de projetos nenhuma, queriam lembretes de seguimento. Um construtor de landing pages, cortado de um plano de 60 dias para cinco modelos, texto editável e um formulário básico, aprendeu que os utilizadores queriam mais modelos, não personalização. Noventa dias extra de construção teriam sido noventa dias a construir a coisa errada.

As cinco armadilhas que voltam a encher o teu âmbito

1. «Mas isto é essencial para a nossa visão.» A visão é para a V10. O que é essencial para testar a hipótese?
2. «Os utilizadores falaram nisto.» Que utilizadores? Quão doloroso é? Vão pagar? Uma pessoa pronta a pagar vale mais do que dez sugestões do tipo «não seria giro se…».
3. «São só mais dois dias.» Dois dias tornam-se duas semanas com a depuração. Corta; acrescenta mais tarde se ficar provado que é preciso.
4. «Os concorrentes têm isso.» Levaram anos a construí-lo. Tu estás a testar, não a competir.
5. «Não podemos lançar sem isto.» Podes, sim. Qual é o mínimo absoluto?

Se a tua lista final tiver mais de cinco funcionalidades, ainda não acabaste de cortar. A melhor funcionalidade é a que não constróis: cada corte lança mais depressa, aprende mais depressa, custa menos e é mais fácil de manter. O teu objetivo não é construir um produto. O teu objetivo é testar uma hipótese.

O livroThe Solopreneur RevolutionLuis Gonçalves sobre como construir um negócio de EUpreendedor com IA sem deixar o emprego.Quero o livro →

Perguntas frequentes

O que significa MoSCoW?

Must have, Should have, Could have, Won't have — tem de ter, devia ter, podia ter, não vai ter. Cada categoria tem um teste: Must have significa que a hipótese não pode ser testada sem ela; Should have significa que os primeiros utilizadores continuariam a usar o produto sem ela; Could have significa que ninguém deixaria de usar o produto se ela faltasse; Won't have significa que distrai do valor central e é cortada explicitamente.

Quantas funcionalidades deve ter um MVP?

Cinco ou menos. Se a tua lista for mais longa, ainda não acabaste de cortar. Mantém o tempo total de construção abaixo das quatro semanas, acrescenta uma margem de 50% a cada estimativa de esforço e contesta cada «must have» — a maioria das funcionalidades pertence ao Won't have.

Qual é a diferença entre Must have e Should have?

Um Must have é uma funcionalidade sem a qual não consegues testar o teu pressuposto central — retira-a e a experiência morre. Um Should have melhora bastante a experiência, mas os primeiros utilizadores continuariam a usar o produto sem ele, por isso espera até depois da validação da V1.

Quando devo automatizar um processo manual?

Só quando já o fizeste à mão mais de 10 vezes, demora mais de 30 minutos de cada vez, o padrão é claro e consistente e os utilizadores pedem explicitamente a automação. Até lá, o trabalho manual é mais barato do que código — e ensina-te o que os utilizadores realmente precisam.