Site Overlay

Product Owner débutant… Really ?

Comme le remarquait Julien sur son blog LeProductOwner, il semble y avoir sur le marché un problème d’offre et de demande avec d’un côté un nombre impressionnant d’offres d’emploi ou de mission de PO et de l’autre des « anciens » (Product Manager, chef de projet, etc.) qui se sont formés le plus souvent et ont du mal a trouver leur premier poste en tant que Product Owner.

Bien souvent, il s’agit de réussir a obtenir le premier entretien durant lequel non seulement les motivations mais aussi les expériences passées deviennent tout de suite claires pour les recruteurs et ouvrent, la plupart du temps, la voie pour continuer le processus de recrutement. Lors de mes divers échanges, on m’a souvent conseillé d’intégrer dans mon CV les parties de missions du PO que je maîtrisais pour les avoir déjà pratiquées : « En fait tu as tout fait mais par épisodes… ».

Mettre tout cela dans un CV me semble assez dur aussi je me prête à l’exercice sur ce post. Pour rassembler les missions principales du Product owner, j’ai essayé de synthétiser des éléments du Scrum Guide, du livre The professional Product Owner, d’annonces vues ci et là et des posts de JP lambert et vidéos de Scrum Life… Cette liste n’est peut être pas complète, n’hésitez pas à commenter et proposer des missions du Product Owner que j’aurais pu oublier.

Pour chaque « mission » j’ai donc recherché des exemples de réalisation. Cet exercice m’a beaucoup apporté me confortant dans mes choix, et permettant a minima de mettre les choses à plat pour mieux les réutiliser en entretien.

Ce qui suit ne concerne que mon cas mais n’hésitez pas à l’utiliser comme framework pour vos propres expériences.

En préambule et pour aider à la compréhension, quelques mots sur mon parcours : j’ai commencé en tant que product manager dans une grande entreprise Telecom puis directeur de clientèle/conseil en agence digitale, sur des gros projets de refontes web et outils digitaux. J’ai ensuite créé et animé une business unit en cabinet conseil tout en développant les produits SAAS du cabinet. Je suis indépendant depuis un peu plus d’un an et en recherche de mission ou emploi.

Comprendre le « métier »

C’est la base ! On ne peut pas conseiller ou répondre à un appel d’offre qu’il s’agisse de site ou d’outils internes sans comprendre les métiers, les business model et les organisations. Sur ce point précis, je pense au contraire que mon expérience de plusieurs secteurs et types d’entreprise me permet d’apporter de nouvelles solutions, cross fertilisation, points de vue…

Collecter les besoins

J’ai eu l’occasion de mener de nombreux interviews, de les synthétiser et de les exposer lors d’études de marché, d’opportunités le tout dans une démarche user centric. C’est ce que j’ai notamment fait lors du cadrage en vue de créer un portail de distribution d’extraits vidéo BtoB. La démarche s’est articulée autour de 3 axes : interviews internes et ateliers d’expression des besoin / benchmark intra et extra secteur / interviews de clients potentiels.

Définir les personas

Ma dernière mission, pour ne citer que celle-ci, consistait en la définition de personas pour une entreprise de travaux de rénovation qui entreprenait sa transformation digitale (refonte web, automatisation des process de recrutement et de réalisation des chantiers).

Définir et porter la vision

Un de mes rôles dans les grosses refontes de sites ou la création de nouveaux parcours pour des distributeurs de billets par exemple étaient clairement d’aligner en permanence les travaux avec la vision initiale et les objectifs.

Créer et piloter la roadmap

Pour gérer les grosses refontes de sites, e-commerce hôteliers ou bancaire, il a fallu mettre en place des roadmap plutôt précises et les tenir, à cause des enjeux business derrière les mises en ligne. De même, durant mes 8 années de product management j’ai developpé des plans produits et des plans marketing avec des vision à 1, 3 et 5 ans sur des sujets comme la géolocalisation par exemple.

Définir les release, les mvp

Nous avons créé from scratch un outil d’aide à la vente des commerciaux grands comptes dans l’hôtellerie. Pour créer ce produit, ou plutôt le co-créer avec les utilisateurs, nous avons définit une vision, mais aussi un plan de releases en commençant par un MVP.

Exprimer et gérer le product backlog / prioriser par la valeur

Sur les projet de longue haleine, comme les projet de refonte de site profonds, on ne peut pas appliquer stricto sensu du waterfall, il est nécessaire de diviser le travail en plus petits morceaux / livrables et de les prioriser par rapport à leur valeur dans le projet (client ou utilisateur)… ça ressemble à s’y méprendre à un backlog non ?

De plus les systèmes d’estimation projet en avant-vente d’agence digitale notamment sur le développement se basent tous sur la découpe en fonctionnalités et leur estimation. Voire même sur leur classement et priorisation par rapport a la valeur délivrée pour permettre des propositions « à tiroir ».

Spécifier le produit / rédiger les user stories

J’ai eu l’occasion de travailler dans de multiples environnements de la très grande entreprise à la PME, toutes dans la tech… je suis donc passé par des process très contraints (5 niveaux de spec pour un produit et 6 mois minimum) à des methodes beaucoup plus libres.

Dans tous les cas j’ai rédigé de specifications, des stroy boards / wireframes, (commentés ou pas), animé des ateliers de conception, de priorisation etc. J’ai de plus expliqué, échangé et commenté ces documents tant avec les clients qu’avec les équipes, notamment techniques (voir plus bas).

Estimer

Répondre à un appel d’offre ou gérer un produit chez l’annonceur, c’est aussi l’estimer. Cette estimation se fait en négociation permanente avec les différentes équipes (tech, créa…) et services (promo, marketing, commercial…). Sans forcément faire de planning poker ou autres techniques d’évaluation, j’ai géré ces phases d’estimation et ré-estimation sur tous les produits dont j’ai eu la charge.

« Manager » une équipe pluridisciplinaire sans liens hiérarchique

C’est exactement la situation dans laquelle on se retrouve en agence ou chaque intervenant ne dépend pas forcément hiérarchiquement du lead produit / projet. Il convient, comme dans Scrum, de trouver la position de leader qui va embarquer les autres.

J’ai beaucoup travaillé sur des clients « récurrents » avec des équipes pratiquement à temps plein sur ces clients, gérant à la fois le ongoing et les évolutions de plus long terme. Ces organisations entraînent un fonctionnement très proche de l’équipe auto-gérée.

Savoir communiquer avec l’équipe de développement

Les « négociations » avec les autres intervenants, notamment techniques, ne peuvent avoir lieu que si l’on comprend et connait un minimum le métier de l’autre, ce qui permet de trouver un langage commun et de pouvoir travailler ensemble.

Comprendre les problématiques techniques et la dette technique

Mon côté un peu geek fait que je m’intéresse au dev depuis toujours et que j’ai développé ces connaissances au contact de mes interlocuteurs. Je suis donc sensibilisé aux problématiques de dette, d’infra et d’archi par exemple. J’ai de plus géré des dossiers de TMA avec les outils de ticketing et les process associés. Ça m’a permis de voir des couches plus basse sur les systèmes.

Rédiger les tests / tester

J’ai organisé et participé à de nombreuses recettes fonctionnelles, qui se basaient sur des attendus que j’avais participé à spécifier, voire que j’avais spécifié.

Se mettre en condition de livrer fréquemment (avec l’équipe)

Les gros projets de refonte avec les enjeux économiques qu’ils contiennent m’ont à plusieurs reprises amené à mettre en place des process de livraison continue.

Mettre en place et suivre les indicateurs (Burn down, KPI’s…)

Vente, visite, clics, étude des parcours, études de marché… Le suivi d’indicateur, mais aussi les sondages et interviews, sont au centre de tout. Tous les projets mis en œuvre ont été accompagné d’indicateurs de succès définis en amont de manière à suivre et comprendre les performances mais surtout à modifier et évoluer.

Proposer les évolutions

J’ai beaucoup travaillé sur les parties amont et le conseil… autant de secteurs ou il est nécessaire de développer des propositions d’évolutions ou des nouveaux produits.

Concernant le savoir être…

Je pense, ou du moins j’espère, que côté savoir-être il n’y a pas vraiment de questions à se poser sur les candidats qui proviennent d’autres fonctions. En effet, ils adhèrent aux valeurs de l’agilité et sont dans une démarche de pivot, plus que de changement radical, ce qui prouve une certaine ouverture à la nouveauté, une envie réelle d’intégrer les équipes et de s’y épanouir.

J’espère que ce petit exercice vous aura plu. N’hésitez pas à me faire vos remarques en commentaires.

Note : On aurait aussi pu faire l’exercice dans l’autre sens, en prenant les projets ou les typologies de projets et en y intégrant des missions du Product Owner… Il n’est pas dit que je ne le ferai pas 😉 

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *