Comment nous avons lu la première vague de retours d'information

Lorsqu’un site de studio est mis en ligne, on commence à recevoir un certain type d’e-mails. Il ne s’agit pas de rapports de bogues concernant une application spécifique — ceux-ci ont leur propre canal —, mais de retours d’expérience plus généraux et plus vagues. J'aimerais une application qui fasse X. Avez-vous envisagé Y ? Vos prix sont trop bas / trop élevés / peu clairs. Tout cela est un don. La plupart d'entre eux ne peuvent pas devenir des produits.

Cette dernière phrase semble plus sévère que nous ne le voulions. Le problème ne réside pas dans la qualité des suggestions ; beaucoup d’entre elles sont bonnes. Le problème, c’est qu’un petit studio ne peut développer que quelques projets à la fois, et que chaque « oui » signifie un « non » pour autre chose. Le véritable travail consiste donc à déterminer quelles sont les quelques idées qui méritent cette place.

Ce que nous en faisons

Lisez-le. Marquez-le. Triez-le. Les suggestions sont consignées dans un document partagé que nous relisons à la fin de chaque trimestre, et non chaque semaine — les tendances qui comptent n'apparaissent que lorsque l'on en a suffisamment pour discerner une tendance.

Les balises sont simples : de quelle application il s’agit (ou “ studio ” s’il n’y en a pas), de quel type de demande il s’agit, et une paraphrase d’une ligne rédigée avec nos propres mots. La paraphrase est importante. C’est souvent en formulant ce dont la personne a réellement besoin, plutôt que la solution qu’elle a proposée, que l’on découvre des informations utiles. Une personne qui demande l’exportation d’un calendrier dans un organisateur de mariage nous indique peut-être en réalité qu’elle partage l’organisation avec quelqu’un qui n’utilise pas l’application.

Nous répondons à tout le monde, même si notre réponse est brève. Un simple “ merci ” accompagné d’une remarque sincère — “ nous en tenons compte ” ou « nous ne développerons probablement pas cette fonctionnalité, et voici pourquoi » — vaut mieux que le silence, et vaut mieux qu’une promesse que nous ne pourrons pas tenir.

Ce que nous ne faisons pas

Créer immédiatement la fonctionnalité la plus demandée. La fonctionnalité la plus demandée est presque toujours un signe de ce dont les utilisateurs sont le plus conscients d'avoir besoin, et non de ce qui améliorerait le plus le produit. Les améliorations les plus profondes proviennent généralement du deuxième ou troisième courriel, celui qui dit cela fonctionne mais ne convient pas parce que...

Il est plus difficile de donner suite à ces e-mails, car ils ne proposent que rarement de solution concrète. Quelqu’un nous dit qu’un écran lui semble encombré, ou qu’il a cessé d’utiliser une fonctionnalité sans vraiment savoir pourquoi. Pris isolément, chacun de ces messages reste vague. Mais lorsqu’ils sont regroupés et qu’ils mettent en avant le même aspect d’une application, ils constituent souvent les informations les plus précieuses du dossier.

Nous ne considérons pas non plus les demandes de nouvelles applications comme une simple liste de tâches. Une idée de produit entièrement nouveau fait l’objet du même examen trimestriel que tout le reste, et la plupart d’entre elles restent au stade de l’idée. Celles qui sont retenues correspondent à notre façon de travailler : un outil ciblé, utile en soi, que nous aurions nous-mêmes envie d’utiliser.

Nos erreurs

Au cours des premières semaines, notre réflexe était de réagir aux retours dès qu’ils arrivaient : une correction rapide par-ci, un petit ajustement par-là. Cela donnait l’impression d’être à l’écoute. Mais cela signifiait aussi que l’e-mail le plus bruyant de la semaine dictait nos priorités, et que certains changements effectués à la hâte devaient être discrètement annulés. Attendre l’analyse trimestrielle prend plus de temps et peut parfois être frustrant, mais cela permet de prendre de meilleures décisions.

Un mois plus tard, nous en avons déjà un dossier. Nous y travaillerons tout l'été.