Priorização MoSCoW:80 ideias de funcionalidade, construa 5

Você tem 80 ideias de funcionalidade — 50 suas e mais 30 sugeridas pelos seus usuários. A priorização MoSCoW — Must have, Should have, Could have, Won't have (tem que ter, deveria ter, poderia ter, não vai ter) — reduz essas 80 ideias às 5 ou menos funcionalidades que realmente testam a sua hipótese. Todo o resto é distração, e a maior parte pertence ao Won't have.

Além das suas 80, os concorrentes têm outras 20 funcionalidades que você não tem. Você não consegue construir todas, e nem deveria. Aqui está o framework para cortar sem dó — a pergunta de teste de cada categoria, como é uma boa e uma má priorização em cronogramas reais, e a regra que te impede de construir coisas que você poderia simplesmente fazer à mão.

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

O MoSCoW distribui cada funcionalidade em uma de quatro caixas, cada uma com uma única pergunta de teste. Responda com honestidade e a lista de 80 itens desmorona sozinha:

Repare no que reprova no teste do Must have nesse exemplo. Níveis de prioridade? Os usuários podem reordenar a lista manualmente. Categorias e tags? Legal, mas não é central. Tarefas recorrentes? Dá para criá-las à mão. Uma funcionalidade não é Must have porque é útil — é Must have porque a sua hipótese não pode ser testada sem ela.

Você não está construindo um produto mínimo viável

Você está construindo um produto mínimo testável. Essa mudança de enquadramento muda tudo, porque ancora cada decisão de priorização na sua hipótese, e não na sua visão. Visão é para a versão 10. Se você não consegue enunciar a sua hipótese numa frase, pare e resolva isso primeiro — ela sai diretamente do trabalho de validação que você fez antes de decidir construir qualquer coisa.

E é no Won't have que mora a disciplina. Não é um backlog — é uma lista de funcionalidades que você está decidindo ativamente não construir, cada uma com um gatilho escrito para ser reconsiderada: depois de 100 usuários, depois que a V1 for comprovada, ou se os usuários pedirem cinco ou mais vezes. Escrever o gatilho é o que impede a funcionalidade de voltar sorrateiramente para o escopo na segunda semana.

12 semanasA sua carreira corporativa nunca foi o planoCandidate-se à Aceleradora de EUpreendedores.Candidatar-se →

A segunda passada: impacto versus esforço

O MoSCoW te leva de 80 para uma lista curta. A matriz de impacto versus esforço te leva a cinco. Avalie cada funcionalidade sobrevivente em duas dimensões — o quanto ela ajuda o usuário (de 1 a 10) e quantos dias ela leva, honestamente, para ser construída — e quatro quadrantes aparecem:

• Vitórias rápidas (alto impacto, baixo esforço): este é o seu MVP.
• Grandes projetos (alto impacto, alto esforço): faça depois da validação, nunca antes.
• Complementos (baixo impacto, baixo esforço): acabamento, só se sobrar tempo.
• Perdas de tempo (baixo impacto, alto esforço): nunca construa — o motor de relatórios personalizados que dois usuários talvez queiram, a funcionalidade de IA que ninguém pediu, permissões complexas para casos extremos.

Desconfie dos seus próprios números. Fundadores sistematicamente subestimam o esforço e superestimam o impacto — então adicione uma margem de 50% a cada estimativa, questione toda nota de impacto 9 de 10 e mantenha o tempo total de construção abaixo de quatro semanas.

Faça manualmente antes de construir

Para cada funcionalidade que sobreviver, faça mais uma pergunta: consigo fazer isso manualmente para os primeiros 10 usuários? Se sim, não construa ainda. Mande as notificações por e-mail você mesmo. Monte o relatório semanal numa planilha. Faça o onboarding de cada usuário numa call pessoal. Emita as faturas à mão. Importe o CSV deles por eles.

Começar pelo manual lança mais rápido, te ensina o que os usuários realmente precisam, e não o que eles dizem que precisam, e constrói relacionamento com os primeiros usuários, que são os que mais importam. E é um teste de demanda disfarçado: se você não se dá ao trabalho de fazer algo manualmente para 10 usuários, por que construir para 1.000? Só automatize quando já tiver feito a tarefa manualmente mais de 10 vezes, ela levar mais de 30 minutos a cada vez, o padrão for consistente e os usuários pedirem explicitamente.

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

A mesma ideia de gerenciador de tarefas, duas decisões de escopo. A versão ruim: tarefas recorrentes, subtarefas, tags e categorias, controle de horas, compartilhamento em equipe, app mobile, visualização em calendário, gráficos de Gantt — 90 dias para construir. A versão boa: criar tarefa, definir prazo, marcar como concluída, visualização simples em lista e um resumo diário por e-mail enviado manualmente para os 10 primeiros usuários — 14 dias. Lançado em duas semanas em vez de três meses.

De qualquer forma, o custo real não são as funcionalidades cortadas — é o aprendizado perdido. Um CRM para freelancers, cortado de um plano de oito funcionalidades e 120 dias para cinco funcionalidades (adicionar contato, adicionar notas, marcar status, busca simples, exportação manual em CSV), foi lançado em 21 dias, e os usuários revelaram algo que nenhum roadmap previu: eles não queriam gestão de projetos, queriam lembretes de follow-up. Um construtor de landing pages, cortado de um plano de 60 dias para cinco templates, texto editável e um formulário básico, descobriu que os usuários queriam mais templates, não personalização. Noventa dias a mais de construção teriam sido noventa dias construindo a coisa errada.

As cinco armadilhas que enchem o seu escopo de novo

1. "Mas isso é central para a nossa visão." Visão é para a V10. O que é central para testar a hipótese?
2. "Os usuários mencionaram isso." Quais usuários? Quão doloroso é? Eles vão pagar? Uma pessoa pronta para pagar vale mais do que dez sugestões do tipo "não seria legal se…".
3. "São só dois dias a mais." Dois dias viram duas semanas com a depuração. Corte; adicione depois, se for comprovadamente necessário.
4. "Os concorrentes têm." Eles levaram anos construindo isso. Você está testando, não competindo.
5. "A gente não pode lançar sem isso." Pode, sim. Qual é o mínimo absoluto?

Se a sua lista final tem mais de cinco funcionalidades, você ainda não terminou de cortar. A melhor funcionalidade é a que você não constrói: cada corte lança mais rápido, aprende mais rápido, custa menos e dá menos manutenção. O seu objetivo não é construir um produto. O seu objetivo é testar uma hipótese.

O livroA Revolução do EUpreendedorLuis Gonçalves sobre como construir um negócio de EUpreendedor com IA sem largar o emprego.Quero o livro →

Perguntas frequentes

O que significa MoSCoW?

Must have, Should have, Could have, Won't have — tem que ter, deveria ter, poderia ter, não vai ter. Cada categoria tem um teste: Must have significa que a hipótese não pode ser testada sem aquilo; Should have significa que os early adopters ainda usariam o produto sem aquilo; Could have significa que ninguém deixaria de usar o produto se aquilo faltasse; Won't have significa que tira o foco do valor central e é cortado explicitamente.

Quantas funcionalidades um MVP deve ter?

Cinco ou menos. Se a sua lista é maior, você ainda não terminou de cortar. Mantenha o tempo total de construção abaixo de quatro semanas, adicione uma margem de 50% a cada estimativa de esforço e questione todo "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 você não consegue testar a sua premissa central — tire-a e o experimento morre. Um Should have melhora bastante a experiência, mas os early adopters ainda usariam o produto sem ele, então ele espera até depois da validação da V1.

Quando devo automatizar um processo manual?

Só quando você já o fez manualmente mais de 10 vezes, ele leva mais de 30 minutos a cada vez, o padrão é claro e consistente e os usuários pedem a automação explicitamente. Até lá, trabalho manual é mais barato do que código — e te ensina o que os usuários realmente precisam.