A armadilha do escopo inchado: como dizer não a recursos que soam bem mas não são
Você criou algo que os usuários amam. Agora eles querem recursos que soam razoáveis, mas que levariam o app para dez direções diferentes. Veja como decidir quais pedidos atender e quais recusar com educação.
Você lançou um app. Os usuários apareceram. E agora a sua caixa de entrada está cheia de pedidos de recursos que todos soam como boas ideias.
“Dá para adicionar exportação para Excel?” Razoável. “As faturas podem ser enviadas automaticamente?” Faz sentido. “Dá para integrar com o Stripe?” É ali que mora o dinheiro de verdade. “Dá para adicionar um app mobile?” Todo mundo pede isso. “Dá para fazer white-label disso para os nossos próprios clientes?” Ah, agora apareceu um modelo de negócio.
Cada pedido, isoladamente, soa inteligente. Juntos, soam como se você estivesse construindo cinco produtos diferentes.
Isso é escopo inchado, e mata mais apps pequenos criados com IA do que problemas técnicos jamais matarão. Não porque você constrói os recursos — mas porque você fica sem tempo, sem dinheiro ou sem sanidade tentando.
Como o escopo inchado mata um app que funciona
Veja o que acontece. Você diz sim aos três primeiros pedidos porque parecem razoáveis. Você pede ao seu criador de apps com IA para adicioná-los. Leva duas semanas em vez de uma, porque cada recurso novo esbarra no código existente. Agora você tem um app que faz cinco coisas, e faz três delas bem e duas mais ou menos.
Aí chega o pedido número quatro: “Dá para termos níveis de permissão diferentes?” De repente você precisa repensar quem pode ver o quê em cada tela. Isso não é um recurso; é uma mudança de arquitetura. Você pede ao seu criador de apps com IA para fazer. Mexe em tudo. Duas semanas viram três. O app fica mais lento porque você adicionou lógica em cada tela.
No pedido número oito, você parou de lançar coisas novas para os seus usuários originais porque está ocupado demais mantendo a máquina de pedidos de recurso girando. As pessoas que amavam o app três meses atrás estão frustradas porque nada do que pediram fica pronto. As pessoas fazendo pedidos novos estão frustradas porque os recursos demoram uma eternidade.
Você criou algo que funciona. E o quebrou ao tentar ser tudo.
O modelo de decisão
Você precisa de um filtro. Todo pedido de recurso passa por três perguntas:
Pergunta 1: Isto pertence a este app, ou é um app diferente?
O seu primeiro app faz uma única tarefa muito bem. Um app de agendamento agenda coisas. Um app de faturamento fatura. São apps diferentes. Se alguém pede que o seu app de agendamento fature, você não está adicionando um recurso — está pedindo que um app de agendamento faça contabilidade. Isso é um produto diferente.
Um bom teste: “Se eu pegasse este recurso e o lançasse de forma independente, as pessoas iam querer comprar?” Se sim, ele provavelmente pertence a um app diferente. Se a resposta é “não, só faz sentido como parte de uma coisa maior”, então você está construindo no escopo certo.
Você vai receber pedidos como “integrar com o nosso CRM”. O que isso realmente significa é “seja o seu próprio CRM”. Isso é um app diferente. Você pode integrar com um CRM depois. Você não pode adicionar um CRM inteiro em recursos sem virar um CRM.
Pergunta 2: Isto resolve um problema para a maioria dos seus usuários, ou só para este?
Um cliente ama o seu app e tem uma ideia de recurso. É um problema real que ele tem. É também um problema real que só ele tem.
Se você tem vinte usuários e um está pedindo algo, verifique: os outros dezenove também estão esperando por isto, ou essa pessoa simplesmente pensou nisso? Você pode perguntar diretamente: “Antes de você, já pensou em perguntar a mais alguém se precisa disto?” Em geral, a resposta é não.
Esta é a pergunta perigosa, porque o único cliente que está pedindo pode ser o seu cliente mais importante. Talvez você precise mantê-lo feliz. Isso é uma decisão de negócio, não de produto. Mas vá com os olhos abertos: se você constrói algo para um único cliente, não está fazendo o seu app crescer, está montando uma consultoria.
Pergunta 3: Quanto isto custa e qual é o custo para a ideia original?
Tudo custa alguma coisa. Exportação para Excel custa tempo de engenharia. Custa complexidade ao seu app. Custa foco. Construa isso em vez de uma otimização de desempenho de que os seus usuários reclamam todo dia, e você fez uma escolha.
Pergunte concretamente: “Se eu construir isto, o que eu não construo?” Se a resposta é “nada, temos tempo infinito”, você não está sendo honesto. Não temos. O tempo é finito.
O custo para a ideia original costuma ser invisível. Quando você está mergulhado em pedidos de recurso, para de manter a coisa central que as pessoas amavam em você. O núcleo fica mais lento. O núcleo fica mais cheio de bugs. O núcleo parece abandonado. E, no fim, as pessoas vão embora porque o app que funcionava ótimo agora funciona mais ou menos e faz coisas para as quais nunca foi projetado.
Um exemplo real: o formulário de admissão
Alguém criou um formulário simples de admissão de clientes. Os clientes preenchem, o coach revisa, eles agendam. Esse é o app.
Pedido um: “Dá para marcar admissões urgentes?” Sim, é uma variação do fluxo central. Construa.
Pedido dois: “Dá para exportar as admissões para Excel para os meus registros?” Isso é um recurso de documento. Não é a função do app. As admissões vivem no app. Se precisarem de Excel, podem copiar e colar. Mas, tudo bem, a exportação pode fazer sentido como conveniência. Construa.
Pedido três: “As admissões podem criar eventos de calendário automaticamente?” Agora você está fazendo agendamento. O app era para admissão, não agendamento. Se alguém quer os dois, provavelmente quer um sistema de agendamento de verdade, não um remendo que cole um no outro. Recuse com educação.
Pedido quatro: “Os coaches podem enviar follow-ups de admissão por SMS?” Agora você é um sistema de comunicação. Não.
No pedido três, você bateu no limite. O app é admissão. Qualquer outra coisa é um app diferente. Você pode integrar com esses apps depois. Você não pode adicioná-los sem virar esses apps.
Como dizer não
A parte mais difícil é de fato dizer. Você não quer frustrar os seus usuários.
Seja honesto: “É uma ótima ideia, mas é um produto diferente do que estamos construindo aqui. O que estamos construindo é [a sua única tarefa]. Se tentarmos fazer agendamento, faturamento ou coisa de CRM, vamos ser razoáveis em todos e ótimos em nenhum.”
Muitas vezes o cliente vai entender. Ele perguntou porque a ideia veio à cabeça, não porque está te testando.
Às vezes ele vai insistir. “Mas eu preciso dos dois.” É aí que você recomenda: use o app de agendamento de verdade. Use o app de faturamento de verdade. Use o CRM de verdade. E aí use este app para aquilo que ele faz bem. Essa é a resposta honesta.
A tentação de ser tudo
A parte mais difícil de construir um produto pequeno é dizer não. Não parece deixar dinheiro na mesa. E se aquele cliente realmente fosse pagar pelos dois? E se aquele recurso te deixasse dez vezes maior?
Talvez. Mas você não é um produto dez vezes maior se não o lançar. Você é um produto pela metade que faz cinco coisas mal. As pessoas que amavam o núcleo estão frustradas. As pessoas que queriam os recursos novos estão frustradas. E você se pintou num canto onde adicionar qualquer coisa nova significa refatorar cinco coisas antigas primeiro.
Os produtos que crescem são os que fazem uma única tarefa muito bem, e depois adicionam com cuidado. Eles não tentam ser o Salesforce desde o primeiro dia. São o app que você procura quando precisa fazer aquela única coisa, e o app em que você confia para ser rápido e confiável quando faz.
Diga não. Proteja o núcleo. Faça isso, e você vai construir algo que as pessoas realmente querem usar.