La définition du métier de PO

Accueil > Les cours > Le portail du Product management > La définition du métier de PO

Cet article fait partie d'une série d'article "Paroles d'aspirant.e.s PO/PM" proposés par les étudiants que je suis sur la formation Product Owner et Product Manager sur OpenClassrooms.

Bonjour, je suis Ouled-Alla Mohamed Amine. Je débute ma formation en tant que Product Owner.

Le premier module de cette formation se voulait introductif : Donner une définition du métier. Après écoute de nombreuses présentations, je remarque un champ lexical commun : des sprints ?, un backlog ?, une manière agile de travailler... et tous parlent ‘’d’une méthode scrum.’’ 

Je comprends qu’il faut donc orienter les recherches sur cette notion de scrum. Je vous partage donc, avec mes mots, ma compréhension de la méthode scrum. 

Je vous mets en gras les mots qui font le champ lexical de la méthode scrum.

Scrum c’est d’abord une équipe. 

Si je devais donner une définition simple : permettre de délivrer et de modifier un projet, un produit ou une fonctionnalité très rapidement.

On a un chef d’équipe (le product owner) qui représente le client. Il va écouter sa demande (je veux tel produit, telle fonctionnalité ) et la retranscrire à l’équipe.

Alors, mieux que la retranscrire... Il va les valider avec le client, les modeler, les simplifier et surtout prioriser les demandes.

Scrum c’est aussi un processus. C’est là que c’est intéressant car on suit clairement un processus mais pour autant celui-ci nous offre beaucoup de souplesse et d’agilité. On le

verra plus bas...

Le product owner arrive donc pour présenter le projet à son équipe (développeur, designer, etc…). On parle alors de user story : décrire l’expérience utilisateur en utilisant le langage, le vocabulaire du client.

Chaque user story peut comporter : ID , une priorité , une estimation du temps, démo, mais

aussi des wireframes (représentation visuelle)....

Super, on a donc partagé le projet à la team. 

On va s’assurer que tout le monde a bien compris la demande client mais aussi se garantir du respect des process scrum. Pour ce dernier point c’est la responsabilité du Scrum master (qui est très souvent le rôle aussi du

PO)

user story --->  exigences ---> product backlog

Le product backlog : il sera notre carnet de commande pour le produit. Le listing de réalisation

il est amené à constamment évoluer…Là aussi nous le verrons très vite pourquoi il va évoluer et pourquoi donc nous parlons de méthode agile.

Sprint planning meeting : réunion de planification. Dans cette séance on va aller puiser les éléments prioritaire du backlog qui seront développé dans des sprints.

on récapitule : user story ✅ list backlog priorisé ✅ --> On a fait notre réunion, c’est parti !!

Encore un nouveau mot: Sprint. 

Ce sont les sessions de travail (qui durent en moyenne 2 semaines). 

Le but de ce sprint : développement + contrôle qualité + livraison. Plutôt que de partir sur un marathon du travail, on part sur des sprints. On livre et on sollicite à chaque fin de sprint l’avis du client. Petite info, on appelle sprint backlog l’ensemble des livraisons cumulés.

Un point hyper important : scrum meeting : 15 min , réunion journalière avec 3 points :

• Ce que j’ai fait la veille

• Ce que je fais aujourd’hui

• Problèmes bloquant ?

Voilà aussi le rôle du PO, le suivi journalier quant au bon déroulement du sprint. Il va chaque jour retranscrire et suivre cela grâce à son burn down chart : graphique qui décrit l’évolution du projet, la codification des séances scrum.

Le sprint est fini ? Let’s go sprint meeting review : On réalise une démonstration au client.

Lors de cet entretien : des modifications ? problème ? ----> cela sera ventilé sur le Product backlog et on repart sur des sprints... etc..

Grâce à ces sprints, on est capable de rapidement accepter les retour du client et les introduire dans notre carnet de route.

Voilà pourquoi depuis le départ on insistait sur cette notion d’agilité. Ce travail saccadé de sprint nous permet, de ne pas nous lancer tête baissée. Au contraire, on prend le temps de comprendre le client, de hiérarchiser, prioriser et ainsi subdiviser le travail. On avance prudemment, on peut ainsi s’adapter au retour client.

Je ferai un rapide parallèle avec la méthode lean. Une fois votre minimum viable product trouvé, il faut très vite le lancer sur le marché. En fonction des retours, on poursuit ou on pivote. Eviter le travail inutile, la perte de temps, c’est aussi ça être agile.

J’en ai donc conclus que le meilleur moyen de décrire le métier de product, c’est d’abord de décrire la méthode Scrum. Le PO s’adapte à la méthode 💪

Merci de m’avoir lu. Merci Samuel (mon mentor pour cette formation) de m’avoir offert cette tribune. J’espère avoir été clair, encore une fois il s’agit de ma compréhension et surtout vous avoir donné le goût d’en découvrir davantage.

On continue sur notre lancée….

Après la méthode on découvre des outils.

Pour cette étape de la formation, l'exercice est celui-ci : nous sommes en 2009. Airbnb lève des fonds, ils veulent maintenant scale et former une équipe. J'ai donc proposé mes services en tant que PO 😉

L'idée étant de synthétiser l'ensemble des informations au travers d'outils et ainsi les mettre en perspective. Je vais donc lister l'ensemble des outils, leur donner une définition personnelle et l'intérêt résultant.

J'insiste, il s'agit encore une fois de ma compréhension des choses, relatée avec mes mots.

Voici ma présentation pour la soutenance de ce module, je vous la partage avec plaisir.

The golden circle

Il s'agit, sur une idée de Simon Sinek, d'un outil permettant de répondre à trois questions :

Pourquoi ? Quelle est la vision ? Que voulons nous atteindre ? Nous partons (vivons) d'un monde actuel (la Terre), quel objectif (la Lune) souhaitons nous?

Comment ? 

La mission. Nous avons imagé la Lune pour la vision, cette étape sera la création de notre fusée pour atteindre celle-ci.

Comment ? Quel produit?

Intérêt : on a notre Lune, lointaine et visible par tous ? On sait où on va. On a notre fusée, notre mission comprise par tous (team et client) il ne nous reste plus qu'à réaliser le produit optimal concordant avec cette mission.

Les erreurs évitées : accorder trop d'importance aux produits, l'ordre est d'abord celui défini.

Si vous n'avez pas de vision, vous ne répondez pas à une problématique.

Avant de se lancer dans un projet ou d'écrire la moindre ligne de code, quelle est ma vision? Ma vision répond t-elle à un "pain" ?

Swot (mon outil préféré)

Il s'agit de faire une capture photo de votre outil sur un instant. Cette photo va prendre votre produit ainsi que son environnement.

Vous allez étudier quatre axes de votre projet : forces, faiblesses, (sous entendu interne ) opportunités et menaces (sous entendu externe)

On a donc une vision réelle de notre projet dans un environnement défini.

Intérêt : un diagnostic précis du projet. Quel axe devons nous améliorer ? Quelles sont nos forces ? Des parasites externes à prendre en considération etc....

Connaître par coeur son produit et son environnement.

List backlog - prendre du recul

Un grand nombre d'informations nous parvient, et cela de tout bord... Les CEO, les feedback clients, le marché, les collaborateurs... 

Intérêt : Une list backlog est là pour reprendre toutes ces données, les trier et prioriser.

Je vous invite à regarder ma list backlog (réalisée en 3 étapes) pour une meilleure compréhension.

L'impact mapping. Une réelle découverte

Cet outil est surprenant par sa simplicité mais terriblement intéressant par ses conclusions.

J'explique brièvement : cet outil se construit en 4 étapes:

• notre objectif

• les acteurs qui vont nous aider pour l'atteindre

• comment ces acteurs peuvent ils nous aider ? Par quel comportement ?

• et enfin quelles fonctionnalités allons nous mettre en en place.

Une suite logique qui permet de répondre donc à un objectif par des fonctionnalités.

Je mets cet excellent lien expliquant beaucoup mieux l'outil impact mapping :

https://hubvisory.com/blog/comment-organiser-des-ateliers-d-impact-mapping/

Voir les deux exemples que j'ai eu à réaliser pour cette formation.

L'intérêt de cet outil : les résultats sont totalement contre intuitifs, inattendus si nous n'avions pas pris la peine d'avancer étape par étape en faisant interagir les acteurs et leur comportement.

La roadmap

Excellent outil de présentation et synthétisant l'ensemble des données vues précédemment.

Elle va être notre feuille de route évolutive qui permet de planifier les différentes étapes de la création ou de l'amélioration d'un produit tout en intégrant une dimension flexible évidemment.

Voilà pourquoi on s'intéresse aux grandes lignes des projets et plus on avance dans le temps plus on ne note que des zones d'actions. L'objectif étant de rester plutôt agile et ainsi apporter des correctifs futurs.

Encore une fois n'hésitez pas à parcourir la présentation pour plus d'informations.

Merci de votre lecture. J'espère que ce deuxième volet vous aura donné l'envie d'en connaître davantage.  

Mohamed Amine Ouled-Alla