La gestion produit, ce n'est pas construire davantage. C'est résoudre ce qui compte vraiment.

Pourquoi le produit commence par l'écoute

Entretien avec Jonathan Coll

Responsable Produit Principal 

Une conversation avec Jonathan a changé ma façon de voir le produit. Jonathan est Product Manager chez Avalo, où il contribue à façonner la plateforme Ionfi by Avalo. Vu de l'extérieur, le métier de produit peut sembler se résumer à décider ce qu'il faut construire et à remettre à l'ingénierie une liste d'exigences. Vu de l'intérieur, c'est quelque chose de plus discret et de plus exigeant : s'assurer que ce que l'on construit résout réellement le bon problème, pour la bonne raison. 

Lorsque je lui ai demandé de décrire son métier en termes simples, sa réponse m'a surpris. 

« Je dirais que c'est 75 % d'écoute et 25 % de construction », m'a-t-il confié. « Mon rôle est de donner au design et à l'ingénierie suffisamment de contexte pour qu'ils résolvent eux-mêmes le problème. » 

Ce contexte vient de partout : les clients, le support client, les opérations, la conformité, la technologie. Chacun voit une partie différente du tableau. Le rôle du produit n'est pas de décider quelle demande l'emporte. C'est de repérer les schémas récurrents, de comprendre l'impact business, et de s'assurer que toute l'équipe résout le même problème, pour la même raison. 

« Mon travail n'est pas de vous construire une fonctionnalité », a déclaré Jonathan. « Mon travail est de résoudre votre problème. » 

Cela signifie parfois poser une question de plus. Un client peut dire : mettez simplement ce module à cet endroit. Plutôt que de dire oui immédiatement, Jonathan demande pourquoi. 

« Quand un client vient me voir avec une idée de fonctionnalité, j'essaie d'aller un peu plus loin pour comprendre ce qu'il cherche réellement à résoudre », a-t-il expliqué. « Parfois, ce qu'on nous demande de construire n'est pas la meilleure solution, ou il existe un moyen plus simple de résoudre le problème. » 

Derrière la demande se cache généralement un objectif plus large : un flux de travail plus fluide, une adoption plus large, ou une meilleure expérience client. Comprendre cet objectif est ce qui permet à l'équipe de construire quelque chose d'utile, plutôt que de simplement ajouter une fonctionnalité de plus. 

Une histoire en particulier m'est restée en tête. Des clients créaient des virements, joignaient des pièces justificatives à un profil, puis soumettaient la transaction pour approbation. De leur point de vue, les documents se trouvaient déjà sur la plateforme. Mais les fichiers pertinents pouvaient se trouver noyés parmi des dizaines de documents du profil, générant une demande de suivi évitable pour quelque chose que le client pensait déjà avoir fourni. 

Jonathan a entendu des versions du même problème de la part de plusieurs clients 

« Ce sujet est revenu environ cinq fois lorsque j'ai interrogé différents clients », a-t-il dit. 

Plutôt que de traiter chaque cas comme une demande isolée, l'équipe a identifié la lacune sous-jacente. Cette prise de conscience a servi de base à une fonctionnalité permettant aux clients de joindre directement à un virement les documents pertinents de leur profil. Le contexte peut ainsi voyager avec la transaction, réduisant les allers-retours et accélérant l'examen. 

« La plupart des grands projets consistent en réalité à relier les points entre eux », a expliqué Jonathan. « On observe ce qui revient de manière récurrente. C'est ce qui nous aide à décider des priorités. » 

Deux éléments de notre conversation m'ont particulièrement marqué. 

D'abord, le produit est l'endroit où convergent différentes perspectives. Le support client entend directement la voix du client. La conformité et les opérations comprennent ce qui est nécessaire pour faire avancer une transaction. L'ingénierie sait ce qui peut être construit et comment le faire à grande échelle. Le design rend l'expérience intuitive. Jonathan aide ces équipes à partager un langage commun et à s'aligner autour du même résultat. 

"« La conformité et l'ingénierie ne parlent pas toujours le même langage, »" a-t-il expliqué. 

Une partie de son travail consiste à s'assurer que l'exigence, la raison qui la motive et le résultat visé sont compris par tous. 

Ensuite, le progrès n'implique pas nécessairement une rupture. À mesure que la plateforme continue d'évoluer, Jonathan s'attache à préserver les flux de travail sur lesquels les clients s'appuient déjà, tout en rendant claire la valeur de chaque changement. 

« Si nous nous contentons de migrer les utilisateurs sans expliquer les bénéfices, ils vont se demander pourquoi ils devraient changer », a-t-il dit. « Nous devons leur montrer : voici ce que vous nous avez dit être difficile, et voici comment nous l'avons résolu pour vous. » 

Aider les clients à reconnaître leur propre retour dans le produit, ai-je résumé. Il a acquiescé — c'est exactement cela. 

Un bon leadership produit, selon lui, ne consiste pas à livrer le plus grand nombre de fonctionnalités ou à courir après la dernière idée à la mode. Il s'agit de poser de meilleures questions, d'écouter au-delà des frontières internes, et d'aider l'équipe à concentrer son temps et son énergie sur ce qui compte le plus. 

Jonathan a décrit le produit comme un rôle de « touche-à-tout ». Cette polyvalence est peut-être sa force cachée. Son travail n'est pas de remplacer les spécialistes de chaque fonction. C'est de comprendre suffisamment chaque perspective pour les relier entre elles, gagner la confiance dans la durée, et faire avancer tout le monde dans la même direction. 

Les bons produits résultent rarement d'une seule percée décisive. Le plus souvent, ils naissent de dizaines de petits moments où quelqu'un écoute attentivement, repère un schéma récurrent, et transforme une frustration répétée en une meilleure façon de travailler. 

Jonathan contribue à rendre cela possible — avec réflexion, en collaboration, un problème à la fois.