Les demandes de fonctionnalités ne sont pas des spécifications

L'erreur que font la plupart des équipes produit : elles traitent une demande de fonctionnalité comme une spécification.

Un utilisateur dit "ajoutez le mode sombre" et elles construisent le mode sombre. Un utilisateur dit "permettez-moi d'exporter en CSV" et elles construisent l'export CSV. Cela semble juste. Vous écoutez vos utilisateurs.

Mais les demandes de fonctionnalités décrivent une solution que l'utilisateur a imaginée, pas le problème qu'il a. Quand quelqu'un demande le mode sombre, il souffre peut-être de fatigue oculaire sur une interface lumineuse lors de sessions tardives. Quand il demande l'export CSV, il essaie peut-être d'envoyer des données à son comptable. Ce sont des problèmes différents avec des solutions potentiellement différentes, parfois meilleures que celle proposée par l'utilisateur.

Le rôle du feedback n'est pas de vous donner un backlog de fonctionnalités. C'est de vous aider à comprendre où les utilisateurs rencontrent des frictions, ce qu'ils essaient d'accomplir, et pourquoi ils n'y arrivent pas.

Les deux types de demandes

Chaque demande de fonctionnalité appartient à l'une de ces deux catégories.

La première : une frustration exprimée sous forme de demande. "Pouvez-vous ajouter X pour que je n'aie plus à faire Y ?" L'utilisateur a un flux de travail douloureux. Il a imaginé une fonctionnalité pour le corriger. Sa proposition est peut-être bonne. Peut-être pas. Mais le problème sous-jacent est réel.

La deuxième : un vrai désir de capacité manquante. "Je paierais plus si vous construisiez X." L'utilisateur peut déjà faire ce qu'il a besoin. Il a identifié quelque chose qui rendrait votre produit beaucoup plus utile.

La première catégorie est plus courante et souvent plus précieuse pour la rétention. Si un utilisateur ne peut pas accomplir un flux principal sans contournement, corriger cela est plus urgent qu'ajouter une option agréable.

Pourquoi compter les votes induit en erreur

Quand vous avez 50 demandes, l'approche évidente est de trier par votes. "Export CSV" a 30 demandes, donc construire ça en premier.

Mais les votes vous disent ce que les utilisateurs veulent avoir, pas ce qui les bloque pour obtenir de la valeur. Une fonctionnalité dont 5 utilisateurs ont absolument besoin vaut plus qu'une fonctionnalité que 30 utilisateurs veulent occasionnellement. L'une est un problème de rétention. L'autre est une préférence.

La bonne question n'est pas "combien de personnes veulent ça ?" mais "que se passe-t-il pour les utilisateurs qui n'ont pas ça ?" Si la réponse est "ils partent" ou "ils contournent avec un processus douloureux," c'est votre priorité.

Lire entre les lignes

Quand vous recevez une demande, posez-vous : qu'est-ce que cette personne essaie de faire ? Pas : qu'est-ce qu'elle demande ?

"Le tableau de bord est confus" n'est pas une demande d'un meilleur tableau de bord. C'est un signal que les utilisateurs ne trouvent pas ce dont ils ont besoin. L'architecture de l'information est peut-être mauvaise. Il y a peut-être trop d'informations. Les labels sont peut-être flous. Vous ne pouvez pas le savoir sans comprendre la tâche sous-jacente.

"Pouvez-vous ajouter l'intégration Slack ?" ne signifie peut-être pas que l'utilisateur veut l'intégration Slack. Cela peut signifier qu'il a besoin d'être notifié quand quelque chose se passe dans votre produit, et Slack est l'outil qu'il a déjà ouvert. Une notification par email pourrait résoudre le problème à un dixième du coût d'implémentation.

Le contexte est tout

Pour qu'un feedback soit interprétable, vous devez savoir où l'utilisateur se trouvait au moment de l'envoi. L'URL de la page est la métadonnée la plus importante.

Un utilisateur qui dit "je ne trouve pas ce qu'il me faut" sur votre page de paramètres a un problème différent du même utilisateur disant la même chose sur votre tableau de bord principal. Sans le contexte de la page, vous ne pouvez pas diagnostiquer le problème.

Les bons outils de feedback capturent cela automatiquement. Vous ne devriez pas avoir besoin de demander aux utilisateurs "sur quelle page étiez-vous ?" Ils ont avancé depuis que vous lisez leur feedback. Le contexte doit être dans la soumission.

Un processus pour lire les retours

Quand vous consultez les feedbacks, parcourez cette séquence pour chaque élément :

1. Sur quelle page l'utilisateur se trouvait-il ?
2. Quel sentiment a-t-il exprimé ?
3. Qu'essayait-il de faire ?
4. Qu'est-ce qui l'en a empêché ?
5. À quoi ressemblerait "résolu" de son point de vue ?

Ce n'est qu'après avoir répondu à ces questions que vous devriez penser à ce que vous allez construire. La demande de fonctionnalité est le résultat de ce processus, pas son point de départ.

Les équipes qui créent des produits que les utilisateurs adorent ne sont pas celles qui implémentent chaque demande. Ce sont celles qui comprennent chaque demande et construisent la bonne solution au problème sous-jacent.