La demande de fonctionnalité que vous devriez vraiment construire (et comment la repérer)

Vous savez dire non aux mauvaises demandes de fonctionnalités. Vous avez appris à distinguer la dérive des fonctionnalités des fonctionnalités centrales. Vous protégez les frontières de votre produit.

Mais vous voilà maintenant dans une autre impasse : vous avez une douzaine de demandes qui passent toutes le test. Elles concernent toutes votre appli. Elles sont toutes raisonnables. Ce sont toutes des choses que vos utilisateurs veulent vraiment. Mais vous ne pouvez en construire que trois.

Lesquelles trois ?

C’est là que la plupart des décisions produit dérapent. Les fondateurs choisissent celles qui semblent les plus impressionnantes, ou les plus rentables, ou celles qui viennent de leur client le plus important. Parfois ils ont raison. En général ils ont tort.

Les signaux qui comptent

Signal 1 : la répétition spontanée

Si trois utilisateurs distincts demandent la même chose sans s’être parlé, c’est un signal. Ils ne se sont pas concertés. Ils y ont tous pensé tout seuls. Si cinq utilisateurs le demandent, ce n’est pas une coïncidence — c’est un vrai besoin.

L’inverse est important : si un utilisateur demande et que personne d’autre ne le fait, et que vous le construisez, vous entretenez désormais une fonctionnalité que personne d’autre n’utilise et dont cet utilisateur unique pourrait toujours ne pas être satisfait (parce que vous l’avez construite légèrement de travers).

Comptez les demandes avant de construire. Pas celles du client le plus bruyant ni de votre plus gros client — comptez la répétition spontanée. Deux ou trois utilisateurs indépendants qui demandent la même chose est un signal bien plus fort qu’un client important qui demande cinq choses.

Signal 2 : le contournement compte

Si vous avez des utilisateurs et qu’ils restent même si la fonctionnalité manque, c’est qu’ils ont trouvé un contournement. Peut-être qu’ils le font en dehors de votre appli. Peut-être qu’ils le font à la main. Peut-être qu’ils utilisent un autre outil en parallèle.

Mais ils restent, ce qui veut dire qu’ils n’ont pas besoin de la fonctionnalité pour utiliser votre appli. Ils en ont besoin pour utiliser votre appli mieux. C’est différent d’un point bloquant.

Les fonctionnalités qui comptent le plus sont celles qui empêchent carrément les gens d’utiliser votre appli. Les fonctionnalités sympas à avoir sont celles que les gens contournent.

Faites attention à quelles demandes sont des points bloquants. Quelqu’un qui dit « je ne peux pas l’utiliser tant que vous ne faites pas X » contre quelqu’un qui dit « ce serait génial si vous aviez X ». Cette distinction vaut de l’or.

Signal 3 : la fonctionnalité va de pair avec un modèle économique

Certaines fonctionnalités débloquent des façons entièrement nouvelles de gagner de l’argent. « Facture mes clients » débloque un modèle où vous facturez pour la facturation. « Export vers Salesforce » débloque des revenus d’intégration. « Marque blanche pour revendeurs » débloque un canal de partenaires.

Mais voici l’astuce : vous ne savez pas si ces modèles marcheront tant que vous n’êtes pas déjà en train de livrer. Vous ne pouvez pas les planifier. Vous ne pouvez que les remarquer après avoir livré et vu si les gens les utilisent réellement.

Les ajouts de fonctionnalités les plus réussis sont ceux où livrer la fonctionnalité révèle un marché dont vous ne soupçonniez pas l’existence. Vous avez construit l’export. Il s’avère que des entreprises veulent intégrer votre export dans leur flux de travail. Vous avez maintenant une histoire d’intégration que vous n’aviez pas planifiée.

Construisez des fonctionnalités parce que vos utilisateurs en ont besoin. Ensuite, observez si vos utilisateurs en ont besoin d’une façon qui crée du nouveau business. Ne prédisez pas le modèle économique en premier.

Signal 4 : la proposition d’aider

Si un utilisateur vous demande de construire quelque chose, c’est une demande. Si un utilisateur demande si vous pourriez construire quelque chose et propose d’aider à le tester, c’est différent.

Les gens qui proposent d’aider à tester sont des gens investis dans le résultat. Ils utiliseront la fonctionnalité avec soin. Ils signaleront les bugs. Ils vous diront si elle résout vraiment leur problème.

Les gens qui se contentent de demander sont des gens qui espèrent que vous construirez comme par magie ce qu’ils imaginent. Parfois ce sera le cas. Souvent non.

Construisez avec les testeurs d’abord. Tout le reste est secondaire.

La tentation de construire la fonctionnalité prestige

Chaque produit a une fonctionnalité qui, si vous la livrez, vous fait paraître plus impressionnant. Pour les applis de planification, c’est l’intégration avec Calendly. Pour les applis de tâches, c’est l’intégration avec Slack. Tout le monde sait de quoi il s’agit. Tout le monde les veut.

Voici le truc : tout le monde les obtient aussi auprès de quelqu’un d’autre. Si votre fonctionnalité n’est pas la meilleure, la plus facile des intégrations à Slack, elle ne fait qu’ajouter de la complexité à votre appli sans vous rendre célèbre.

Les fonctionnalités qui vous rendent célèbre sont celles que vous êtes le mieux placé pour construire parce que vous comprenez les problèmes de vos utilisateurs spécifiques mieux que quiconque. Ce ne sont pas les fonctionnalités prestige. Ce sont les fonctionnalités ennuyeuses qui résolvent de vrais problèmes pour de vraies personnes.

Une intégration Slack, c’est impressionnant. Un outil qui permet à vos utilisateurs de faire une chose précise bien plus vite que Slack n’y a jamais songé, c’est précieux.

Comment décider, concrètement

Quand vous avez un lot de demandes de fonctionnalités qui passent toutes le test « est-ce dans le périmètre ? », classez-les par :

1. Combien d’utilisateurs l’ont demandé (indépendamment) ? Plus, c’est mieux.
2. Est-ce un point bloquant ou un sympa-à-avoir ? Les points bloquants sont plus urgents.
3. Vos utilisateurs peuvent-ils contourner ça aujourd’hui ? Si non, c’est plus important.
4. Quelqu’un vous aidera-t-il à le tester ? Si oui, construisez-le en premier.
5. Est-ce que ça révélera un nouveau marché ? Si peut-être, c’est un bonus, pas une raison.

Puis construisez dans cet ordre. Pas dans l’ordre de ce qui sonne impressionnant. Pas dans l’ordre de votre plus gros client. Dans l’ordre du vrai signal venant des gens qui utilisent votre appli.

La fonctionnalité que vous ne construirez pas (pour l’instant)

Vous aurez des demandes qui ne passeront pas le filtre. Ne faites pas semblant que vous les construirez un jour. Dites à l’utilisateur : « On ne construit pas ça pour l’instant. Voici pourquoi. Voici ce qu’on est en train de construire. Voici une solution alternative qui pourrait marcher pour vous. »

Cette honnêteté compte plus que vous ne le pensez. Les utilisateurs préfèrent savoir que vous ne le ferez pas plutôt que d’attendre six mois en espérant.

Et parfois, une fois que vous avez dit non, l’utilisateur trouve un contournement, ou un autre outil, ou résout le problème autrement. C’est très bien. Vous ne pouvez pas être tout pour tout le monde.

Les produits qui gagnent sont ceux qui font bien leur travail et écoutent attentivement ce dont les utilisateurs ont vraiment besoin, pas ceux qui essaient d’être tout et finissent par n’être rien.