Aller au contenu

Priorisation produit — choisir quoi travailler

Définition

La priorisation produit consiste à choisir quel problème traiter maintenant, face aux autres problèmes possibles et avec une capacité limitée.

Elle intervient avant le cadrage :

Étape Question
Stratégie Quels outcomes comptent ?
Priorisation Quel problème mérite notre capacité maintenant, et pourquoi plutôt qu'un autre ?
Cadrage Comment rendre ce sujet assez clair et borné pour avancer ?
Exécution Quelle action réalise-t-on ensuite ?

Prioriser n'est donc ni découper un sujet, ni classer des tickets, ni appliquer mécaniquement un score.

Ce qu'on priorise

On compare des problèmes ou opportunités, pas des solutions déjà détaillées.

Chaque candidat doit pouvoir tenir en quelques lignes :

  • Problème : qui souffre, de quoi, aujourd'hui ?
  • Preuve : quelle donnée, observation ou source le montre ?
  • Outcome concerné : quel changement cherche-t-on ?
  • Impact attendu : que gagne-t-on si le problème est résolu ?
  • Coût d'attente : que se passe-t-il si on ne fait rien maintenant ?
  • Incertitude : qu'est-ce qu'on ignore encore ?
  • Ordre de grandeur de l'effort : assez précis pour comparer, sans cadrage détaillé.

Une demande formulée comme une feature revient au problème avant d'entrer dans l'arbitrage (Lean PM).

Comment arbitrer

1. Partir du cap

Un sujet doit contribuer à un outcome stratégique ou à la north star de sa squad. Sinon, il doit expliquer pourquoi il mérite malgré tout de prendre de la capacité (area Produit).

Les contraintes obligatoires — réglementation, sécurité, engagement externe ou incident — sont identifiées à part. Elles ne sont pas maquillées en « fort impact produit ».

2. Comparer la valeur, la confiance et le coût

Pour chaque problème, poser cinq questions :

  1. Impact — quel outcome peut bouger, et pour combien d'utilisateurs ?
  2. Preuve — sur quoi repose cette estimation ?
  3. Confiance — quelle est la probabilité que le mécanisme imaginé fonctionne ?
  4. Effort et coût d'opportunité — que ne pourra-t-on pas faire si on choisit ce sujet ?
  5. Temporalité — pourquoi maintenant ? Y a-t-il une échéance, une dépendance ou un coût d'attente ?

ICE ou RICE peuvent rendre la comparaison explicite. Le score ne décide pas seul. Dans la priorisation Q3 de la squad Analyse, un sujet au score faible reste identifié comme un enjeu majeur, mais il est gelé tant que l'incertitude d'architecture n'est pas levée (priorisation Q3).

3. Chercher le levier

Deux sujets peuvent être prioritaires pour des raisons différentes :

  • Levier d'impact : il peut faire bouger directement l'outcome.
  • Levier d'apprentissage : un petit test peut invalider le pari le plus risqué.
  • Levier de déblocage : il ouvre plusieurs travaux en aval.

Le bon choix n'est pas toujours le sujet au plus gros impact théorique. Une courte vérification peut éviter plusieurs semaines de travail, ou débloquer une chaîne entière.

4. Décider explicitement

Chaque candidat reçoit une décision lisible :

  • Maintenant — capacité engagée et raison du choix.
  • Ensuite — prochain sujet si les conditions restent les mêmes.
  • Plus tard — utile, mais pas prioritaire dans la fenêtre actuelle.
  • Pas maintenant — refus assumé, avec la raison ou la condition de réouverture.

Pour les sujets retenus, préciser un owner, une capacité ou un appétit, et une date de revue. Limiter le nombre de sujets actifs : la squad Analyse utilise par exemple un maximum de deux items en cours pour éviter les tunnels (priorisation Q3).

Qui est dans la boucle

Le responsable produit prépare la comparaison et porte une recommandation. Il n'organise pas un vote.

  • Métier / utilisateurs : apportent les preuves, les contraintes et le coût du problème.
  • Tech et design : donnent l'ordre de grandeur, les dépendances et les risques. Ils ne cadrent pas toute la solution à ce stade.
  • Responsable produit : relie les sujets aux outcomes et propose l'ordre.
  • Leadership : tranche les arbitrages qui engagent plusieurs squads, une contrainte stratégique ou un engagement de l'entreprise. Ce niveau sert aux décisions collectives, pas à la discovery.

Une décision doit avoir un décideur identifiable. « Tout le monde est aligné » ne remplace pas l'owner de l'arbitrage.

Quand revoir une priorité

Une priorité change quand une information utile change :

  • une nouvelle preuve invalide l'impact attendu ;
  • une contrainte ou une échéance apparaît ;
  • une dépendance est débloquée ;
  • un test réduit fortement l'incertitude ;
  • la capacité disponible change ;
  • l'outcome est atteint ou n'est plus stratégique.

Sans changement de ce type, rejouer le débat ne produit pas une nouvelle décision (réflexe 8).

Sortie attendue

La sortie de la priorisation est un portefeuille court et compréhensible :

  1. les sujets Maintenant, ordonnés et reliés à un outcome ;
  2. le sujet Ensuite ;
  3. les sujets écartés, avec la raison ;
  4. les arbitrages qui doivent remonter au leadership ;
  5. la date ou le signal de prochaine revue.

Une fois un sujet retenu, il entre dans le cycle de cadrage. Les issues arrivent après le cadrage, dans le project Linear correspondant.

État actuel

Dernière mise à jour : 2026-09-16

  • V1 — séparation explicite entre choix du portefeuille, cadrage d'un sujet et exécution.
  • À roder sur le prochain arbitrage de roadmap.

Sources