Comment décider quels retours utilisateurs construire (et lesquels laisser tomber)
Dès que les gens utilisent votre appli, les demandes affluent. Voici une méthode simple pour décider quels retours utilisateurs valent la peine d'être construits avec votre créateur d'applis avec IA, lesquels mettre de côté et lesquels refuser poliment.
Les premières semaines après que les gens commencent à utiliser votre appli sont calmes. Puis les messages arrivent. « Tu pourrais ajouter un mode sombre ? » « Ce serait génial de pouvoir exporter en PDF. » « Tu peux mettre le bouton en bleu ? » « On a vraiment besoin d’intégrations avec l’outil qu’on utilise déjà. » En l’espace d’un mois, vous avez une liste de quarante choses, et un créateur d’applis avec IA qui construira volontiers n’importe laquelle d’entre elles en une après-midi.
Cette dernière partie est le piège. Quand construire chaque fonctionnalité est bon marché et rapide, la question difficile n’est plus « est-ce que je peux construire ça ? » mais « est-ce que je devrais ? » Le goulot d’étranglement passe de vos mains à votre jugement, et personne ne vous donne de mode d’emploi pour ça.
Cet article propose une méthode simple pour trier les retours entrants en trois tas — à construire, à mettre de côté, à laisser tomber — sans avoir besoin d’un bagage en gestion de produit. Le but n’est pas de dire non aux gens. C’est de s’assurer que les choses que vous construisez sont bien celles qui font réellement avancer votre appli.
Pourquoi « construis tout » cesse de fonctionner
Pour vos dix premières fonctionnalités, « construis simplement ce qu’on te demande » est une bonne stratégie. Vous n’avez pas assez d’utilisateurs pour avoir des avis contradictoires, et chaque fonctionnalité rend l’appli plus utile que le truc vide qu’elle était la semaine dernière.
Ça cesse de fonctionner à peu près au moment où vous avez de vrais utilisateurs, différents les uns des autres. Un freelance veut une chose, une petite agence veut le contraire, et un visiteur de passage veut quelque chose qu’aucun des deux n’utilisera jamais. Construisez les trois et votre appli se transforme en tiroir fourre-tout — plein de choses, impossible d’y retrouver quoi que ce soit, lourd à porter. Chaque fonctionnalité que vous ajoutez est une fonctionnalité que vous devrez maintenir en état pour toujours, expliquer aux nouveaux utilisateurs et ne pas casser quand vous modifiez quelque chose à côté.
Un créateur d’applis avec IA aggrave ça avant d’arranger les choses, parce qu’il supprime le frein naturel. Quand une fonctionnalité prenait deux semaines à un développeur, vous réfléchissiez à fond pour savoir si elle valait deux semaines. Quand elle prend vingt minutes au créateur, vous ne réfléchissez plus du tout — vous dites simplement oui. Le coût n’a pas disparu. Il est passé du « temps de construction » au « poids à porter », et le poids est plus difficile à voir.
Trois questions qui trient presque tout
Quand une demande arrive, faites-la passer par trois questions, dans l’ordre. La plupart des choses se trient d’elles-mêmes après les deux premières.
1. Est-ce que ça aide les gens pour qui j’ai construit ça ? Vous avez construit votre appli pour quelqu’un de précis — des photographes de mariage, des entraîneurs de foot pour enfants, des animateurs de podcasts indépendants. Une demande venant de l’une de ces personnes vaut plus qu’une demande venant de quelqu’un qui est passé par hasard et ne reviendra jamais. Si une fonctionnalité aide vos gens du cœur de cible à faire la chose principale pour laquelle ils sont venus, elle monte vers le haut. Si elle aide un visiteur qui n’est pas vraiment votre utilisateur, elle descend vers le bas, peu importe la force avec laquelle il l’a réclamée.
2. Combien de personnes l’utiliseront réellement ? Pas « qui l’a demandée » — qui l’utilisera. Une personne qui demande fort n’équivaut pas à dix personnes qui en profiteraient en silence. Soyez honnête ici, parce que les demandes bruyantes ressemblent à de grosses demandes, et n’en sont généralement pas. Un bon indice : demandez à la personne ce qu’elle fait aujourd’hui à la place. Si elle a une combine bancale qu’elle utilise tous les jours, c’est un vrai besoin. Si elle « l’utiliserait sans doute de temps en temps », c’est un confort déguisé en nécessité.
3. Qu’est-ce que ça me coûte de la porter pour toujours ? Certaines fonctionnalités sont légères. Une nouvelle option de couleur, un libellé reformulé, un champ supplémentaire sur un formulaire — construisez-la et oubliez-la. Certaines fonctionnalités sont lourdes : tout ce qui touche aux paiements, tout ce qui envoie des e-mails à de vraies personnes, tout ce qui ajoute une section entière avec ses propres règles. Les fonctionnalités lourdes ne sont pas mauvaises, mais elles doivent justifier leur poids en passant les deux premières questions avec une bonne marge.
Les trois tas
Faites passer ces questions et presque tout atterrit dans l’un de ces trois endroits.
À construire. Ça aide vos gens du cœur de cible, plusieurs d’entre eux l’utiliseront, et le coût à porter est raisonnable. Celles-ci sont faciles. Faites-les, et dites-le à la personne qui a demandé — les gens qui voient leur idée livrée deviennent vos utilisateurs les plus fidèles et votre meilleure source de la prochaine bonne idée.
À mettre de côté. Bonne idée, mais c’est trop tôt, ou une seule personne la veut, ou c’est lourd et vous n’êtes pas encore sûr. Ne dites pas non et ne la construisez pas. Notez-la quelque part où vous regarderez vraiment — une simple liste, une note, un tableau. Si trois autres personnes demandent la même chose au cours du mois suivant, elle vient de se promouvoir elle-même dans le tas « à construire » et vous l’a fait savoir. Mettre de côté n’est pas un cimetière ; c’est une salle d’attente.
À laisser tomber. Ça ne correspond pas à ce pour quoi votre appli existe, ça ne servirait jamais qu’une seule personne, ou ça rendrait l’appli pire pour tout le monde. Celles-ci appellent un non poli et honnête. « C’est une idée réfléchie, mais ce n’est pas quelque chose que je compte ajouter — voici ce que je suggérerais à la place » préserve la relation et protège l’appli. Dire non est une fonctionnalité. Chaque non est un oui au fait de garder l’appli assez simple pour que les gens la comprennent.
Un petit exemple
Quelqu’un que nous connaissons gère une appli de réservation pour professeurs de musique, construite entièrement avec un créateur d’applis avec IA. En une semaine, elle a reçu trois demandes : un professeur voulait des SMS de rappel automatiques aux élèves, un parent voulait pouvoir voir tous les cours de ses enfants au même endroit, et une personne voulait l’appli traduite en latin « pour le fun ».
Les rappels passaient les trois questions — utilisateurs du cœur de cible, beaucoup d’entre eux galèrent avec les absences, et le SMS est lourd mais ça en vaut la peine. Construit. La vue parent était une bonne idée venant d’une seule personne, donc elle l’a mise de côté ; deux autres parents ont demandé en trois semaines et elle s’est promue toute seule. La traduction en latin a eu droit à un non chaleureux. Aucune de ces décisions n’a nécessité de tableur. Elles ont nécessité trois questions et la volonté de répondre honnêtement à la troisième.
La partie que personne ne vous dit
Les retours les plus durs à gérer ne sont pas les mauvaises idées. Ce sont les bonnes idées venant de gens que vous appréciez, pour une appli qui ne peut pas tout être. Les laisser tomber donne l’impression de décevoir la personne. Ce n’est pas le cas. La chose la plus gentille que vous puissiez faire pour les gens qui utilisent votre appli, c’est de la garder assez ciblée pour qu’elle reste bonne sur la seule chose pour laquelle ils sont venus.
La prochaine fois que les demandes s’accumulent, n’ouvrez pas votre créateur d’applis avec IA en premier. Ouvrez votre liste, faites passer chaque élément par les trois questions, et triez-le dans un tas. La construction est désormais la partie facile. Décider de ce qui vaut la peine d’être construit, c’est le vrai travail — et c’est un travail que vous pouvez faire sans écrire une seule ligne de code.