Thèse

Une taxonomie de retours clients est une échelle d'altitude, pas un rangement par sujet

Angle

Enjeu métier, cas d'usage, capacité produit, point de friction local ne sont pas quatre catégories d'un même plan : ce sont quatre altitudes, et l'altitude d'un verbatim est fixée par celle à laquelle le client a parlé, pas par le sujet dont il parlait. Cette échelle ne sert pas à ranger plus finement — elle sert à router : chaque palier est le seul point d'entrée d'une décision produit distincte, la stratégie en haut, la discovery et la roadmap au milieu, le design et le backlog en bas. Un référentiel qui écrase les quatre paliers sur un axe unique n'a donc pas seulement perdu du détail, il a coupé l'alimentation de trois arbitrages sur quatre — qui continueront de se prendre, sans les signaux qui devaient les nourrir.

Synthèse

Le problème se présente comme un problème de rangement : on centralise des retours dans Productboard ou Harvestr, et il faut bien une taxonomie. Posé ainsi, il n'a pas de solution — chaque axe candidat, la feature, l'enjeu, le thème, marche pour une partie de la matière et casse sur le reste.

Le déplacement qui débloque est de cesser de chercher le bon axe. Ce qui sépare « le bouton d'export est difficile à trouver » de « absorber la croissance sans recruter » n'est pas un sujet différent, c'est une hauteur différente ; les deux peuvent parler du même domaine fonctionnel. Une fois la hauteur reconnue comme la vraie dimension du problème, le classement cesse d'être une interprétation et devient une lecture de la formulation du client : quatre questions, quelques secondes.

Mais c'est la suite qui fait la valeur de l'échelle, et elle ne se voit dans aucun palier pris isolément. Chaque altitude a un consommateur et un moment : l'enjeu métier est ce dont on a besoin pour arbitrer un segment, l'action de travail est ce qui nourrit la discovery, la capacité est ce sur quoi une roadmap se discute, l'irritant situé est ce qu'un designer peut corriger la semaine suivante. Les quatre ne se rangent pas dans le même tiroir parce qu'ils ne partent pas vers les mêmes personnes.

D'où l'effet réel d'un axe unique, qui n'est pas celui qu'on croit. On imagine un déficit de finesse — on aurait mieux pu ranger. Le déficit est ailleurs : trois niveaux de décision se retrouvent sans matière. Rien ne se plaint, parce que les décisions se prennent quand même, avec ce qui est disponible. Une roadmap bâtie sur un référentiel écrasé au niveau des features paraît parfaitement documentée.

Reste la contrainte qui empêche de généraliser le raisonnement à l'infini. Une échelle se paie à chaque saisie, par la personne qui classe un verbatim après un entretien. Ajouter des paliers parce qu'ils se justifient conceptuellement produit un modèle juste que personne ne remplit — et un palier vide n'alimente aucune décision, exactement comme un palier absent. Quatre est un compromis, pas une vérité ; le critère qui l'a fixé est qu'au-delà, l'échelle cesse d'être appliquée.

Tensions / contradictions

Deux exigences s'opposent sans être départagées ici. Le routage vers les décisions pousse à ajouter des paliers — chaque décision mal alimentée réclame le sien. L'adoption pousse à en retirer, parce que le coût se paie à chaque saisie, par des gens dont classer n'est pas le métier. Le chiffre de quatre est le point d'équilibre d'un contexte, pas un résultat.

Seconde tension, dans l'échelle elle-même : le palier du cas d'usage vaut par son indépendance à toute solution, et il est encadré par deux paliers — capacité et friction — dont le vocabulaire est celui du produit. Un verbatim descendu trop vite d'un cran perd cette indépendance sans que rien ne le signale.

Questions

  • Les paliers que cette échelle distingue se conservent-ils quand le référentiel est partagé entre plusieurs équipes produit qui n'arbitrent pas au même endroit ?
  • Un retour classé à une altitude peut-il être remonté d'un cran plus tard sans réinterroger le client ?