Idée

Décrire un besoin au niveau du cas d'usage évite d'enfermer l'analyse dans une solution

Idée principale

« Qualifier un incident », « retrouver du contexte avant d'agir », « comparer plusieurs entités », « coordonner plusieurs personnes » : formulé ainsi, un besoin client nomme une action de travail et rien d'autre. Il ne dit pas par quel écran, quelle feature ni quelle mécanique le produit doit y répondre.

C'est précisément ce qui le rend exploitable longtemps. Un besoin enregistré comme « ajouter un bouton de comparaison » a déjà tranché la solution au moment de la collecte, et la trace de ce que le client cherchait à faire a disparu — on ne peut plus la rouvrir pour imaginer autre chose. Formulé au niveau de l'action, le même retour reste ouvert à plusieurs réponses produit, et il reste comparable à d'autres retours qui visaient la même action par des demandes différentes.

Ce niveau est aussi celui qui résiste le mieux au temps : les écrans changent, les features sont remplacées, mais qualifier un incident reste ce que fait un technicien.

Pourquoi c'est important

Cela protège la phase de discovery d'une décision prise trop tôt et par la mauvaise personne. Un client qui demande un bouton propose une solution ; l'enregistrer telle quelle fait entrer sa proposition dans le référentiel comme si c'était le besoin.

Cela crée aussi un point de regroupement. Trois demandes de features sans rapport apparent, rapportées au même job, révèlent une même action mal outillée — regroupement invisible tant que chaque demande reste rangée sous sa solution.

Nuances et limites

Remonter au job ne doit pas devenir une remontée systématique vers l'abstraction : un irritant précis reformulé en action métier générique perd le détail qui permettait de le corriger. Le niveau de l'action est un niveau de plus, pas un niveau qui absorbe les autres.

Et la formulation en job ne garantit rien sur la fréquence ni sur la valeur : elle dit ce que le client cherche à faire, pas combien de clients le cherchent.

Questions ouvertes

  • Comment vérifier qu'un job formulé par l'équipe produit correspond à ce que le client fait réellement, et non à ce qu'on a compris de son récit ?