Como lemos a primeira onda de feedback

Quando o site de um estúdio é lançado, começa a chegar um tipo específico de e-mail. Não se trata de relatórios de erros sobre uma aplicação específica — esses têm o seu próprio canal —, mas sim de comentários mais gerais e vagos. Gostaria de ter uma aplicação que fizesse X. Já pensaram em Y? Os vossos preços são demasiado baixos / demasiado altos / pouco claros. Tudo é uma dádiva. A maior parte não se pode transformar em produto.

Essa última frase soa mais severa do que pretendíamos. O problema não é a qualidade das sugestões; muitas delas são boas. O que se passa é que um estúdio pequeno só consegue desenvolver algumas coisas de cada vez, e cada «sim» é um «não» a outra coisa. Por isso, o verdadeiro trabalho consiste em decidir quais são as poucas ideias que merecem esse espaço.

O que fazemos com ele

Lê. Assinala. Organiza. As sugestões vão para um documento partilhado que relemos no final de cada trimestre, não todas as semanas — os padrões que importam só se tornam visíveis quando há um número suficiente deles para se perceber uma tendência.

As etiquetas são simples: de que aplicação se trata (ou “estúdio”, se não houver nenhuma), que tipo de pedido é e uma paráfrase de uma linha, nas nossas próprias palavras. A paráfrase é importante. Escrever o que achamos que a pessoa realmente precisa, em vez da solução que propôs, é muitas vezes onde surgem as ideias úteis. Alguém que pede a exportação do calendário numa aplicação de organização de casamentos pode, na verdade, estar a dizer-nos que partilha o planeamento com alguém que não utiliza a aplicação.

Respondemos a toda a gente, mesmo que a resposta seja curta. Um breve agradecimento acompanhado de uma nota sincera — “isto está na nossa lista” ou “provavelmente não é algo que venhamos a desenvolver, e eis o motivo” — é melhor do que o silêncio e melhor do que uma promessa que não podemos cumprir.

O que não fazemos

Criar imediatamente a funcionalidade mais solicitada. A funcionalidade mais solicitada é quase sempre um sinal do que os utilizadores estão mais conscientes de que precisam, e não do que mais melhoraria o produto. Os melhoramentos mais profundos vêm normalmente do segundo ou terceiro e-mail, aquele que diz isto funciona mas parece errado porque...

É mais difícil dar seguimento a esses e-mails, porque raramente vêm acompanhados de uma solução. Alguém nos diz que um ecrã parece sobrecarregado, ou que deixou de utilizar uma funcionalidade sem saber bem porquê. Isoladamente, cada um deles é vago. Vários juntos, apontando para a mesma parte de uma aplicação, são muitas vezes o que há de mais valioso na pasta.

Também não tratamos os pedidos de novas aplicações como uma lista de tarefas. Uma ideia para um produto totalmente novo é analisada trimestralmente, tal como tudo o resto, e a maioria delas fica-se por ideia. As que avançam encaixam-se na nossa forma de trabalhar: uma ferramenta específica, útil por si só, que nós próprios gostaríamos de utilizar.

O que fizemos de errado

Nas primeiras semanas, o nosso instinto era responder aos comentários à medida que chegavam — uma correção rápida aqui, uma pequena alteração ali. Parecia uma atitude atenciosa. Mas isso também significava que o e-mail mais insistente da semana definia as nossas prioridades, e algumas alterações feitas à pressa tinham de ser discretamente revertidas. Esperar pela análise trimestral é mais demorado e, por vezes, frustrante, mas leva a melhores decisões.

Um mês depois, já temos um dossier com essas coisas. Vamos trabalhar nelas durante todo o verão.