Comment garantir une approche produit avec un service interne à l’entreprise

1_Vignette_HD
Complément aux vidéos / La gestion de produit en pratique

Comment garantir une approche produit avec un service interne à l’entreprise

Note de l'auteur

Dans ce cinquième épisode de la série la gestion de produit en pratique, Jean-Pierre Lambert et Constantin Guay font équipe pour aborder un sujet qui, derrière ses apparences anodines, soulève une multitude de questions. Et il est vrai que nous pouvons tous avoir tendance à adapter notre manière de travailler lorsque notre produit est destiné à un service interne à l’entreprise. Jean-Pierre Lambert et Constantin Guay mettent les points sur les i. Ils exposent les bonnes pratiques, dénoncent les dérives et nous abondent de conseils pour vous permettre de garder une approche produit en toute circonstance.

Table des matières

Introduction

L’équipe Panda 🐼 est bien embêtée. Elle a compris l’importance de se positionner comme la force vive de la construction d’un produit. Son Product Owner vient tout juste de comprendre l’importance cruciale de son rôle et pourtant, en l’espace d’une décision, ils viennent tous d’être catapultés exécutants d’une autre équipe. Cette situation pose la question : pouvons-nous suivre une approche produit dans le cadre d’une relation interne à l’entreprise ?

Je suis Jean-Pierre Lambert, le créateur de Scrum Life, la première chaine YouTube francophone qui parle de l’esprit agile. Je coanime Scrum Life avec Constantin Guay et nous accompagnons, tous deux au quotidien, des équipes agiles. Dans les grands groupes, il n’est pas rare que ces équipes créent des produits à destination de services internes. J’ai par exemple été Scrum Master durant deux ans de l’équipe Player de la direction du numérique de France Télévision. Elle était justement dans cette situation : construire des produits à destination des différents sites internes de la marque. J’ai eu l’honneur de détailler cette expérience lors de conférences. Rejoignez notre communauté pour échanger sur votre quotidien !

Photo Jean-Pierre Lambert

Dans ce nouvel épisode de la série la gestion de produit en pratique, nous allons préciser ce qu’est l’approche produit pour ensuite voir ce que cela change d’être face à des clients internes. Nous vous apporterons des conseils pratiques pour vous permettre d’appliquer une approche produit dans ce contexte.

Qu’est-ce qu’une approche produit ?

Nous rencontrons souvent des équipes qui ne sont pas vraiment posées la question. Alors voilà la définition que nous vous proposons : l’approche produit est un mode de fonctionnement où l’équipe en charge de la construction d’un produit prend également les décisions stratégiques sur ce produit. Vos décisions ne seront pas dénuées de fondement, vous vous entourerez des parties prenantes. Il s’agit des personnes qui ont un véritable intérêt dans le produit et donc dans votre réussite. Elles peuvent être un sponsor, un utilisateur ou un client.

  • Le sponsor: personne ou entité dont le rôle est le financement d’un produit ou projet. Il vous partage des éléments de contexte, du marché, des enjeux et des ajustements des objectifs. Tout cela reste informatif et non pas directif.
  • Les utilisateurs ou clients : leurs retours devront être filtrés, contextualisés et analysés car chaque type d’utilisateur peut avoir des problématiques très concrètes et très importantes pour lui seul. Ici encore, il s’agit d’informations et non pas d’éléments ayant force de consignes.
  • Sponsor + utilisateur ⚠️ : il est important de préciser qu’il est interdit d’être les deux à la fois. Nous ne sommes jamais sponsor et utilisateur. Nous reviendrons sur ce point plus loin.
  • Gouvernance et utilisation : vous voyez que dans les deux cas les éléments rapportés ne doivent pas être traités de manière brute sans analyser leur pertinence. Une bonne manière de gérer cette approche est de concevoir une séparation claire entre la gouvernance et l’utilisation. Le lien entre les deux est géré par l’équipe et facilité par le Product Owner.

Maintenant que le contexte a été précisé, comment collecter des retours utilisateurs en pratique ? Par exemple en procédant à des tests utilisateurs.

  • La notion de test : il s’agit bien ici de valider ou d’invalider un comportement ou une hypothèse et non pas d’obtenir une suggestion pour le devenir de votre produit.
  • Les données d’utilisations : nous pouvons également collecter les données auprès des utilisateurs lorsqu’ils utilisent le produit.

Les tests utilisateurs comme la collecte des données d’utilisation nous amènent naturellement, en termes de démarche intellectuelle, vers ce que nous appelons les test A/B.

  • Les test A/B : consiste à mettre en concurrence deux versions du produit pour découvrir objectivement quelle est la meilleure. Ce processus nous permet de prendre de la distance par rapport à l’utilisateur.

Nous parlons bien d’utilisation et les grosses difficultés arrivent lorsque la partie prenante est à la fois sponsor et utilisateur. Cette posture crée inévitablement des conflits d’intérêts pour la construction d’un bon produit. Comme le dit très justement Jason Fried, PDG de Basecamp : « dès lors qu’un client vous paie beaucoup plus que n’importe quel autre client, vous n’êtes plus une entreprise qui construit un produit, vous êtes à nouveau une entreprise de services ou de conseils. »

«The moment one customer pays you a lot more than any other customer, you’re no longer a product company, you’re a services/consulting company again. »

Effectivement à partir du moment où vous faites affaire avec un client qui pèse financièrement sur votre entreprise, vous risquez d’exécuter ses demandes sans prendre le recul nécessaire pour construire un bon produit. Ce conditionnement fera la différence entre une approche produit et la construction d’une solution à la demande.

Pour résumer, OUI ! Nous pouvons suivre une approche produit dans le cadre d’une relation interne à l’entreprise. Je dirais même que nous devrions, quelque soit le contexte, réaliser des tests utilisateurs, prendre du recul sur les retours utilisateurs, collecter les données d’usages et les analyser…

Quel est l’impact d’une relation interne sur l’approche produit

Nous venons d’expliquer ce qu’est une approche produit et nous avons confirmé qu’elle était applicable dans le cadre d’une relation interne à l’entreprise. Mais comme le dit la formule, c’est plus facile à dire qu’à faire. Nous vous donnerons les clefs de la mise en place d’une approche produit en interne. Nous verrons également le cas particulier d’un produit qu’un utilisateur n’a pas le choix d’utiliser. Mais pour commencer je vous propose d’aborder une autre situation que vous pouvez rencontrer : quand le patron se prend pour un utilisateur.

Le patron endosse injustement le rôle d’utilisateur : comment gérer la situation ?

Parfois, la limite de chaque rôle n’est pas clairement établie et il peut arriver qu’une partie prenante soit à la fois sponsor et utilisateur. Dans ce cas la notion d’utilisateur reste déjà à confirmer. Souvent ils ne sont pas réellement utilisateurs et se proclament représentant de ces derniers. Ils ne font que fantasmer sur l’utilisation du produit en considérant uniquement leur propre vision et leurs propres besoins. Dans le meilleur des cas ils seront réellement utilisateurs et il faudra les mettre sur le même plan que les autres utilisateurs. Le risque de cette situation est de réaliser le produit que le patron souhaite au lieu de celui qu’il faut construire. C’est d’ailleurs un point qui sera détaillé dans le prochain épisode de notre chaine : comment rationnaliser les décisions sur le produit à partir des données ? Pour être certain de ne rien rater, abonnez-vous à Scrum Life et activez les notifications !

C’est clair : le sponsor utilisateur ne devrait pas exister car c’est le meilleur moyen d’évincer les vrais utilisateurs, de rater la cible et de ne pas construire le bon produit. Citons une nouvelle fois notre cher Peter Drucker :

« Il n’y a rien de plus inutile que de faire avec efficacité quelque chose qui ne devrait pas du tout être fait. »

Nous ne le dirons jamais assez : allez à la rencontre des vrais utilisateurs ! Dans une telle situation il peut être utile de redéfinir les rôles de chacun par exemple avec l’atelier rôles et responsabilités que nous avions présentée sur Scrum Life :

Le produit imposé à l’utilisateur : quelle est l’approche appropriée ?

Voyons maintenant le cas particulier dans lequel le produit est imposé en interne. Nous sommes donc face à des utilisateurs qui sont dans l’obligation de l’utiliser. Pouvons-nous pour autant négliger la qualité du produit sous prétexte de maitriser les résultats en terme de volume d’utilisation ? Évidemment non. Un produit qui ne répond pas complètement aux besoins ajoutera une frustration supplémentaire à celle de ne pas avoir le choix. Cela conduira très souvent l’utilisateur à trouver des moyens détournés pour écarter le produit imposé au profit d’un autre qui lui conviendra mieux… Alors il faut vous demander ce qui poussera l’utilisateur à rester sur votre produit. Et au-delà des besoins de l’utilisateur, en quoi le produit est-il important pour l’entreprise ? Quelle est sa raison d’être ? Certainement pas uniquement de consommer le budget !

Une approche impliquant l’analyse d’indicateurs peut vous permettre d’aborder la question avec sérénité. Nous parlons souvent des KPI (Key Performance Indicator) : des indicateurs à suivre pour juger de la performance. Dans notre cas un indicateur qui prend en compte l’achat ou l’utilisation du produit ne sera pas pertinent puisque nous sommes dans l’obligation de l’utiliser. Voici quelques exemples d’indicateurs qui nous ramènent à la raison d’être du produit, qui sont évidemment chacun lié à un contexte qui leur est propre :

  • Les fournitures de bureaux sont livrées plus vites.
  • La lourdeur administrative liée à certaines procédures est réduite.
  • Les notes de frais sont payées plus vites.
  • Les départements ou équipes qui dépendent de notre service livrent plus vite à leurs clients.

Globalement, dans tous les cas, nous cherchons à gagner en efficacité et en qualité. Il s’agit de réduire le gâchis : nous perdons moins de temps à réaliser des taches inutiles.

Le B2B interne : comment suivre une approche produit lorsqu’il est dédié à un utilisateur intermédiaire ?

Voici une autre difficulté qui complique la mise en place d’une approche produit dans le cadre d’une relation interne à l’entreprise : lorsque les utilisateurs du produit développent eux-mêmes un autre produit qui aura ses propres utilisateurs. Création et utilisation en cascade. Bon attendez ! Reprenons le diagramme introduit plus haut :

  • En interne : visez la notion de cascade : C’est vrai que nous avons du mal à concevoir cette vision de création et d’utilisation en cascade et pourtant nous rencontrons des exemples tous les jours. D’innombrable produits sont conçus non pas pour l’utilisateur final mais pour servir de support ou de service pour la construction d’un autre produit. Vous ne voyez toujours pas ? Prenons quelques exemples pour l’illustrer :
    • AWS : ce service de cloud d’Amazon fournit une infrastructure serveur. Les professionnels achètent un droit d’utiliser ce produit pour ensuite créer et revendre leur propre service sur ce support.
    • Les voitures : elles sont constituées d’un ensemble de sous-système comme la climatisation par exemple. Ces sous-systèmes sont des produits à part entière, vendues par d’autres entreprises.
    • Les colis prépayés : utilisés par un grand nombre d’entreprises pour leurs clients. Bien que ces derniers ne soient pas en relation directe avec l’entreprise postale, ils utilisent ses services par l’intermédiaire d’un autre professionnel.
    • Les composants informatiques : un ordinateur est constitué d’une multitude de composants qui sont eux-mêmes conçus, fabriqués et vendus comme des produits à part entière par d’autres société. Plus généralement, on peut en dire autant de tous les composants électroniques.

Bref il est fréquent qu’un produit soit construit pour finalement participer à la construction d’un autre produit. Pour garder une approche produit dans le cadre d’une relation interne à l’entreprise, c’est exactement cette notion de cascade que vous devez viser ! De fait il est possible que les feedbacks émanent de l’utilisateur du produit final et non pas de l’utilisateur de votre produit. Et oui cette situation pose des questions sur la responsabilité mais pour autant, toute l’industrie arrive à fonctionner avec cette organisation. Alors pourquoi nous n’arriverions pas à la mettre en place dans le cadre d’une relation interne ?

  • Les dérives ou les atouts : vous avez le choix ! Evidement le fait que les clients soient au sein même de l’entreprise peut amener des dérives de jeux politiques et des pressions de la hiérarchie mais nous avons des outils pour gérer ces situations. Regardez par exemple notre vidéo sur les relations client-fournisseur : ne vous faites pas BOUFFER et construisez une relation AGILE

Tout l’enjeu consiste à réussir à transformer cette difficulté en atout. Vous interagissez avec des personnes internes à l’entreprise ! La clé est de s’assurer que vous servez un objectif commun, qui répond à une même vision. Les utilisateurs directs utilisent votre produit pour apporter de la valeur à l’utilisateur final. C’est ce dernier qui devrait être le point de rassemblement de votre collaboration : un focus commun sur l’utilisateur final.

Conseils pratiques à l’équipe pour garder une approche produit avec un service interne

Quels conseils pratiques pouvons-nous donner à l’équipe ? Il faut traiter le client en interne comme n’importe quel client ! Il faut donc gérer tout le cycle de développement complet du produit. C’est-à-dire :

  • Livrer souvent sans rogner sur la qualité
  • Fournir une documentation
  • Assurer le support du produit livré
  • Communiquer les changements et les évolutions du produit
  • Collecter les retours utilisateurs

Ne tombez pas dans le piège de la simplification des process sous couvert de la proximité des services. Vous devez, à votre client interne, le même niveau d’exigence et de service que celui accordé à n’importe lequel des clients externes.

Il reste un sujet qui n’a pas été fouillé dans cet épisode : l’importance de bien définir les interfaces entre les équipes. Pas de panique, nous l’avons traité en profondeur dans notre vidéo : comment bien démarrer Scrum alors qu’on dépend d’autres équipes ?

Glossaire

Product Owner

Apporte la vision produit, la vision marché et l’alignement avec les objectifs d’entreprise (rentabilité par exemple)

Approche produit

mode de fonctionnement ou l’équipe en charge de la construction d’un produit prend également les décisions stratégiques sur ce produit

Sponsor

personne ou entité dont le rôle est le financement d’un produit ou projet

Test A/B

mise en concurrence de deux versions du produit pour découvrir objectivement quelle option est la meilleure

KPI (Key Performance Indicator)

indicateur à suivre pour juger de la performance

Faites votre veille : Sources et liens complémentaires

Vous avez aimé cet article ?

Alors vous allez adorer

Le guide du Scrum Master compétent