PO, Product Manager, Scrum Master : qui fait quoi

Trois rôles qu'on confond tout le temps

Ces trois intitulés se chevauchent selon les entreprises, et c'est une vraie source de galère quand on débute. Une anecdote pour situer : sur ma première mission, j'ai passé trois semaines à construire une roadmap de six mois avant de comprendre qu'un Product Manager la faisait déjà deux étages au-dessus, et qu'on attendait de moi des stories prêtes pour le sprint suivant. Personne ne me l'avait dit, parce que tout le monde croyait que c'était évident. Voici les repères qui tiennent dans la majorité des organisations.

Le Product Manager (PM) regarde vers l'extérieur et vers le long terme : le marché, la concurrence, le business model, la roadmap sur plusieurs trimestres, la rentabilité. Il répond à "quel produit construire et pourquoi c'est un bon pari".

Le Product Owner (PO) regarde vers l'équipe et vers l'exécution : traduire la stratégie en backlog, écrire les stories, être disponible pour les développeurs, valider ce qui est livré. Il répond à "comment on construit ça, dans quel ordre, et est-ce conforme".

Le Scrum Master (SM) ne s'occupe pas du produit du tout. Il s'occupe de l'équipe et du processus : lever les blocages, protéger l'équipe des interruptions, faire progresser la maturité agile, faciliter les cérémonies. Il répond à "comment l'équipe travaille mieux ensemble".

Dans les faits, ça dépend de la taille

Dans une startup de quinze personnes, une seule personne cumule souvent PM et PO. On l'appelle parfois "PO stratégique" ou simplement Product Manager, et elle fait tout, de la vision au ticket Jira. C'est intense mais cohérent : les décisions stratégiques et d'exécution restent dans la même tête.

Dans un grand groupe, les rôles se séparent : un PM pilote la vision de plusieurs équipes, chaque équipe a son PO qui exécute. Beaucoup de POs débutants sont en réalité des "PO features", des scribes de backlog sans mandat stratégique. Ce n'est pas grave pour commencer, mais il faut le savoir, sinon on croit qu'on décide alors qu'on exécute des décisions prises ailleurs. Le signe qui ne trompe pas : si tu découvres la roadmap en même temps que l'équipe, tu es un PO d'exécution. Négocie au moins un siège dans les discussions qui la fabriquent.

À noter aussi : le Scrum Guide, lui, ne connaît pas le titre de Product Manager. Il ne décrit que le Product Owner, avec un mandat complet incluant la stratégie. La séparation PM/PO est une invention des grandes organisations, pas de Scrum. C'est pour ça que les définitions varient autant d'une boîte à l'autre : demande toujours, en arrivant, qui décide de la roadmap et qui ordonne le backlog. Les réponses à ces deux questions te disent ce qu'on attend vraiment de toi, quel que soit le titre sur la fiche de poste.

Le test qui clarifie tout

Face à une demande, pose-toi : de quoi je parle ?

• "Faut-il attaquer le marché des trajets scolaires avec Covio ?" → question de PM (stratégie, marché).
• "La story 'annuler un trajet jusqu'à 1h avant' passe-t-elle avant 'noter son conducteur' ?" → question de PO (priorité du backlog).
• "Pourquoi la daily dure 40 minutes et personne n'écoute ?" → question de Scrum Master (processus).

À toi

Classe chacune de ces quatre situations : PM, PO ou SM ?

1. L'équipe n'arrive jamais à finir ce qu'elle prend en sprint, les stories débordent systématiquement.
2. Un concurrent vient de lever 20 M€ pour attaquer le covoiturage rural : faut-il réagir ?
3. La story "remboursement automatique" doit-elle sortir avant la fin du trimestre pour tenir le KR d'annulation ?
4. Deux développeurs sont en conflit ouvert depuis deux sprints et l'ambiance plombe les réunions.

Correction : 1 = SM (problème de processus : engagement trop gros, découpage, estimation — le SM aide l'équipe à le voir en rétro). 2 = PM (analyse concurrentielle, pari de marché). 3 = PO (ordre du backlog au service d'un objectif trimestriel). 4 = SM (santé de l'équipe). Si tu as hésité sur la 1 en pensant "PO, c'est lui qui met trop de choses dans le sprint" : non, c'est l'équipe qui s'engage sur le volume, pas le PO — on y revient dans la leçon sur le sprint planning.

Le triangle qui fonctionne

La bonne équipe, c'est un PO qui porte la valeur, un Scrum Master qui fluidifie, une équipe de dev qui construit : trois responsabilités qui se respectent. Le SM n'est pas le chef du PO, le PO n'est pas le chef des devs. Personne ne commande, chacun a un domaine. Quand ce triangle est sain, les désaccords portent sur le fond ("cette story a-t-elle plus de valeur que celle-là ?") et pas sur le territoire ("de quoi je me mêle ?").

À retenir : si ton Scrum Master priorise ton backlog ou si ton PM écrit tes critères d'acceptation, quelqu'un fait le travail d'un autre. Ça marche un temps, ça finit toujours mal.