Stanford Online : l'IA évalue l'impact et le coût, mais c'est l'humain qui choisit la priorité

Stanford Online a publié une vidéo dans laquelle Anand Subramani, enseignant à l'université Stanford, et Jiaona « JZ » Zhang, Chief Product Officer de Laurel, passent en revue la priorisation du roadmap produit. Leur schéma comporte trois étapes : estimer l'impact, estimer le coût, puis prendre une décision qu'un tableur est incapable de prendre. L'IA, selon eux, est adaptée à un test de résistance des deux premières étapes. Elle ne remplace pas la troisième.

Une limite d'emblée : nous ne disposons que de la description de la vidéo, sans transcription complète. Les thèses ci-dessous sont donc rapportées telles qu'annoncées, et les conclusions pratiques sont signalées comme notre interprétation.

Trois étapes, dont deux que le modèle peut éprouver

Les deux premières étapes sont familières à tout product manager. D'abord, l'estimation de l'impact : combien d'utilisateurs la fonctionnalité touchera, ce qu'elle changera en matière de rétention, de revenus ou de charge pour le support. Ensuite, l'estimation du coût : semaines d'ingénierie, dépendances envers d'autres équipes, coût de maintenance après la sortie. Ces deux estimations tiennent dans un tableau, que l'on peut trier selon le rapport bénéfice/coût.

C'est précisément là, selon les intervenants, que l'IA apporte son aide. Le mot clé de la description de la vidéo est « pressure-test », c'est-à-dire un test de résistance. On peut demander au modèle de repérer les hypothèses fragiles dans la prévision d'impact, de rappeler des dépendances cachées, de comparer l'estimation à des projets similaires ou de poser des questions gênantes sur les chiffres. Il joue le rôle d'un contradicteur pointilleux en réunion, pas celui d'auteur de la liste finale.

Où s'arrête le tableau

La description qualifie la troisième étape de décision de jugement (« judgment call »). Deux colonnes d'estimations ne savent rien de la stratégie de l'entreprise, du risque de perdre un client clé, du moral de l'équipe, ni de ce qu'un concurrent lancera dans un trimestre. Ces facteurs se traduisent mal en chiffres, et c'est un humain qui en porte la responsabilité.

Les intervenants formulent une question de contrôle : « Pourquoi est-ce en première position ? » Si la réponse est « l'IA l'a décidé », il s'agit, selon leur formulation, d'une externalisation de sa propre réflexion. Un product manager incapable d'expliquer la logique d'une priorité sans renvoyer au modèle ne maîtrise pas son roadmap.

• Format : vidéo Stanford Online, publiée le 15 octobre 2026.
• Participants : Anand Subramani (enseignant à Stanford), Jiaona « JZ » Zhang (Chief Product Officer, Laurel).
• Nombre d'étapes dans le schéma : trois — impact, coût, jugement.
• Ce qui est délégué à l'IA : le test de résistance des estimations d'impact et de coût.
• Ce qui reste à l'humain : la décision finale et sa justification.
• Question de contrôle : « Pourquoi est-ce tout en haut ? »

Comment l'appliquer

Ci-dessous, notre interprétation des thèses, et non des citations de la vidéo.

Premièrement : utilisez le modèle une fois vos propres estimations consignées. Si vous lui laissez produire la première ébauche, vous risquez de vous ancrer sur ses chiffres plutôt que sur vos hypothèses. D'abord votre tableau, ensuite la requête « trouve où je me trompe ».

Deuxièmement : demandez une critique, pas un classement. La formulation « énumère cinq raisons pour lesquelles cette prévision est surestimée » est plus utile que « trie les tâches par importance ».

Troisièmement : consignez la justification de la priorité avec vos propres mots, en un paragraphe. Si vous n'y parvenez pas sans la phrase « le modèle a calculé », la décision n'est pas encore prise.

Quatrièmement : séparez les données d'entrée du verdict. L'IA peut enrichir les entrées, par exemple en ajoutant des risques et des alternatives. Le verdict revient à celui qui l'expliquera ensuite à l'équipe, à la direction et aux clients.

Le contenu est plus méthodologique qu'informatif. Il n'annonce ni nouveaux produits ni métriques, mais décrit la frontière de travail entre automatisation et responsabilité que de nombreuses équipes produit sont en train de tracer en pratique.