Le Product Goal est l'une des évolutions les plus importantes du Scrum Guide 2020. Il constitue l'engagement du Product Backlog et sert de cap à long terme à toute la Scrum Team. Souvent négligé en entreprise, il est pourtant central pour donner du sens au produit — et fréquemment testé à l'examen PSM I.
Définition officielle du Product Goal
Le Scrum Guide 2020 énonce : « Le Product Goal décrit un état futur du produit qui peut servir de cible à la Scrum Team pour planifier. Le Product Goal se trouve dans le Product Backlog. Le reste du Product Backlog émerge pour définir « quoi » remplira le Product Goal. »
Trois idées clés :
- Un état futur du produit : ce n'est pas une fonctionnalité, ni une liste de tâches. C'est un résultat observable pour l'utilisateur ou le marché.
- Une cible pour planifier : le Product Goal oriente chaque Sprint Planning et chaque décision d'ordonnancement du Product Backlog.
- Situé dans le Product Backlog : le reste du Product Backlog émerge pour le remplir. Ce qui n'y contribue pas n'a pas sa place au sommet du backlog.
Pourquoi le Product Goal existe
Avant la révision 2020 du Scrum Guide, de nombreuses Scrum Teams travaillaient Sprint après Sprint sans direction claire au-delà de l'itération courante. Le Product Backlog devenait une liste hétéroclite de fonctionnalités, sans fil rouge. Le Product Goal comble ce manque en remplissant quatre fonctions essentielles.
Donner une direction
Le Product Goal transforme le Product Backlog en plan orienté résultat. Sans lui, chaque Sprint est un morceau isolé. Avec lui, chaque Sprint devient un pas mesurable vers un cap partagé.
Aligner la Scrum Team et les parties prenantes
Formulé et rendu visible, le Product Goal permet à tout le monde — Developers, Product Owner, sponsors, utilisateurs internes — de savoir pourquoi on développe telle ou telle fonctionnalité et de prioriser les échanges en Sprint Review autour de ce même horizon.
Faciliter les arbitrages
Un Product Owner armé d'un Product Goal a un critère simple pour dire non : « cette demande, aussi séduisante soit-elle, ne contribue pas à notre Product Goal en cours ». C'est un puissant outil de focus.
Permettre l'empirisme à l'échelle produit
Le Product Goal rend possible l'empirisme au-delà d'un Sprint : transparence sur l'ambition, inspection régulière des progrès (Sprint Review), adaptation du backlog en fonction des apprentissages.
Qui définit le Product Goal ?
Le Scrum Guide est sans ambiguïté : le Product Owner est responsable du Product Goal, comme il l'est du Product Backlog. Cela ne veut pas dire qu'il l'invente seul dans son coin.
| Acteur | Rôle sur le Product Goal |
|---|---|
| Product Owner | Formule le Product Goal, en garantit la cohérence avec la Vision, décide de son évolution ou de son abandon. Responsable final. |
| Developers | Contribuent en apportant leur expertise technique (faisabilité, coût, risques). Ils s'engagent ensuite à formuler un Sprint Goal qui y contribue. |
| Scrum Master | Coache le Product Owner sur la formulation, aide la Scrum Team à comprendre l'importance du Product Goal, veille à sa visibilité. |
| Parties prenantes | Apportent leurs besoins, contraintes de marché et retours utilisateurs. Consultées, jamais décisionnaires. |
| Management | Peut orienter (stratégie, budget, contraintes réglementaires), mais n'impose pas la formulation du Product Goal. |
Exemples de Product Goal par secteur
Un bon Product Goal est mesurable, orienté valeur et ancré dans un horizon produit. Voici plusieurs exemples réalistes, secteur par secteur.
« Permettre à 90 % de nos clients particuliers d'ouvrir un compte en moins de 5 minutes, entièrement en ligne. »
Résultat mesurable, orienté client, indépendant des fonctionnalités précises à livrer.
« Devenir la marketplace de référence en France pour la revente d'équipements de padel d'ici 12 mois. »
Ambition produit claire, cadre temporel, décliné ensuite en Sprint Goals concrets.
« Réduire de 50 % le temps moyen de clôture comptable mensuelle pour nos clients PME. »
Impact utilisateur explicite, mesurable, sans imposer de solution technique.
« Permettre à 100 % des managers de piloter leurs entretiens annuels sans support de l'équipe RH. »
Objectif de valeur, mesurable via l'usage réel et le nombre de tickets support.
« Augmenter à 65 % le taux de complétion des parcours certifiants sur 6 mois. »
Indicateur central du business, laisse la Scrum Team libre du comment (UX, contenu, gamification…).
« Atteindre 90 % d'auto-onboarding sans intervention manuelle du support. »
Résultat business et opérationnel, aligné avec la réduction du coût d'acquisition.
« Permettre la souscription 100 % en ligne d'un contrat auto en moins de 8 minutes. »
Cap clair, mesurable, décliné en Sprint Goals autour du parcours, des paiements et des données.
« Passer de 3,5 à 4,5 étoiles de note moyenne sur les stores d'ici 6 mois. »
Résultat produit observable, exigeant travail sur bugs, performance et valeur perçue.
Bon vs mauvais Product Goal
La différence entre un Product Goal utile et un Product Goal « décoratif » se joue sur trois critères : orienté résultat, mesurable, relié à la valeur.
« Réduire de 40 % le taux d'abandon du tunnel de paiement mobile d'ici 6 mois. » — résultat observable, mesurable, laisse la Scrum Team libre du comment.
« Refaire le tunnel de paiement. » — décrit une solution, pas un résultat. Aucun critère de succès, aucune valeur exprimée.
« Permettre l'onboarding d'un nouveau client entreprise en self-service, sans support manuel. »
« Livrer les 47 tickets Jira du backlog Q3. » — c'est une liste de tâches, pas un objectif produit.
« Atteindre la conformité NIS 2 sur l'ensemble du produit avant l'échéance réglementaire. »
« Améliorer le produit. » — trop vague, ne permet ni de trancher, ni de savoir si on l'atteint.
Tous les PBI contribuent au Product Goal. Ce qui n'y contribue pas est retiré ou reporté.
Product Goal vs Sprint Goal
Confusion numéro 1 au PSM I. À retenir : ils n'ont pas le même horizon, pas le même artefact, pas le même engagement.
| Critère | Product Goal | Sprint Goal |
|---|---|---|
| Horizon | Plusieurs Sprints, souvent 1 à 6 mois | Un seul Sprint |
| Engagement de… | Product Backlog | Sprint Backlog |
| Responsable | Product Owner | Défini en collaboration au Sprint Planning |
| Nombre en parallèle | Un seul à la fois | Un seul par Sprint |
| Peut changer ? | Rarement (pivot, apprentissage) | Non pendant le Sprint, mais peut être renégocié |
| Rôle | Cap long terme | Focus immédiat |
Un Sprint Goal qui ne contribue à aucun Product Goal est un signal d'alerte : soit le Sprint Planning a dérivé, soit le Product Goal est obsolète.
Product Goal vs Vision produit
La Vision est l'ambition ultime du produit, souvent sur plusieurs années. Elle est stable et inspirante. Le Product Goal est un jalon intermédiaire qui rend cette Vision atteignable.
| Critère | Vision produit | Product Goal |
|---|---|---|
| Horizon | Plusieurs années | Plusieurs Sprints (mois) |
| Stabilité | Très stable | Stable mais peut évoluer |
| Précision | Inspirationnelle, qualitative | Mesurable, orientée résultat |
| Nombre | Une seule | Un à la fois, plusieurs successifs |
| Portée dans le Scrum Guide | Pas définie formellement | Engagement du Product Backlog |
Product Goal vs Product Backlog
Le Product Backlog est la liste ordonnée de tout ce qui est nécessaire pour améliorer le produit. Le Product Goal en est l'engagement : le cap qui donne du sens aux Product Backlog Items et guide leur ordonnancement.
- Le Product Backlog est émergent : il se raffine pour remplir le Product Goal.
- Ce qui ne contribue pas au Product Goal est retiré ou reporté.
- Le Product Owner ordonne les PBI selon leur contribution au Goal.
Product Goal vs Roadmap
La Roadmap est un outil de communication qui projette les livraisons dans le temps. Le Product Goal est un résultat à atteindre, indépendant du calendrier détaillé.
| Critère | Roadmap | Product Goal |
|---|---|---|
| Nature | Plan de livraison | Résultat à atteindre |
| Format | Frise temporelle, jalons | Phrase d'engagement mesurable |
| Stabilité | Ajustée régulièrement | Stable jusqu'à atteinte / abandon |
| Relation | Peut décliner plusieurs Product Goals successifs | Engagement Scrum, obligatoire |
Product Goal vs Increment
L'Increment est un pas concret vers le Product Goal. Chaque Increment livré, conforme à la Definition of Done, rapproche la Scrum Team de son Product Goal. Sans Increment livré, pas de progrès vers le Goal — la Sprint Review sert justement à inspecter cette progression.
Peut-on changer un Product Goal ?
Oui, mais avec discernement. Le Product Goal est un engagement, pas un tabou. Trois situations légitimes :
- Apprentissage majeur : les retours utilisateurs ou des données remettent en cause l'hypothèse initiale.
- Changement de contexte : marché, réglementation, concurrence, contrainte technique bloquante.
- Atteinte : le Product Goal est atteint (célébrer), le Product Owner formule le suivant.
Erreurs fréquentes sur le Product Goal
Le Product Goal couvre plusieurs Sprints ; le Sprint Goal, un seul. Confusion la plus fréquente au PSM I.
Le Scrum Guide impose un seul Product Goal à la fois. Deux Goals en parallèle = perte de focus garantie.
C'est le Product Owner qui en est responsable. Le Scrum Master coache, il ne décide pas du contenu.
Un Product Goal exprime un résultat, pas les moyens d'y arriver. « Livrer X, Y, Z » n'est pas un Product Goal.
Un Product Goal ni atteint ni abandonné bloque le pipeline produit. Le Product Owner doit trancher : célébrer, ajuster ou stopper.
S'il n'est pas rendu visible (backlog, Sprint Review, dashboards), il perd sa fonction d'alignement. La transparence est un pilier de Scrum.
Chaque Sprint Goal doit contribuer au Product Goal. Sinon, le Sprint Planning a dérivé — ou le Product Goal est obsolète.
Le Product Owner est responsable. Un Goal imposé sans son adhésion annule sa capacité à arbitrer.
Questions pièges PSM I sur le Product Goal
S'entraîner au PSM I sur le Product Goal
Comprendre le Product Goal est indispensable pour viser 85 % au PSM I. Sur PasseTonScrum, vous vous entraînez sur des questions représentatives, avec le même format qu'à l'examen — et des explications détaillées pour chaque réponse.