Quoi ? Un PO faire du support ? Mais un PO, ça vaut mieux que ça ! Le support, c’est sale. Et en plus, un PO est bien trop payé pour faire ça. Déjà qu’on a du mal à les attirer, alors autant ne pas les faire fuir tout de suite ! Un PO, ça doit allouer son temps sur d’autres activités qui sont plus difficiles à déléguer et sur lesquelles sa valeur ajoutée est bien plus forte, non ?
C’est malheureusement le type de réflexion qui caractérise, encore trop souvent, l’attitude de certaines organisations par rapport au support. Certes, on parle d’expérience centrée sur l’utilisateur, mais on a encore du mal à se dire qu’il y a un intérêt à investir sur la fonction support. Paradoxal à l’heure où même les C-levels ont au moins une fois dans leur vie entendu parlé d’UX…
Le support reste encore trop souvent piloté par une vision partielle des coûts : on ne cherche pas à réduire globalement du support pour l’entreprise, mais celui de la main d’oeuvre qui compose la fonction support sur des tâches estimées à faible valeur ajoutée. On relègue donc encore le support au rang de simple centre de coût, sans se donner la peine de recruter des profils qualifiés pour assurer ces fonctions.
Que met-on derrière le coût du support ?
Voilà une question qui devrait intéresser tous les POs en leur qualité de maximisateurs de valeur.
Le coût du support ne se résume au simple coût de sa mise en oeuvre (salaire, matériel) :
- si l’on prend le cas d’un outil utilisé en interne, on pourrait citer le temps de blocage des utilisateurs, et donc la perte de productivité ;
- et pour un produit exposé au public, c’est le coût de la chute de réputation. Les exemples sont nombreux, par exemple chez nos amies les compagnies aériennes comme British Airlines qui en a pâti en 2013 lors d’une campagne Twitter initiée par un client prêt à payer des tweets sponsorisés pour faire connaître son mécontentement.
Bref, derrière le support, il y a des enjeux sérieux, qui méritent qu’on s’y intéresse sérieusement.
Pour ma part, je suis PO. Je fais du support sur un produit interne, essentiel au bon fonctionnement de l’entreprise. Et aider les utilisateurs m’aide aussi beaucoup dans mon quotidien !
Voici pourquoi :
#1 Ca me permet de construire une relation de confiance avec mes utilisateurs
Certes, il faut se garder de faire des généralités, mais la norme dans la plupart des organisations reste que la tech est un environnement mal compris du métier. C’est d’ailleurs une des raisons pour lesquelles on a besoin de cette interface entre parties prenantes et équipe produit qu’est le PO.
Résumons le cliché de la transformation digitale. Le département IT passe en organisation produit. Un nouveau PO arrive. Il prête un oreille attentive aux demandes des utilisateurs. Qui commencent à tirer des plans sur la comète. « Enfin, se disent-ils, quelqu’un qui parle plus ou moins notre langue ». C’est la naissance d’une histoire d’amour qui sera vite rattrapée par la réalité, à mesure que la roadmap se met à glisser, que les imprévus arrivent, etc.
« Quel beau parleur ce PO », constate amèrement un métier déçu, résigné même, qui se dit qu’avec la tech, ça ne changera décidément jamais, sans pour autant comprendre véritablement pourquoi. Et oui, car ça avait l’air pourtant simple sur le papier…
Et bien, si le produit s’y prête, être en première ligne, c’est une manière efficace de montrer que vous êtes plus qu’un Alain Delon qui promettrait Caramel, bonbons et chocolat. Vos utilisateurs rencontrent des difficultés ? Vous ne vous dérobez pas : vous êtes avec eux, à vous retrousser les manches, pour les aider à le résoudre.
Certes, ce n’est pas très scalable comme logique, surtout si vous avez beaucoup d’utilisateurs. Mais c’est généralement une bonne tactique de commencer par faire des choses qui ne semblent pas scalables. Et puis :
- en tant que PO vous vous devez d’être le garant d’une expérience utilisateur la plus optimale possible sur votre produit. Si les utilisateurs ont un problème, c’est votre problème. Si le problème est trop récurrent, vous trouverez sûrement des manières de faire en sorte d’accélérer sa résolution, voire de l’empêcher de se produire
- en interne le mot circulera. Le métier saura que vous prenez ses problèmes au sérieux, et la prochaine fois que vous lui direz non ou que vous aurez un mauvaise nouvelle à lui annoncer, il sera plus avec vous, même s’il ne comprendra peut-être toujours pas la raison.
#2 Ca me permet de développer l’équipe support
Les utilisateurs sont rarement précis quand ils évoquent un problème. Les équipes de support non plus. In fine, chacun a ses modèles mentaux et conjugue la vie selon sa propre syntaxe. Pourtant, quand un problème survient, la bonne compréhension de cette dernière compte de manière significative dans son traitement plus ou moins efficace ; difficile en effet de traiter efficacement une demande si on ne la comprend pas.
Le premier enjeu du support, c’est donc de comprendre et trier la demande pour l’aiguiller vers le bon canal et augmenter les chances de lui apporter une réponse adéquate rapidement :
- Est-ce vraiment un bug, et auquel cas, quelle est sa criticité et comment on le réplique ?
- Est-ce une demande d’évolution, et dès lors comment comprendre le besoin qui se cache derrière ce que l’utilisateur essaie de faire ?
- Est-ce un besoin de formation – l’utilisateur ne sait pas faire quelque chose qui est possible mais ne l’exprime pas comme cela, et dès lors pourquoi n’a-t-il pas vu cette possibilité ?
Ces questions ne sont pas triviales à adresser : elles requièrent à la fois une connaissance du produit, des workflows des utilisateurs, et également des notions d’expérience utilisateur, du moins une forme d’empathie pour révéler ce qui bloque l’utilisateur et à quel point ce blocage est coûteux… On s’aperçoit dès lors que trier des demandes nécessite une expertise : c’est un véritable diagnostic, et le terme devrait nous faire réfléchir quant au niveau d’expertise qui est requis pour le réaliser.
Pourtant, les équipes support ne sont pas systématiquement (euphémisme ?) composées en intégrant ces différentes compétences : c’est ce qu’on disait plus haut : on voit le support comme un automate humain, plutôt technicien, et d’ailleurs on ne sait pas trop où le rattacher dans l’organisation…
Dès lors, avoir un PO qui participe à l’effort de support, c’est se donner l’opportunité de faire monter en compétence l’équipe support pour qu’elle sache mieux trier les demandes, ce qui permettra notamment :
- d’améliorer la qualité de la prise en charge des demandes de support (et donc d’améliorer la satisfaction des demandeurs)
- d’alimenter le backlog (et donc de réduire de manière plus scalable le nombre des demandes)
- de protéger l’équipe de développeurs (dont le temps et la motivation coûtent cher à l’organisation)
C’est aussi se donner l’opportunité de construire des transmettre de la connaissance aux membres de l’équipe support pour les développer sur d’autres aspects, et de construire avec eux des chemins de carrières les orientant pourquoi pas vers des rôles de Proxy PO, de QA ou de développeurs.
#3 Ca me permet d’alimenter mon backlog
Les utilisateurs ne vous contactent pas uniquement quand il y a un bug, mais d’une manière plus large quand ils ont un problème. Ce problème, ça peut aussi être quelque chose qu’ils n’ont pas bien compris. Ou bien un besoin qu’ils ont et que vous ne couvrez pas encore.
1. le bug
La fonctionnalité est présente mais ne produit pas l’effet attendu dans certains contextes.
Précisions tout de suite que tous les bugs ne sont pas à traiter, encore une fois cela dépend du contexte : combien de gens sont concernés, à quelle fréquence se produit ce bug, etc. Mais si le jeu en vaut la chandelle, il est dès lors important de ne pas se contenter simplement de résoudre le bug, ce qui est pourtant souvent la mission que se donnent les équipes supports : il faut l’empêcher de se reproduire.
Et pour faire ça, il faut être capable de le répliquer. Le problème ici, c’est que parfois, la langue de l’utilisateur ou celle de l’équipe support ne permet par de retracer la séquence d’actions ayant mené à ce bug. Avoir un PO qui sache engager la discussion avec l’utilisateur et poser les bonnes questions est un moyen de mieux expliciter les conditions d’occurence du bug, et de les traduire en spécifications pour que l’équipe les traite définitivement.
2. le besoin de formation
La fonctionnalité est présente, mais l’utilisateur ne la comprend pas/ne sait pas l’utiliser/ne la voit pas.
C’est clairement un dysfonctionnement du système, et faire du support le rend visible. Le problème ici, c’est que la fonction de formation est peut-être séparée de la fonction support, et que les deux sont peut-être séparées du produit…. L’information est là, mais difficile d’y accéder et donc de l’exploiter.
Avoir un PO au support donne ici l’opportunités de sortir des logiques de silos : avant d’être face à un problème technique ou de formation, on est face à un problème utilisateur, et même un problème du produit. Et c’est au produit d’y répondre. Là où la solution du formateur sera très probablement de faire une nouvelle communication ou formation, la solution du PO pourra être de travailler les feedbacks, les libellés des boutons, etc, bref de simplifier, clarifier et documenter les règles directement dans le produit pour adresser le besoin de manière plus scalable.
3. L’évolution
La fonctionnalité n’est pas présente dans le système, ou gagnerait à être rendue plus accessible pour garantir plus de valeur.
Ce qui est bien quand on fait du support, c’est qu’on découvre des manières souvent inattendues d’utiliser son produit. Or, une personne qui pense « support » considère qu’il y a une manière de faire les choses avec son outil. Elle verra un détournement, et ne cherchera pas nécessairement à comprendre ce qui se trame derrière.
Un PO, lui, ne parlera pas de détournement, car il n’y a a proprement parler pas de bonne ou de mauvaise manière d’utiliser un produit : il y a un Job To be Done. Cet enchaînement exotique d’actions en est d’ailleurs un bon révélateur. Et une fois que le Job est compris, peut-être qu’il sera judicieux (tout dépend du contexte, de la vision du produit en question, et de la stratégie de l’organisation) de couvrir ce job d’une manière plus directe.
Quoiqu’il en soit, qu’il s’agisse de bug, de besoin de formation ou d’évolution, mettre un PO au support permet de mieux valoriser les informations souvent très précieuses qui y transitent. En plus, cela permet plus facilement de recruter des utilisateurs privilégiés pour vos tests ou interviews.
One last thing
Et si vous avez encore besoin d’être convaincu, je rajoute succinctement trois raisons supplémentaires :
- ça vous permet de suivre l’accueil de vos mises à jours fonctionnelles par les utilisateurs (et les éventuelles régressions), donc créez-vous une routine pour scruter les demandes d’information et autre tickets de support après chaque livraison, pourquoi pas avec votre équipe. Bien sûr, ça ne doit pas dispenser d’essayer d’anticiper sur l’accueil lors de tests utilisateurs plus en amont dans le cycle de discovery, ou bien sur les impacts lors du refinement… Le suivi d’une livraison est complémentaire du discovery/prototypage/analyse d’impact : après tout, il faut livrer pour apprendre
- ça vous permet de protéger votre équipe produit : une des qualités requises du PO c’est l’organisation : il est peut-être, au sein de l’équipe, plus à même de jongler entre différentes activités, et le task switching est peut-être moins couteux pour lui. Avoir un PO qui fait du support, c’est se donner une autre chance de ne mobiliser l’équipe de développeurs qu’en dernier recours, histoire qu’elle puisse rester concentrée sur ses objectifs et qu’elle ne se fasse pas « aspirer » par la gestion de la production qui peut vite devenir très chronophage
- ça force à être son propre utilisateur : vous faites du support, et idéalement vous réglez les problèmes en vous servant de votre produit. Or, c’est toujours plus simple de faire un bon travail produit quand on est à la place de l’utilisateur. On comprend ses frustrations parce qu’on les a aussi vécues. On adhère à ses souhaits parce qu’on a ressenti le même besoin. On comprend ce qu’il veut dire, car on connait l’interface, les interactions, les user flows. Bref, être son propre utilisateur simplifie grandement l’interprétation des interactions avec les utilisateurs et permet d’alimenter le backlog avec de la valeurs concrète/tangible/non supposées. Etc. Et faire du support, c’est un bon moyen de se mettre en situation d’être son propre utilisateur.
