O pedido de recurso que você deveria de fato construir (e como saber)

Você sabe dizer não a pedidos de recurso ruins. Você aprendeu a distinguir escopo inchado de recursos centrais. Você está protegendo os limites do seu produto.

Mas agora você está numa enrascada diferente: você tem uma dúzia de pedidos que todos passam no teste. São todos para o seu app. São todos razoáveis. São todos coisas que os seus usuários de fato querem. Mas você só consegue construir três deles.

Quais três?

É aqui que a maioria das decisões de produto dá errado. Os fundadores escolhem os que soam mais impressionantes, ou mais lucrativos, ou os que vieram do cliente mais importante. Às vezes eles acertam. Em geral erram.

Os sinais que importam

Sinal 1: repetição espontânea

Se três usuários distintos pedem a mesma coisa sem terem falado entre si, isso é um sinal. Eles não combinaram. Todos simplesmente pensaram nisso. Se cinco usuários pedem, isso não é coincidência — é uma necessidade genuína.

O inverso é importante: se um usuário pede e mais ninguém pede, e você constrói, você agora mantém um recurso que ninguém mais usa e com o qual aquele único usuário ainda pode não estar feliz (porque você construiu um pouco errado).

Conte os pedidos antes de construir. Não os do cliente mais barulhento ou do seu maior cliente — conte a repetição espontânea. Dois ou três usuários independentes pedindo a mesma coisa é um sinal muito mais forte que um cliente importante pedindo cinco coisas.

Sinal 2: a gambiarra importa

Se você tem usuários e eles estão ficando mesmo com o recurso faltando, eles encontraram uma gambiarra. Talvez estejam fazendo isso fora do seu app. Talvez estejam fazendo na mão. Talvez estejam usando outra ferramenta em paralelo.

Mas eles estão ficando, o que significa que não precisam do recurso para usar o seu app. Eles precisam dele para usar o seu app melhor. Isso é diferente de um impedimento.

Os recursos que mais importam são os que impedem as pessoas de usar o seu app de jeito nenhum. Os recursos que são bons de ter são aqueles que as pessoas contornam.

Preste atenção em quais pedidos são impedimentos. Alguém dizer “Não consigo usar isto até você fazer X” vs. alguém dizer “Seria ótimo se você tivesse X”. Essa distinção é ouro.

Sinal 3: o recurso vem em pacote com o modelo de negócio

Alguns recursos destravam formas inteiramente novas de ganhar dinheiro. “Faturar os meus clientes” destrava um modelo de negócio em que você cobra por faturamento. “Exportar para o Salesforce” destrava receita de integração. “White-label para revendedores” destrava um canal de parceiros.

Mas aqui está o truque: você não sabe se esses modelos vão funcionar até já estar lançando. Você não pode planejar em torno deles. Você só pode notá-los depois de lançar e ver se as pessoas de fato os usam.

As adições de recurso mais bem-sucedidas são aquelas em que lançar o recurso revela um mercado que você não sabia que existia. Você construiu a exportação. Acontece que as empresas querem embutir a sua exportação no fluxo de trabalho delas. Agora você tem uma história de integração que não planejou.

Construa recursos porque os seus usuários precisam deles. Aí observe para ver se os seus usuários precisam deles de um jeito que cria um novo negócio. Não tente prever o modelo de negócio primeiro.

Sinal 4: o pedido de ajuda

Se um usuário te pede para construir algo, isso é um pedido. Se um usuário pergunta se você poderia construir algo e se oferece para ajudar a testar, isso é diferente.

Quem se oferece para ajudar a testar é gente investida no resultado. Vão usar o recurso com cuidado. Vão reportar bugs. Vão te dizer se ele de fato resolve o problema deles.

Quem só faz o pedido é gente esperando que você construa magicamente o que está imaginando. Às vezes você vai. Muitas vezes não.

Construa com os testadores primeiro. Todo o resto é secundário.

A tentação de construir o recurso de prestígio

Todo produto tem um recurso que, se você lançar, te faz soar mais impressionante. Para apps de agendamento, é integrar com o Calendly. Para apps de tarefas, é integrar com o Slack. Todo mundo sabe quais são esses. Todo mundo os quer.

Eis a questão: todo mundo também os está pegando de outra pessoa. Se o seu recurso não é a melhor e mais fácil integração com o Slack, ele só adiciona complexidade ao seu app sem te deixar famoso.

Os recursos que te deixam famoso são aqueles que você está em posição única para construir porque entende os problemas dos seus usuários específicos melhor que qualquer um. Esses não são os recursos de prestígio. São os recursos chatos que resolvem problemas reais para pessoas reais.

Integração com o Slack é impressionante. Uma ferramenta que deixa os seus usuários fazerem uma coisa específica muito mais rápido do que o Slack jamais pensou é valiosa.

Como de fato decidir

Quando você tem um lote de pedidos de recurso que todos passam no teste do “isto está dentro do escopo?”, classifique-os por:

1. Quantos usuários pediram (de forma independente)? Mais é melhor.
2. Isto é um impedimento ou um bom de ter? Impedimentos são mais urgentes.
3. Os seus usuários conseguem contornar isto hoje? Se não, é mais importante.
4. Alguém vai te ajudar a testar isto? Se sim, construa primeiro.
5. Isto vai revelar um novo mercado? Se talvez, isso é um bônus, não um motivo.

Aí construa nessa ordem. Não na ordem do que soa impressionante. Não na ordem do seu maior cliente. Na ordem do sinal de verdade vindo das pessoas que usam o seu app.

O recurso que você não vai construir (ainda)

Você vai ter pedidos que não entram. Não finja que vai construí-los um dia. Diga ao usuário: “Não vamos construir isso agora. Aqui está o porquê. Aqui está o que estamos construindo. Aqui está uma alternativa que pode funcionar para você.”

Essa honestidade importa mais do que você imagina. Os usuários preferem saber que você não vai fazer a esperar seis meses na esperança.

E às vezes, depois de você ter dito não, o usuário encontra uma gambiarra, ou outra ferramenta, ou resolve o problema de outro jeito. Tudo bem. Você não pode ser tudo para todo mundo.

Os produtos que vencem são os que fazem o seu trabalho bem e escutam com atenção o que os usuários de fato precisam, não os que tentam ser tudo e acabam não sendo nada.