Priorização de features: decidindo o que construir primeiro

A fundadora chegou ao kickoff com uma planilha. Quarenta e uma linhas, uma feature em cada, todas marcadas como “obrigatória”. Ela estava construindo uma ferramenta de agendamento e pagamentos para uma pequena rede de pet shops de banho e tosa, tinha demanda real, e tinha um orçamento que cobria talvez oito das quarenta e uma. Quando perguntei quais oito, ela disse que todas eram essenciais. Esse é o momento em que a priorização de features de fato começa, e é o momento em que a maioria dos founders trava.

Priorização de features é decidir quais features construir primeiro, e quais cortar ou adiar, quando você não pode construir tudo de uma vez. Todo guia na primeira página do Google vai te entregar um framework de pontuação para isso: RICE, MoSCoW, Kano, matrizes ponderadas. Esses frameworks são reais e funcionam, mas foram feitos para product managers que já têm um produto, dados de uso e um time. Como founder não técnico no começo, você tem uma lista de desejos, um orçamento fixo e nenhum dado ainda. Seu problema não é a conta. É o travamento.

Por que os frameworks não resolvem o seu problema de verdade

Um framework de pontuação pega uma lista de features e as ordena por alguma combinação de valor e custo. O RICE, método que a Intercom popularizou, multiplica alcance, impacto e confiança, e divide pelo esforço. O MoSCoW separa tudo em obrigatória, importante, desejável e fora de escopo. São genuinamente úteis quando você tem os insumos de que precisam.

A pegadinha é que os insumos são a parte difícil, e no começo você não os tem. Alcance e impacto são estimativas de quantos usuários uma feature atinge e quanto ela move uma métrica. Você tem zero usuários e nenhum histórico de métrica, então todo número que você coloca é um chute disfarçado de aritmética. O framework então lava o seu chute num score de aparência confiante, e você toma uma decisão de build de seis dígitos sobre um número que inventou. Isso é pior do que nenhum framework, porque parece rigoroso.

Então o trabalho de verdade acontece antes da matriz. Priorização no começo não é um cálculo. É uma decisão sobre o que você está disposto a lançar sem ter. Até você tomar essa decisão com honestidade, nenhum framework vai te salvar, e depois que você a toma, você quase não precisa de um.

O método de priorização do founder

Eis o que de fato rodamos com founders antes de alguém abrir uma planilha de pontuação. Quatro perguntas, feitas a cada feature da lista.

Primeira: essa feature faz alguém pagar, ou faz alguém ficar? Não “é legal”. Não “um usuário ia gostar”. Ela faz uma pessoa colocar um cartão, ou voltar na semana seguinte? O fluxo de agendamento dos pet shops fazia os donos pagarem porque substituía um sistema de telefone e caderninho que perdia horários. O módulo de pontos de fidelidade não fazia nem uma coisa nem outra no lançamento. Um era de dia um; o outro podia esperar um ano.

Segunda: se você a removesse, o trabalho central quebraria? Todo produto faz um trabalho principal. Para a ferramenta dos pet shops, o trabalho era “receber um agendamento e ser pago sem uma ligação”. Remova os pagamentos online e o trabalho quebra. Remova a agenda de disponibilidade dos profissionais e o trabalho quebra. Remova os recibos por e-mail personalizáveis e o trabalho continua de pé, o recibo só fica mais simples. Features que quebram o trabalho central quando removidas não são negociáveis. Todo o resto é.

Terceira: a demanda é real, ou é o cliente mais barulhento? Founders consistentemente dão peso demais ao único cliente que manda três e-mails sobre uma feature específica. Esse cliente não é o seu roadmap. Ele é uma voz, muitas vezes a menos representativa, e construir a feature de estimação dele primeiro é como você acaba com um software no formato do seu cliente mais exigente em vez do seu mercado. Pergunte quantas pessoas pediram, espontaneamente, a mesma coisa. Uma é ruído. Oito é sinal.

Quarta: dá para esperar até os usuários te dizerem? A feature mais barata é a que você não constrói porque o uso real deixou óbvio que você não precisava dela. Se uma feature não é de dia um e não quebra o trabalho central, o movimento certo costuma ser lançar sem ela e deixar os usuários reais te dizerem se ela importa. Eles vão dizer, e vão ser mais honestos do que a sua planilha.

Rode essas quatro perguntas e as quarenta e uma linhas se ordenam em três pilhas: construir agora, construir depois e provavelmente nunca. A fundadora da ferramenta de tosa terminou com nove features na pilha “construir agora”, não quarenta e uma, e as nove eram as que faziam os donos pagarem. Lançamos em dez semanas em vez de oito meses, e o módulo de fidelidade que ela havia marcado como obrigatório nunca foi construído, porque, uma vez que os donos estavam no ar, nenhum deles pediu por ele.

As quarenta e uma linhas, ordenadas

Ajuda ver o método rodando contra linhas reais, porque a versão abstrata faz toda feature soar igualmente importante e a concreta não. Seis dos itens dela, e onde cada um foi parar:

Agendamento online com disponibilidade ao vivo foi para o construir-agora. Fazia os donos pagarem (era a razão de trocarem o telefone) e removê-lo quebrava o trabalho central. Pagamento por cartão no agendamento: construir-agora, mesma lógica, já que “ser pago sem uma ligação” era metade do trabalho. Uma agenda com horários por profissional: construir-agora, porque um agendamento que marca dois clientes para o mesmo profissional é pior do que nenhum agendamento.

Aí a linha se moveu. Lembretes automáticos por SMS: construir-depois. Os donos queriam e eles reduzem faltas, mas a ferramenta funcionava sem eles no lançamento, e dava para ver as taxas reais de falta antes de gastar com isso. Recibos por e-mail personalizados e com a marca: construir-depois beirando o nunca, porque um recibo simples faz o trabalho e a personalização era gosto, não receita. O motor de pontos de fidelidade: provavelmente-nunca, o item mais caro da lista, marcado como obrigatório por instinto, pedido por nenhum dono de pet shop de verdade depois que estavam no ar.

A questão não é que pontos de fidelidade sejam ruins. É que a fundadora os havia colocado com o mesmo peso de ser paga, porque uma lista de desejos achata tudo em “querer”. As quatro perguntas desachatam. Elas transformam quarenta e um desejos iguais em nove coisas de que o produto precisa para fazer seu trabalho e trinta e duas coisas que podem provar que importam depois.

Todo sim é um não em algum outro lugar

A razão de a priorização ser dolorosa é que os founders a vivem como adição. Cada feature é algo que eles querem, e cortar parece perda. O reframe que ajuda é enxergar priorização como subtração contra um número fixo.

Você tem um orçamento. Seja quanto custa construir o app ou as semanas de tempo do seu único desenvolvedor, ele é finito, e compra uma quantidade fixa de build. Toda feature à qual você diz sim é uma feature, ou uma semana, à qual você disse não em algum outro lugar. O módulo de fidelidade não é de graça mesmo que você o ame. Ele custa o fluxo de onboarding que você não poliu, ou as três semanas que você não gastou na coisa que de fato faz os donos pagarem. Quando um founder vê a lista como um orçamento sendo gasto em vez de uma lista de desejos sendo concedida, os cortes ficam mais fáceis, porque agora ele está trocando, não perdendo.

Essa é também a disciplina que impede o feature creep de comer o build. O creep acontece quando novas features são adicionadas sem que nada seja removido para pagá-las. Um founder que prioriza por subtração tem uma resposta pronta para o pedido de “será que dá para adicionar também” no meio do build: claro, e o que sai para abrir espaço.

Há mais uma armadilha que vale nomear, porque ela pega founders afiados em especial. Algumas features são priorizadas não por um cliente, mas por uma plateia: o dashboard bonito que fica ótimo numa demo de captação, a feature de IA adicionada porque um conselheiro perguntou se você tem uma. Querer lançar algo crível para investidores no próximo trimestre é uma pressão real, e às vezes a feature de demo vale mesmo. Mas passe-a pelas mesmas quatro perguntas, com honestidade. Se uma feature só faz um investidor acenar com a cabeça e nunca faz um cliente pagar ou ficar, ela é um custo de marketing fantasiado de produto, e deveria ser orçada como tal, não contrabandeada para o topo da lista de build.

Quando os frameworks finalmente ganham seu lugar

Nada disso significa que RICE e MoSCoW são inúteis. Significa que são ferramentas de etapa posterior, e você as pega no momento certo, não no primeiro.

O momento é quando você tem usuários. Quando seu produto está no ar e as pessoas o usam, você finalmente tem os insumos para os quais os frameworks foram desenhados: alcance real, impacto observado, evidência em vez de chute. É aí que uma matriz de pontuação para de lavar os seus chutes e passa a organizar a sua evidência. Um founder com três meses de dados de uso e um backlog de quarenta pedidos deveria absolutamente rodar RICE sobre eles. Um founder no kickoff sem usuários deveria rodar as quatro perguntas e resistir à vontade de vestir um chute de score.

O arco é simples. Antes do lançamento, priorize por julgamento, contra o trabalho e o orçamento. Depois do lançamento, priorize por dados, com o framework que servir ao seu time. O erro é usar o segundo método quando você ainda está na primeira situação. Essa é a mesma disciplina por trás de lançar um produto mínimo viável de verdade e saber onde gastar o capricho num minimum lovable product: decida para que serve a primeira versão de fato, e deixe todo o resto esperar a vez.

Como dizer não sem perder o cliente

O último medo que os founders levantam é que cortar features vai custar o cliente que as queria. Em geral não vai, se você lida bem com o não. “Não vamos construir isso” cai mal. “Está na lista, e aqui está por que fica depois das coisas que te colocam no ar mais rápido” cai bem, porque mostra ao cliente que ele está numa sequência, não no lixo. As pessoas aceitam ficar para depois muito mais facilmente do que aceitam ser ignoradas, e um founder que consegue explicar a ordem do build soa como alguém no controle dele.

A fundadora dos pet shops ainda tem aquela planilha de quarenta e uma linhas. A maior parte está nas colunas “depois” e “nunca” agora, anotada com qual cliente real pediu e quantas vezes. Acabou virando um roadmap melhor do que o original, porque cada item nele havia ganhado seu lugar em vez de começar lá.

Perguntas frequentes

O que é o método de priorização de features? É o processo de decidir quais features de produto construir primeiro, e quais adiar ou cortar, quando você não pode construir tudo de uma vez. No começo, antes de ter dados de uso, é um julgamento contra o trabalho central do produto e o seu orçamento, não um exercício de pontuação.

Quais são os 4 níveis de priorização? O esquema de quatro níveis mais comum é o MoSCoW: obrigatória (o produto quebra sem ela), importante (relevante mas não vital no lançamento), desejável (boa se houver espaço) e fora de escopo (explicitamente de fora por ora).

Quais são os quatro métodos de priorização? Métodos muito usados incluem RICE (alcance, impacto, confiança, esforço), MoSCoW, o modelo Kano (features básicas, de performance e de encantamento) e uma matriz simples de valor versus esforço. Eles funcionam melhor quando você tem dados de uso reais para alimentá-los.

Qual é o objetivo principal da priorização de features? Gastar um orçamento e um cronograma finitos nas features que de fato fazem um cliente pagar ou ficar, e adiar o resto, para que a primeira versão faça bem o seu trabalho central em vez de fazer muitas coisas mal.