Devenir PM à l'ère de l'IA 08 | L'IA ne peut pas trouver le vrai problème à votre place

a16z a écrit un article destiné aux product managers, dont le titre, traduit littéralement, donne : « 5 principes pour échapper à l’obsolescence en tant que product manager à l’ère de l’IA ». Une phrase y vise juste : le product manager fait par nature un métier qui consiste à dissiper l’ambiguïté ; l’IA n’a pas rendu cette ambiguïté moins présente, elle a juste changé les outils.

Reprenons les articles précédents bout à bout : l’IA peut vous aider à juger (en réalité, elle vous donne des options, c’est vous qui tranchez), elle peut vous aider à fabriquer le besoin, elle peut transformer une phrase en produit. Mais il y a une chose qu’elle n’a jamais touchée, du début à la fin — trouver ce vrai problème qui mérite d’être résolu. Où l’utilisateur coince vraiment, si c’est un vrai problème, si la chose vaut le coup : à tout cela, elle ne peut pas vous donner de réponse, parce que la réponse n’est pas dans ses données d’entraînement, elle est dans le monde réel, chez une personne bien précise.

C’est aussi la raison pour laquelle a16z dit que « le pur chef de processus sera éliminé, celui qui a un état d’esprit de bâtisseur a du levier » : celui qui sait relancer le planning et faire de l’alignement, l’IA peut en remplacer une partie ; celui qui sait trouver le vrai problème et qui ose vérifier en mettant la main à la pâte, elle ne peut pas le remplacer. Cet article décrit quatre gestes concrets de la phase de découverte.

1. Ne laissez pas l’IA réfléchir au besoin à votre place : allez voir sur le terrain où ça coince

La paresse la plus tentante, c’est d’ouvrir l’IA et de lui demander « quelle fonctionnalité devrais-je ajouter à mon produit ». Elle vous rendra une liste bien lisse, qui a l’air sérieuse — rien que des fonctionnalités courantes vues ailleurs, pas une seule qui ait poussé à partir de vos vrais utilisateurs.

L’IA ne peut que recombiner ce qu’elle a déjà vu ; elle ne voit pas ce point de douleur que personne n’a encore formulé. Cette partie-là, vous seul pouvez la faire : trouvez un vrai utilisateur, asseyez-vous à côté de lui, regardez-le faire la chose avec votre produit (ou avec le bricolage qu’il utilise aujourd’hui), et observez à quelle étape il fronce les sourcils, hésite, ou lâche un juron. Ce point de blocage, l’IA ne pourra jamais le voir à votre place.

2. Distinguez « ce qu’il réclame » de « ce qui le coince vraiment »

Le plus gros piège de la phase de découverte, c’est de prendre directement le besoin que l’utilisateur formule pour la fonctionnalité à construire.

Il y a un vieil exemple : l’utilisateur dit qu’il veut un cheval plus rapide ; le vrai problème, c’est qu’il veut arriver plus vite à destination. Le vrai problème se cache dans ses paroles, mais il en est rarement l’équivalent direct. Quand il dit « est-ce qu’on peut ajouter un export Excel », derrière il y a peut-être « chaque semaine je dois pousser ces données dans un autre système, copier à la main est trop pénible » — le vrai problème, c’est que les deux systèmes ne communiquent pas, l’export n’étant que la solution qui lui est venue à l’esprit. Si vous suivez son « ajouter un export », une fois fini il continuera de souffrir chaque semaine.

Écoutez ce qu’il dit, mais gardez les yeux sur ce qu’il fait. Le comportement est plus honnête que les paroles.

3. Repérez les « bricolages » — c’est le signal le plus solide du vrai problème

Comment juger si un problème mérite vraiment d’être résolu ? Regardez si quelqu’un se débrouille déjà avec un bricolage pour le contourner.

Quand quelqu’un, pour une seule chose, accepte d’exporter un tableau à la main chaque semaine, de monter un groupe WeChat en bazar, de noter une pile de choses dans son bloc-notes, ou de faire tout un détour en assemblant trois outils — ces « bricolages » sont le signal le plus solide : la douleur est réelle, assez réelle pour qu’il accepte de dépenser un effort supplémentaire. Ce que vous avez à faire, c’est souvent de remplacer ce bricolage. À l’inverse, si personne n’est prêt à dépenser le moindre effort en plus pour un problème, c’est qu’il fait sans doute moins mal que vous ne le pensiez : l’IA aura beau aller vite, ce qu’elle produira ne servira à personne.

4. Explorez avec un état d’esprit de bâtisseur, n’attendez pas que le besoin soit complet pour bouger

Une fois un vrai problème présumé trouvé, ne vous arrêtez pas à l’étude et au document, et n’attendez pas non plus d’avoir pensé le besoin dans son intégralité pour vous lancer. L’état d’esprit de bâtisseur dont parle a16z devient ici très concret : avec le dire pour qu’il existe vu dans les articles précédents, faites le jour même la plus petite chose qui tourne, et apportez-la à cet utilisateur pour qu’il clique dessus.

« Est-ce que ça règle l’embêtement dont tu viens de parler ? » — poser cette question avec quelque chose de cliquable est bien plus juste qu’avec un questionnaire. Il clique deux fois, dit « ça, ce n’est pas bon, en fait je voulais… », et votre compréhension du vrai problème se rapproche d’un cran. On approche le vrai problème en construisant au fur et à mesure, pas en le pensant d’un seul coup dans un document.

Une chose à faire dès aujourd’hui : choisissez une fonctionnalité que vous comptez justement construire, et avant d’ouvrir l’IA, allez trouver un vrai utilisateur (un collègue fait l’affaire), demandez-lui comment il a fait la dernière fois cette chose, et avec quel bricolage il se débrouille aujourd’hui. Ce bricolage-là, c’est votre porte d’entrée vers le vrai problème.

Pour aller plus loin

• a16z, « 5 Principles for Product Managers Fending Off Obsolescence in the AI Era » (état d’esprit de bâtisseur vs pur chef de processus) : https://a16z.com/stay-relevant-in-ai/
• Le quatrième article de cette série, « Juger “faut-il le faire” coûte, pour la première fois, plus cher que “peut-on le faire” » : /fr/blog/judgment-over-feasibility/
• Le premier article de cette série, « Quelles tâches du product manager l’IA s’est-elle emparée, et lesquelles valent au contraire plus cher » : /fr/blog/ai-pm-what-changed/