Você Continua Criando Features que Ninguém Pediu. É um Problema de Estação 3.

O Cemitério de Features

Você conhece aquela sensação de aperto no estômago.

Você passou três semanas construindo uma feature. Talvez fosse um botão de exportar para CSV, um dashboard com seis novos gráficos, ou uma integração com Slack que você tinha certeza que as pessoas queriam. Você lançou. Anunciou. E depois... silêncio total.

Alguns "que legal!" educados. Zero uso de verdade.

Aí você faz o que todo founder faz: culpa o processo. "Preciso de um roadmap melhor." "Deveria usar aquele framework de priorização — ICE? RICE? Sei lá qual sigla é essa." "Talvez eu precise fazer mais entrevistas com usuários."

Você instala uma ferramenta de gestão de projetos. Cria uma matriz de pontuação. Se sente organizado. E dois meses depois, está olhando para outro cemitério de features, se perguntando por que aconteceu de novo.

Eis a questão: seu roadmap não está quebrado. O que está quebrado é o seu entendimento de para quem você está construindo.

Isso não é um problema de priorização. É um problema de Persona.

O Que a Estação 3 Realmente Significa

No framework Clari Station, a Estação 3 é a de Personas — e é uma das estações que mais vejo sendo pulada. Não porque os founders não se importam com seus usuários, mas porque acham que já os conhecem.

"Minha persona? Fácil. Donos de pequenos negócios que precisam de software de faturamento."

Isso não é uma persona. Isso é uma categoria de censo.

Uma persona de verdade responde perguntas como:

Qual frustração específica fez essa pessoa pesquisar no Google uma solução às 23h?
O que ela já tentou (e por que não funcionou)?
Como é o dia a dia dela quando esbarra no problema que você resolve?
Do que ela não se importa, mesmo que pareça que deveria?
Qual o nível técnico dela? Quanto tempo ela tem disponível? Como ela toma decisões de compra?

Quando você pula esse trabalho — ou faz de forma superficial — cada decisão seguinte vira cara ou coroa. Inclusive quais features construir.

O Efeito Cascata que Ninguém Comenta

Veja o que realmente acontece quando suas personas são fracas:

1. Todo pedido de cliente parece igualmente válido.

Um designer freelancer pede uma visualização Kanban. Um dono de agência pede permissões de equipe. Um consultor de marketing pede relatórios para apresentar a clientes. Sem personas claras, os três pedidos entram no seu backlog com o mesmo peso. Afinal, todos são "clientes", certo?

Mas se sua persona real é o designer freelancer solo, permissões de equipe e relatórios para clientes são distrações. São features para um negócio que você não está tocando. Construí-las não só desperdiça tempo — piora o produto para quem ele realmente serve.

2. Você otimiza para volume de feedback, não qualidade do sinal.

Personas fracas te transformam em um agradador de gregos. Você ouve um pedido três vezes e pensa: "Três pessoas pediram isso — deve ser importante!" Mas essas três pessoas eram seus usuários ideais? Ou eram casos isolados que se cadastraram, mexeram um pouco e teriam cancelado de qualquer jeito?

Três pedidos vindos da sua persona principal são um sinal. Três pedidos de usuários aleatórios são ruído. Você não consegue diferenciar sem saber quem é sua persona principal.

3. Seu roadmap vira um backlog Frankenstein.

Sem um filtro de persona, seu backlog cresce em todas as direções. Features para grandes empresas ao lado de features para consumidor final. Ferramentas para power users ao lado de simplificações de onboarding. Seu produto começa a parecer inchado e confuso — não porque você construiu features ruins, mas porque construiu features para cinco pessoas diferentes em vez de uma só.

4. Você perde o fio da sua proposta de valor.

É aqui que o efeito cascata fica realmente perigoso. A Estação 3 (Personas) alimenta diretamente a Estação 4 (Proposta — sua proposta de valor). Se você não sabe para quem está atendendo, não consegue explicar por que essa pessoa deveria escolher você. E se não consegue explicar isso, seu marketing fica vago, suas conversas de venda ficam sem foco, e seu posicionamento vira "a gente faz um pouco de tudo".

Excesso de features não é só um problema de produto. É uma crise de identidade do negócio.

A Armadilha do "Mas Meus Usuários São Diversos"

Escuto isso o tempo todo: "Mas eu tenho tipos diferentes de usuários! Não posso simplesmente escolher um."

Pode sim. E deveria — especialmente no começo.

Isso não significa que você vai atender apenas um tipo de pessoa para sempre. Significa que você precisa de uma persona principal — a pessoa para quem seu produto é obsessivamente desenhado agora. Todo o resto é consideração secundária.

Veja como os melhores produtos começaram:

O Slack começou para equipes internas de uma empresa de games. Não "todas as empresas".
O Dropbox começou para pessoas antenadas em tecnologia que queriam sincronizar arquivos entre dispositivos. Não "gestão de arquivos corporativa".
O Basecamp começou para equipes pequenas que odiavam software de gestão de projetos. Não "qualquer um que gerencia projetos".

Eles expandiram depois. Mas começaram com uma clareza dolorosa sobre para quem estavam construindo.

Quando você tenta atender todo mundo desde o dia um, acaba construindo um produto mediano para um público borrado. Quando você escolhe uma persona e vai fundo nela, constrói algo que parece ter sido feito especificamente para ela. E é isso que faz as pessoas indicarem para os amigos.

Como Consertar Isso de Verdade

Ok, suas personas estão fracas. O que fazer? Aqui vai uma abordagem prática:

Passo 1: Olhe para quem realmente usa (e ama) seu produto

Esqueça quem você gostaria que fossem seus usuários. Olhe para quem realmente está ficando. Quem usa seu produto com mais frequência? Quem tirou mais valor dele? Se você tem 50 usuários e 5 deles são power users, vá estudar esses 5.

Se você ainda não tem usuários, olhe para quem mais se identifica com o problema que você descreve. Quem balança a cabeça com entusiasmo quando você fala sobre o que está construindo? Esse é seu ponto de partida.

Passo 2: Seja específico o suficiente para excluir pessoas

Uma boa persona deve te deixar desconfortável. Deve te fazer pensar: "Mas e as pessoas que não se encaixam nessa descrição?" Esse desconforto significa que você está sendo específico o bastante.

Ruim: "Donos de pequenos negócios" Melhor: "Prestadores de serviço autônomos que faturam entre R$ 15 mil e R$ 45 mil por mês, fazem o próprio faturamento e odeiam isso" Ótimo: "Desenvolvedores web freelancers com 5 a 15 clientes ativos que hoje controlam faturas em planilhas e perdem de 3 a 5 horas por mês cobrando pagamentos atrasados"

Percebeu a diferença? A terceira versão te diz exatamente o que construir — e o que não construir. Um desenvolvedor web freelancer com 5 a 15 clientes não precisa de gestão de equipe corporativa. Não precisa de previsão com IA. Precisa de faturamento rápido, lembretes automáticos e uma forma de ver quem não pagou.

Passo 3: Use sua persona como filtro para toda decisão de feature

Depois que você tiver uma persona bem definida, cole ela no seu monitor (de forma metafórica ou literal). Toda vez que um pedido de feature chegar, pergunte:

Minha persona principal precisa disso?
Isso resolve um problema que ela realmente tem?
Isso vai melhorar a vida dela de forma perceptível?

Se a resposta for não, isso vai para a pilha do "talvez depois". Não para o backlog. Não para "próximo trimestre". Talvez depois. Não se trata de ser rígido — se trata de ser intencional.

Passo 4: Revise e refine regularmente

Sua persona não é um exercício de uma vez só. Conforme você aprende mais sobre seus usuários, atualize-a. Converse com seus melhores clientes todo mês. Observe como eles usam seu produto. Perceba o que eles ignoram. Sua persona deve ficar mais nítida com o tempo, não mais vaga.

O Conserto do Roadmap que Não É um Conserto de Roadmap

Aqui está a ironia: quando suas personas estão sólidas, seu roadmap praticamente se escreve sozinho.

Você para de debater se constrói a Feature A ou a Feature B porque a resposta fica óbvia. "A Sarah, a desenvolvedora freelancer, usaria isso?" Sim → constrói. Não → não constrói.

Seu framework de priorização não é ICE, nem RICE, nem qualquer sigla nova que alguém acabou de publicar no Medium. É uma pessoa. Uma pessoa específica, bem compreendida, cujos problemas você conhece intimamente.

Excesso de features não vem da falta de disciplina. Vem da falta de clareza sobre quem você está atendendo. Resolva a clareza, e a disciplina vem naturalmente.

A Verdade Desconfortável

A maioria dos founders resiste a esse conselho porque especificidade parece deixar dinheiro na mesa. "Se eu estreitar minha persona, vou perder todos aqueles outros clientes em potencial!"

Mas você já está perdendo eles. Você está construindo features para todo mundo e não encantando ninguém. Seu produto é um 5 de nota para cinco públicos diferentes, quando poderia ser um 9 para um só.

Os founders que vencem não são os que têm a lista de features mais longa. São os que sabem exatamente quem atendem e constroem algo que torna a vida dessas pessoas inegavelmente melhor.

Então, da próxima vez que você se pegar buscando uma nova ferramenta de gestão de projetos ou um framework de priorização mais sofisticado, pare. Faça a si mesmo uma pergunta mais difícil:

Eu realmente sei para quem estou construindo isso?

Se a resposta for vaga, nenhuma ferramenta de roadmap vai te salvar.

Não tem certeza se sua estação de Personas (ou qualquer outra estação) tem rachaduras? Faça o diagnóstico da Clari Station. Leva poucos minutos e mostra exatamente qual estação está travando o seu negócio — para você parar de consertar as coisas erradas e começar a trabalhar no que realmente importa.