Idée principale

Une interview client ne devient pas exploitable en devenant une carte. Elle le devient quand elle est transcrite, découpée en thèmes, reliée aux douleurs exprimées, aux enjeux du client, aux enjeux produit, aux fonctionnalités existantes et à celles qui manquent, croisée avec d'autres entretiens, puis vérifiée dans les données produit. Tout ce travail porte sur des relations ; une liste, par construction, ne connaît que des éléments et leur ordre.

C'est pourquoi l'expression « backlog de discovery » désigne un mauvais contenant plutôt qu'une mauvaise pratique. La discovery manipule un matériau riche qu'il faut comparer, relier, croiser, reformuler et synthétiser. Ce que produit la discovery peut évidemment finir en carte — mais seulement à la fin, quand un résultat est assez mûr pour une collaboration structurée.

Pourquoi c'est important

Cela donne un critère pour choisir un contenant : avant de demander si l'outil a les bons champs, regarder si le matériau vaut par ses éléments ou par leurs liens. La réponse décide seule de la forme.

Cela explique aussi pourquoi un entretien versé directement en tickets se perd : chaque carte survit, la structure qui les reliait n'a jamais été écrite quelque part.

Nuances et limites

Une liste peut approcher la relation par des tags, des liens entre cartes ou des épopées. Le coût de maintien de ces liens croît plus vite que leur nombre, et ils cèdent les premiers.

Et tout matériau n'est pas relationnel : une file d'exécution — corriger, livrer, vérifier — est correctement décrite par une liste ordonnée.

Questions ouvertes

• À quel moment un résultat de discovery est-il assez stable pour perdre ses relations sans perdre son sens ?