Como decidir qual feedback de usuário construir (e qual deixar para lá)
Quando as pessoas começam a usar o seu app, os pedidos começam a chover. Veja uma forma simples de decidir qual feedback de usuário vale a pena construir com o seu criador de apps com IA, qual estacionar e a qual dizer não com educação.
As primeiras semanas depois que as pessoas começam a usar o seu app são quietas. Aí as mensagens começam. “Dá para adicionar um modo escuro?” “Seria ótimo se eu pudesse exportar para PDF.” “Dá para deixar o botão azul?” “A gente precisa mesmo de integrações com a ferramenta que já usamos.” Em um mês você tem uma lista de quarenta coisas, e um criador de apps com IA que vai construir de bom grado qualquer uma delas para você numa tarde.
Essa última parte é a armadilha. Quando construir cada recurso é barato e rápido, a pergunta difícil deixa de ser “consigo construir isto?” e vira “deveria?”. O gargalo se desloca das suas mãos para o seu julgamento, e ninguém te entrega um guia para isso.
Este post é uma forma simples de classificar o feedback que chega em três pilhas — construir, estacionar, deixar para lá — sem precisar de formação em gestão de produto. O objetivo não é dizer não às pessoas. É garantir que as coisas que você de fato construir sejam as que realmente fazem o seu app avançar.
Por que “só construir” para de funcionar
Para os seus primeiros dez recursos, “só construa o que alguém pedir” é uma estratégia ótima. Você não tem usuários suficientes para ter opiniões conflitantes, e cada recurso torna o app mais útil que a coisa vazia que ele era na semana passada.
Ela para de funcionar mais ou menos quando você tem usuários reais e diferentes. Um freelancer quer uma coisa, uma pequena agência quer o oposto, e um visitante de uma única vez quer algo que nenhum dos dois jamais vai usar. Construa os três e o seu app vira uma gaveta de tranqueiras — cheia de coisas, difícil de achar qualquer uma, pesada de carregar. Todo recurso que você adiciona é um recurso que você tem que manter funcionando para sempre, explicar para usuários novos e não quebrar quando você muda algo ao lado.
Um criador de apps com IA piora isso antes de melhorar, porque remove o freio natural. Quando um recurso levava duas semanas de um desenvolvedor, você pensava bem se ele valia duas semanas. Quando ele leva vinte minutos do criador, você não pensa nada — você só diz sim. O custo não sumiu. Ele se deslocou de “tempo para construir” para “peso para carregar”, e peso é mais difícil de enxergar.
Três perguntas que classificam quase tudo
Quando um pedido chega, passe-o por três perguntas em ordem. A maioria das coisas se classifica sozinha depois das duas primeiras.
1. Isto ajuda as pessoas para quem eu construí isto? Você construiu o seu app para alguém específico — fotógrafos de casamento, treinadores de futebol infantil, apresentadores de podcast indie. Um pedido de uma dessas pessoas vale mais que um pedido de alguém que apareceu por acaso e nunca mais vai voltar. Se um recurso ajuda as suas pessoas centrais a fazer a coisa principal pela qual vieram, ele vai para perto do topo. Se ajuda um visitante que não é realmente o seu usuário, vai para perto do fundo, por mais alto que ele tenha pedido.
2. Quantas pessoas de fato vão usá-lo? Não “quem pediu” — quem vai usar. Uma pessoa pedindo alto não é o mesmo que dez pessoas que se beneficiariam quietamente. Seja honesto aqui, porque pedidos altos parecem grandes pedidos, e em geral não são. Um bom sinal: pergunte à pessoa o que ela está fazendo hoje no lugar. Se ela tem uma gambiarra desajeitada que usa todo dia, isso é uma necessidade de verdade. Se ela “provavelmente usaria às vezes”, é um bom-de-ter fantasiado.
3. Quanto me custa carregar isto para sempre? Alguns recursos são leves. Uma nova opção de cor, um rótulo reescrito, um campo extra num formulário — construa e esqueça. Alguns recursos são pesados: qualquer coisa que toque em pagamentos, qualquer coisa que envie e-mail a pessoas reais, qualquer coisa que adicione uma seção inteira com regras próprias. Recursos pesados não são ruins, mas deveriam justificar o seu peso passando nas duas primeiras perguntas com folga.
As três pilhas
Passe essas perguntas e quase tudo cai num de três lugares.
Construir. Ajuda as suas pessoas centrais, várias delas vão usar, e o custo de carregar é razoável. Esses são fáceis. Faça-os, e avise a pessoa que pediu — quem vê a própria ideia lançada vira o seu usuário mais leal e a sua melhor fonte da próxima boa ideia.
Estacionar. Boa ideia, mas é cedo, ou só uma pessoa quer, ou é pesado e você não tem certeza ainda. Não diga não e não construa. Anote em algum lugar que você de fato vá olhar — uma lista simples, uma nota, um quadro. Se mais três pessoas pedirem a mesma coisa no próximo mês, ela se autopromoveu para a pilha de construir e te avisou disso. Estacionar não é um cemitério; é uma sala de espera.
Deixar para lá. Não encaixa naquilo para que o seu app serve, só serviria a uma pessoa, ou tornaria o app pior para todos os outros. Esses precisam de um não educado e honesto. “É uma ideia atenciosa, mas não é algo que eu planejo adicionar — aqui está o que eu sugeriria no lugar” preserva a relação e protege o app. Dizer não é um recurso. Todo não é um sim a manter o app simples o bastante para as pessoas o entenderem.
Um pequeno exemplo
Alguém que conhecemos toca um app de agendamento para professores de música, construído inteiramente com um criador de apps com IA. Numa semana ela recebeu três pedidos: um professor queria mensagens de lembrete automáticas para os alunos, uma mãe queria uma forma de ver todas as aulas dos filhos numa única visão, e uma pessoa queria o app traduzido para o latim “por diversão”.
Os lembretes passaram nas três perguntas — usuários centrais, muitos deles lidam com faltas, e mandar mensagem é pesado mas vale a pena. Construído. A visão para os pais era uma boa ideia de uma pessoa, então ela a estacionou; mais duas mães pediram em três semanas e ela se autopromoveu. A tradução para o latim ganhou um não caloroso. Nenhuma dessas decisões precisou de uma planilha. Elas precisaram de três perguntas e da disposição de responder à terceira com honestidade.
A parte que ninguém te conta
O feedback mais difícil de lidar não são as ideias ruins. São as boas ideias de pessoas de quem você gosta, para um app que não pode ser tudo. Deixá-las para lá parece decepcionar a pessoa. Não é. A coisa mais gentil que você pode fazer pelas pessoas que usam o seu app é mantê-lo focado o bastante para continuar bom na única coisa pela qual elas vieram.
Da próxima vez que os pedidos se acumularem, não abra o seu criador de apps com IA primeiro. Abra a sua lista, passe cada item pelas três perguntas e classifique-o numa pilha. A construção é a parte fácil agora. Decidir o que vale a pena construir é o trabalho de verdade — e é um trabalho que você consegue fazer sem escrever uma única linha de código.