fbpx

Toute personne ayant grandi dans les années 90 s’en souvient, selon Maître Miyagi “quand un homme a faim, mieux vaut lui apprendre à pêcher que de lui donner un poisson”. Soyons honnêtes, il ne s’agit pas ici de lancer un débat sur les Karaté Kids ni de reprendre la sagesse dispensée dans les Fortune cookies. Alors, comment faire le lien entre cette métaphore douteuse et le Product Management ? En parlant d’accompagnement, d’autonomie et de montée en puissance des Product Managers. 

On le sait, pour maîtriser ses dan (chez Thiga on parle d’un framework 😉), le Product Manager intervient à la confluence de nombreuses compétences. Son quotidien est souvent intense et malheureusement, parfois certaines tâches sont dépriorisées. Les enfants pauvres sont souvent la recherche utilisateur, l’analyse des données, le lancement d’expérimentations… Les raisons sont nombreuses : manque de temps ou de ressources, manque de de focus, caractère fastidieux de certaines tâches, outils manquants ou non adaptés. 

Pour répondre à cette douleur de l’organisation Produit, un rôle a récemment émergé. Il viserait à simplifier la vie des Product Managers (et des équipes Produit en général) : le rôle de Product Ops (ou ProductOps). 

Mais pourquoi le suffixe “Ops” ?  Pour faire le parallèle avec le rôle de DevOps, ces professionnels ont une double casquette. Ils “facilitent” la vie et les tâches des devs en :

  • #1 fournissant les moyens et processus de mise en production pour que les devs ne se soucient que de la qualité de leur code ;
  • #2 garantissant la robustesse du processus de mise en production par l’automatisation d’un maximum de tâches et de tests. 

Qu’en est-il pour le ProductOps ? Quels sont les rôles et prérogatives de ce nouveau poste ? Quand est-il pertinent de se poser la question de son activation dans son organisation Produit ? Qui sait, peut-être que cet article vous convaincra que ce rôle n’est finalement pas pertinent dans votre organisation. 

Hajime : un ProductOps, c’est quoi ?! 

Sur le sujet, il n’y a pas encore pléthore de littérature (hormis une récente étude de Pendo et Product Collective qui fait référence). Mais on peut résumer sa fiche de mission autour de 4 sensibilités : la relation client ; le produit ; la tech et la donnée. 

1# Créer un environnement favorable à la construction du bon Produit : 

  • Répandre la culture centrée sur l’utilisateur (“user centric”) dans l’organisation ;
  • Recueillir les besoins et définir les guidelines de recherche utilisateur ;
  • Rendre possible les expérimentations Produit et les lier à la stratégie de l’entreprise ;
  • Aider les équipes Produit à optimiser le processus de développement Produit et à gagner en cohérence. Notamment lorsque les équipes sont éclatées à l’international. 

2# Mettre en place un outillage adapté aux équipes Produit : 

  • Recommander les outils les plus pertinents pour les équipes Produit ;
  • Automatiser certains processus liés au Produit via ces outils ;
  • Coacher les équipes sur l’utilisation des outils et sur les bonnes pratiques.

3# Créer des relations entre les équipes et les utilisateurs : 

  • Garantir une communication des choix Produit et de la roadmap selon trois cercles. 
    • 1er cercle, l’équipe Produit : développeurs ; QA et DevOps ;
    • 2ème cercle, l’entreprise : alignement des parties prenantes et communication des décisions ;
    • 3ème cercle, le reste du monde : communication de la roadmap et de la vision produit aux utilisateurs / clients.

4# Alimenter les équipes Produit avec toutes les données utiles, en exploitant un maximum de sources : 

  • Données Produit : aider à l’analyse et à la prise de décision à partir de l’exploitation des dashboards de l’analytics ; des tendances observées en A/B tests ; des données d’acquisition (campagnes social media et de publicités) ; etc.  
  • Données Business : exploiter la connaissance marché : questionnaires et scores NPS ; service client ; analyse de la concurrence et benchmarks ; etc. 
  • Données techniques : veiller à également prendre en considération les données de la tech : sur la performance ; sur la dette fonctionnelle et technique par exemple. 

En synthèse, le ProductOps est un catalyseur. Il accélère la vélocité de l’ensemble de la chaîne de valeur du Produit. Il est aussi garant de la cohérence de la démarche Produit à l’échelle (automatisation et outillage), quel que soit l’éclatement géographique.

Lao-Tseu a dit “Il faut trouver la voie”… du ProductOps au sein des équipes

Contrairement au personnage de Tintin, je ne veux couper la tête de personne, bien au contraire. Le ProductOps ne vise pas à remplacer des rôles mais bien à agir en complémentarité. Cependant, il faut faire preuve de vigilance afin de ne pas cannibaliser des rôles existants.

ProductOps et Product Manager

Premier risque observé, celui de déposséder le Product Manager. Dans le modèle d‘UBER le ProductOps est en charge de délimiter le périmètre du Produit : concentrer les besoins et alimenter la roadmap. Ce positionnement, qui répond à un objectif d’optimisation du “time-to-market” des fonctionnalités, entre clairement en conflit avec une des tâches principales du Product Manager (cf. proposition de framework du PM que nous avons construit).

Second risque : que le ProductOps soit considéré, à l’inverse, comme un assistant des équipes Produit, pour réaliser des tâches rébarbatives et à faible valeur ajoutée : les reportings ou dashboard ad hoc par exemple (sic). C’est le principal piège dans lequel il faut éviter de tomber.

Or, si on reprend la comparaison avec un DevOps, celui-ci n’est pas responsable de la qualité du code mais de la simplicité et de la robustesse des mises en production. Le ProductOps ne sera donc pas responsable des choix de la roadmap ni de la priorisation. Il devra néanmoins fournir aux Product Managers tous les éléments pour prendre les bonnes décisions car justifiées par des données ou des feedbacks utilisateur. 

Combien de Product Managers m’ont déjà affirmé vouloir passer plus de temps à faire de la user discovery avec les UX, à observer des sessions grâce aux outils d’enregistrements, à analyser les commentaires sur les stores applicatifs, à exploiter l’analytics… Le ProductOps est un agrégateur des besoins. Il aidera, par exemple, le Product Manager dans la priorisation de sa roadmap, en proposant un score RICE détaillé à partir des nombreuses sources de données dont il dispose (pour insister sur Reach et Impact par exemple). 

En somme, le Product Ops doit livrer au Product Manager l’accès à la bonne information, celle utile à la prise de décision. Il doit rester un fournisseur de moyens (outcome) et non de données figées (outputs) sur le Produit. 

ProductOps et DevOps.

Certains articles expliquent que la coordination des développements et des déploiements, qui entre pourtant clairement dans le périmètre du DevOps, ferait partie des prérogatives du ProductOps. Parfois le ProductOps se voit même affecter la mise en place d’outils de suivi et d’automatisation des livraisons. Ces missions sont habituellement dévolues au Scrum Master, puis transférées généralement à l’équipe de développement devenue autonome. 

Le ProductOps doit choisir ses combats. Selon les entreprises où il intervient, il peut avoir différents barycentres : très orienté outillage, data, ou encore opérations produit.

Le sage cherchera le bon “équilibre” dans l’organisation 

Comme toutes les fonctionnalités organisationnelles, implémenter ce nouveau rôle est tentant. Mais avant de céder à cette tendance Produit, il faut se poser la question de la pertinence de sa mise en place dans votre organisation. Dans une organisation “as a product”, un choix doit répondre à un point de douleur, pour un bénéfice identifié. 

Trois facteurs peuvent justifier sa mise en place : 

  • Une croissance importante des équipes Produit qui entraîne la nécessité d’homogénéiser les pratiques et les outils. Le retour d’expérience de Sébastien Levaillant de Payfit lors d’un meetup LPCx Paris est, pour ce dernier élément, intéressant ; 
  • Une nécessité d’opérer des équipes éclatées géographiquement, avec un risque de non alignement des visions et de non cohérence des features ; 
  • Une organisation reposant sur des équipes non stables ou ayant des périmètres changeant rapidement. Par exemple dans les organisations en impact teams.

La question de la bonne organisation Produit est souvent complexe. Je ne veux pas tirer la métaphore en citant la notion d’équilibre chère au taoïsme (yin yang…), mais où placer ce rôle sans remettre en question l’organisation Produit ? 

Quelle que soit l’organisation cible, celle-ci devra respecter les lois qui définissent une organisation Produit (cf. article cité plus haut) : 

  1. La Loi du Client / Utilisateur : l’obsession de l’impact utilisateur est la raison d’être de l’organisation.
  2. Loi de la Petite équipe : on présume que le travail doit être porté par de petites équipes autonomes, travaillant en cycles courts et suivant la loi du Client (Time-to-Impact).
  3. Loi du Réseau : l’ensemble de l’organisation fait un effort continu pour faire disparaître la bureaucratie, la hiérarchie et les processus inutiles.

On l’a assez dit dans l’article : par définition le rôle de ProductOps répond à la loi #1. Mais qu’en est-il des lois #2 et #3 ? Ajouter un rôle de ProductOps à chaque team semble exagéré car cela élargirait le nombre de membres de chaque équipe. Cela ne permettrait pas non plus de garantir la cohérence (outils et workflows produit) dont est responsable le ProductOps. 

De même, considérer un unique ProductOps mutualisé nuirait à la loi 3#. Ce rôle deviendrait un goulet d’étranglement pour les équipes comme on peut l’observer dans certaines organisations autour des data analysts. Il est alors souvent nécessaire de mettre en place des processus complexes pour prioriser les travaux. 

S’il existait un mode optimal, ce pourrait être une équipe dédiée, une sorte de component team ”ProductOps”. Son objet serait de faciliter les modes de fonctionnement des autres équipes en autonomie : mise en place de plans de taggings généralisés, de Proofs of Concept sur des outils d’analyse Produit, d’automatisation des pratiques, de visualisation des retours utilisateurs, de partage des roadmaps, etc. Tous ces chantiers seraient bien sûr à prioriser dans le backlog du ProductOps. Les Product Managers en seraient ainsi des parties prenantes / consommateurs.

Rappelez-vous : l’organisation est un Produit, qui consiste à répondre à des points de douleur. La mise en place du ProductOps peut être une réponse pour simplifier la vie des Product Managers dans des cas de croissance forte, d’éparpillement géographique et / ou d’instabilité des équipes. Ce n’est pas la réponse à tous vos maux. 

Selon les douleurs de l’organisation, beaucoup d’autres réponses sont possibles : externaliser la user research, uniformiser les expérimentations ou les indicateurs-clés à suivre au sein de chaque équipe, etc. Pour creuser ces éléments avec nous, n’hésitez pas à commenter cet article. Par ailleurs, les défis de la mise en place et de l’évolution des organisations produit sont traités dans la formation Thiga Academy dédiée aux managers des organisations produit : les VP Product et CPOs.

Ces articles pourraient vous intéresser

Laisser un commentaire

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

La Newsletter des Product Managers

Recevez nos articles 2 fois par mois et devenez un top gun du Product Management!