Personne ne comprend mon job de product owner

product owner job

Revers de la médaille d’être un métier nouveau, le job de product owner est souvent incomprise.

Combien d’entre nous exerçant ce métier formidable sommes confrontés au quotidien à l’incompréhension de certains collaborateurs qui ne savent pas vraiment comment nous situer sur l’échiquier des décideurs ?

Voici ci-dessous les 2 situations les plus courantes du quotidien d’un product owner, qui vous sont peut-être déjà arrivées dans votre job et pour lesquelles vous n’étiez pas préparé.

Dans cette article, je vous donne quelques clés pour changer la donne.

#1 Le grand classique, tout le monde vous prend pour un développeur web. 

Imaginez, vous êtes nouveau dans l’entreprise et prenez place à une réunion où sont présent des décideurs Marketing (au hasard).

Soudain vient la question du produit et l’un de vos collaborateurs s’adresse à vous et vous dit :

“Dites moi, avant que j’oublie, j’ai un souci avec l’affichage de la page d’accueil sur mon téléphone. On peut regarder ça ensemble rapidement et régler le problème avant de passer à un autre sujet ? “

Ca vous dit quelque chose ? 

Bien sur certains d’entres-vous êtes d’anciens développeurs .
Néanmoins ce n’est pas pour ça que vous allez changer du code à la volée et le déployer en production. 

Et puis ça veut dire quoi un problème ?  C’est quoi comme téléphone ? Quelle version d’OS ? Quel navigateur ?

Bref, malgré tout le respect à avoir pour la fonction de développeur, si vous êtes assis à la même table que ces décideurs, c’est pour parler planning, stratégie, vision.
Vous n’êtes pas la pour faire la maintenance du réseau intranet ou gérer un problème d’imprimante.

Seulement, même si vous le pensez très fort, votre rôle c’est de faire comprendre ce que vous faites. Évitez de vous faire remarquer dans le mauvais sens. 

Evangélisez le job de product owner

Au quotidien vous aurez besoin de collaborer avec ces personnes. Il se peut même que vous leur demandiez des choses toutes aussi absurdes qui n’ont rien à voir avec leur rôle. 

L’idée est de se mettre à leur place. Si certains de vos collaborateurs vous posent ce genre de questions, c’est qu’ils ne connaissent absolument rien à votre rôle. Ils n’ont aucune idée des contours de votre mission.

Cette situation se retrouve souvent dans des sociétés qui intègrent des équipes techniques dans leur effectif mais dont le service ou produit qu’ils vendent n’est pas numérique .
Par exemple: Développer une application mobile ou un site web pour faire la promotion d’un produit physique.

Si vous faites face à ce genre de situation, voici une réponse générique que je vous conseille de retenir et de personnaliser à votre sauce.

“En effet, vous venez d’identifier un problème qui semble important. Je suis ravi de voir votre implication dans la qualité du produit.
Je vous propose de planifier une réunion ensemble le plus rapidement possible afin de comprendre le problème en détail avec mon équipe. 

En général ce genre de problème est mineur à régler techniquement. En revanche j’aimerais comprendre si c’est un bug isolé ou si cela impacte une grande partie de nos utilisateurs afin de prioriser sa résolution”

Oui, vous vous dites: C’est très langue de bois comme réponse ! 

Si ca vous choque ou si vous êtes nouveau dans la profession, sachez que la politique ca fait partie du job de product owner au quotidien.
Quand vous êtes à la table de décideurs, il faut savoir jouer dans la même cours et surtout ne jamais dire oui à tout.

Analysons en détail chaque ligne de cette réponse pour que vous en compreniez l’essence.

1ere phrase:

“En effet, vous venez d’identifier un problème qui semble important. Je suis ravi de voir votre implication dans la qualité du produit. 

N’y allez pas trop fort, mais sachez flatter votre interlocuteur afin de le mettre dans votre poche. Après tout, c’est la réalité, la personne qui vous reporte un bug montre son intérêt pour la qualité du produit. Il cherche à vous aider indirectement.
Ce genre d’attitude doit forcément éveiller votre attention et être encouragé.

2eme phrase:

“Je vous propose de planifier une réunion ensemble le plus rapidement possible et de comprendre le problème en détail avec mon équipe. “

Avec cette phrase, vous affirmez votre position à la table. Vous montrez que vous connaissez les codes, et, en tant que décideur vous êtes également quelqu’un d’occupé. 

Replacez cette discussion dans un contexte formel qui doit faire appel au process de l’entreprise (ici une réunion).

Par ailleurs en soulignant mon équipe , vous indiquez que vous n’êtes pas l’informaticien de service. Vous rappelez que vous êtes aussi un manager et en l’occurrence que ce genre de tâche doit être délégué. Jouez d’égal à égal.

Dernière phrase:

En général ce genre de problème est mineur à régler techniquement mais j’aimerais comprendre si c’est un bug isolé ou si cela impacte une grande partie de nos utilisateurs afin de prioriser sa résolution”

Cette conclusion vous donne tous les ingrédients pour couper court à la discussion et encore une fois montrez votre valeur et votre professionnalisme.

La première partie  (En général ce genre de problème est mineur à régler) permet de rassurer votre interlocuteur qui n’a probablement aucun bagage technique et n’est pas en mesure d’estimer un problème technique. 

Ensuite, la dernière partie fait appel à sa logique. En soulignant que vous avez besoin d’estimer l’impact du problème sur la base client, vous vous exprimez dans son langage et vous lui donnez une bonne raison de ne pas se précipiter car avant de résoudre quelque chose, il faut identifier si c’est vraiment important par rapport à d’autre chose sur le feu.

#2 Product owner ? C’est comme un chef de projet non ?  

Le vieux poncif du Product owner Vs Product Manager ou Project Manager.

Qui ne vous a pas déjà confondu avec un chef de projet

Certainement même que votre boss vous prend encore pour un chef de projet ou que lors de votre entretien d’embauche le responsable RH vous a appelé “Chef de projet”.  

Oui, encore une conséquence de la nouveauté relative de notre profession dans les entreprises en France.

Il y a souvent que très peu de conséquence quand quelqu’un vous confond avec un chef de projet.

En revanche, si vous êtes amené à travailler avec une personne au dessus de vous hiérarchiquement qui vous prend pour un chef de projet, alors dans ce cas les conséquences peuvent avoir de grosses répercussions sur votre quotidien et celui de votre équipe.

Prenons l’exemple où vous êtes en charge d’améliorer l’expérience utilisateur du produit sur lequel vous travaillez.

Evidemment, vous avez certainement des objectifs à moyen – long terme du genre: 

  • Diminuer la vitesse de chargement des pages de 50% d’ici 6 mois
  • Diminuer les avis négatifs sur l’AppStore et le Google play store relatifs à la compréhension produit.
  • Augmenter l’engagement mensuel des utilisateurs de 15 % d’ici 12 mois.
  • etc…

Ces objectifs donnent un cadre à votre management et orientent forcément certains de vos choix. Pour le reste vous êtes assez libre sur le choix des tâches et des fonctionnalités à prioriser.

C’est vous qui décidez des objectifs de chaque sprint et c’est vous qui décidez du contenu des users stories. 

Vous avez un cap, une mission mais vous prenez le chemin qui vous semble le plus logique pour arriver à vos fins.

Dans le cas où votre boss ou l’un de vos supérieurs hiérarchiques vous prend pour un chef de projet, vous allez devoir gérer des deadlines et justifier à quelques dates telle ou telle fonctionnalité sortira en production.

C’est ici que le cauchemar commence !

Le problème est que quand une entreprise met en place un cadre agile et décide de recruter un job de product owner, seule l’équipe technique applique le mode agile.

Les autres départements eux n’ont rien signés et continuent d’agir comme à leurs habitudes, c’est à dire en mode projet.

Dans cet environnement, vous vous retrouvez à gérer des commandes clients:

“Il nous faut une nouvelle page de création de compte pour le 30 janvier.”

A quelle date on peut avoir cette fonctionnalité ? j’ai promis au client que l’on travaillé dessus pour ne pas le perdre

Ces objectifs et deadlines sont évidemment décorrélés de votre mission première.

En rentrant dans cette dynamique vous ne travaillez plus pour l’amélioration du produit. Vous travaillez désormais sur des objectifs courts-termes qui répondent à des besoins internes.

Le grand danger ici est que vous perdez la main et que vous risquez de créer un produit Frankenstein.
Ce que j’appelle un produit Frankenstein c’est un produit avec des fonctionnalités qui n’ont rien à voir les unes avec les autres car elles ont été implémentées en fonction des demandes de Pierre, Paul et Jacques. 

Il n’y a plus aucune logique et le produit perd sa cohésion.

Comme dans le premier exemple de cet article, si vous vivez une situation semblable ne perdez pas votre sang froid. Réagissez très vite avant qu’il ne soit trop tard.

Insistez sur la mission d’un product owner

Encore une fois, c’est à vous d’éduquer les stakeholders des autres départements de votre boîte.

Les gens ne vont pas changer du jour au lendemain. Expliquez-leur votre démarche et essayer de faire appel à leur bon sens.

Exemple de réponse à une requête interne:

“Si j’implémente une inscription client avec un login Gmail aujourd’hui comme vous me le demander, nous perdons tous le tracking des comptes sociétés. En effet, les comptes business doivent s’inscrire avec une adresse e-mail professionnelle. Cela permet à notre équipe commerciale de tracker les sociétés à recontacter pour leur proposer notre solution X, Y ou Z.  

Avec un login gmail, les gens vont s’inscrire avec une adresse email perso et notre fichier prospect perdra en qualité, ce qui risque de baisser nos revenus.”

Vous comprenez ce que je veux dire ?

Montrez que vous avez une vision claire et précise. Montrez que vous visez un objectif commun. Indiquez le risque de gérer des projets ad-hocs. Même ci ceux-ci peuvent permettre de résoudre un besoin urgent à court-terme, à long-terme, ils peuvent s’avérer dramatique pour la cohérence du business.

N’inondez pas vos collaborateurs avec un discours technique ou en employant du jargon agile. Faites appel à leur bon sens et parlez leur langage.

Avec le temps, les efforts vont payer et vous allez reprendre la main sur votre agenda. Ayez en tête qu’il va falloir vous répétez et vous justifiez tout le temps,

A retenir

En résumé, ne prenez pas mal si des collaborateurs vous demandent des choses absurdes. Il s’agit bien souvent de maladresses plutôt que de volonté de vous rabaisser.

On a tous plus ou moins des images clichés sur des métiers et quand on ne connaît pas quelque chose, on se rattache à la chose qui nous semble la plus proche.

En nous voyant collaborer au quotidien avec des développeurs, il est normal que certains nous voit comme des développeurs. 

En ne sachant pas ce que c’est un product owner réellement , il est normal que certains s’imaginent que c’est juste un “chef de projet” orienté technique.

Sachez réagir avec le sourire et pensez à éduquer sur votre profession en permanence.

N’oubliez pas, vous faites partie de la 1ere ou 2eme génération seulement de product owner dans votre entreprise.

C’est à vous que revient la tâche de faire comprendre votre métier.

Au début des années 2000, les métiers de développeur web ou de community manager ont connu eux-aussi les mêmes incompréhensions dans le monde de l’entreprise.

Aujourd’hui, tout le monde sait plus ou moins ce qu’ils font.

Avec le temps, le job de product owner deviendra aussi évidente pour tous. 

C’est à vous que revient le taf d’évangélisation.

Laisser un commentaire

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