Partie 2 : élaborer la vision produit, la transformer en stratégie et construire son backlog
Dans la première partie de cette série d’articles dédiée à la Vision Produit, nous avons vu en quoi elle consiste, quelle est son utilité et quels sont ses bénéfices pour les équipes et le produit (et les utilisateurs !). Le Product owner (PO) ou Product manager (PM) est, par définition, celui qui porte cette vision. Une fois convaincu de l’utilité de (re)définir une Vision Produit inexistante ou inappropriée, il s’agit pour le PO de la construire. Par où commencer ?
Construire la Vision Produit : par quoi on commence ?
Il va de soi que la Vision Produit ne se construit pas seul(e) : l’ensemble des parties prenantes du produit ont leur pierre à apporter à l’édifice. Le rôle du Product owner est de centraliser les différents axes constituants la Vision Produit, et de fédérer l’ensemble des équipes impliquées autour de ce nouveau cap à suivre.
La Vision Produit repose principalement sur 3 axes :
- la stratégie business (le top management, les objectifs de rentabilité…) : les personnes chargées de la stratégie de l’entreprise, ayant entre leurs mains les notions de budgets et de deadline, sont in fine les mieux placées pour porter cette question ;
- les besoins et les feedbacks utilisateur : de quoi ont-ils besoin ? Quelle solution cherchent-ils dans ce produit, à quel problème de leur quotidien répond-t-il ? Quelles fonctionnalités leur sont vraiment utiles ?
- la créativité / les compétences des équipes : les équipes sont les mieux placées pour répondre à l’ensemble des besoins soulevés par les utilisateurs. Elles ont le savoir-faire nécessaire pour penser et construire les solutions.
La réponse à ces trois questions permet de savoir POURQUOI on se lève tous les matins pour faire grandir le produit : le Product owner est la personne chargée de porter cette question et d’en incarner la réponse.
La première chose à faire pour construire la Vision Produit est probablement de mettre en place des ateliers avec des représentants de ces trois groupes de parties prenantes pour commencer à réfléchir ensemble à la vision que l’on souhaite porter.
À ce stade, si chaque groupe est interrogé séparément sur sa vision du produit, il est intéressant de noter que les réponses divergent le plus souvent, voire ne concordent pas du tout. C’est normal : la vision business n’est pas la même que la vision des utilisateurs, qui elle-même diffère de la vision des équipes de développement ou de support. La vision produit est justement là pour harmoniser tout ça et mettre tout le monde d’accord.
Une fois formalisée, la Vision Produit doit être partagée et validée par tous les acteurs cités plus haut. Mais comment formaliser tout ça ? Comment recueillir les différentes visions et les transformer en une seule et unique Vision, qui sera acceptée et partagée par tous ?
Quels outils pour m’aider à construire ma Vision Produit ?
Il existe plusieurs outils ou méthodes qui ont fait leurs preuves. Ils peuvent tout à fait trouver leur place dans la “boîte à outils” du PO/PM.
Pour commencer, trois petites questions utiles à se poser :
- Pour qui réalisons-nous ce produit ? Qui sont nos utilisateurs ?
- Pourquoi réalisons-nous ce produit ? À quel problème souhaite-t-on répondre ?
- Comment allons-nous résoudre ce problème ? Quelle solution proposons-nous?
Des questions auxquelles il est plus difficile de répondre qu’il n’y paraît…
Il existe une méthode qui prend son point de départ dans la réponse à ces trois questions, mais va plus loin. Plus élaborée, elle permet d’obtenir une idée très juste et concrète de la Vision Produit que nous essayons de construire.
Il s’agit de la méthode QQOQCP, ou le “Qui Quoi Où Qui Comment Pourquoi” :
“I keep six honest serving men. They taught me all I knew. Their names are What and Why and When and How and Where and Who.” Rudyard KIPLING, The Elephant’s Child
Cette méthode consiste à poser un questionnement systématique pour collecter toutes les données nécessaires et dresser un état des lieux complet de l’existant. L’objectif : identifier la vraie nature du problème et en décrire précisément le contexte. En somme, le QQOQCP permet de relever les éléments clés et de les hiérarchiser entre eux.
D’autres méthodes sont tout aussi pertinentes. L’elevator pitch en fait partie. En clair, cette méthode part du principe qu’il faut être capable de parler de son produit en moins de 30 secondes (le temps d’un trajet en ascenseur…). Cela permet d’identifier et de synthétiser les éléments clés du produit.
La consigne est assez simple : compléter la phrase suivante, un peu comme un texte à trous :
Pour (utilisateur cible) qui souhaite (besoin utilisateur), le (nom du produit) est un (description du produit) qui (avantages clés, bénéfices). Contrairement à (produit concurrent ou alternatif), notre produit (facteur différenciant).
Enfin, un autre outil largement répandu aujourd’hui et qui constitue le compagnon de route idéal du Product owner : le Product Vision Board. Comme son nom l’indique, il permet de visualiser sur un seul tableau l’ensemble des idées relatives à la construction de la Vision Produit : les utilisateurs cibles et leurs besoins, la stratégie d’entreprise… Tous ces éléments permettent en bout de course de constituer la Vision Produit partagée. Il en existe divers exemples disponibles sur le web.
Il convient bien sûr de choisir la méthode la plus adaptée au produit et au contexte. Il ne faut pas avoir peur d’ajuster un peu les méthodes, voire de piocher dans chacune d’entre elles pour s’adapter au mieux à son environnement : ces méthodes doivent rester des outils au service de la Vision Produit. Elles ne doivent pas devenir des barrières et enfermer le PO et ses équipes dans une approche rigide, loin de l’agilité donc…
La stratégie produit et ses objectifs concrets découlent ensuite de la vision fixée. Ces objectifs doivent être mesurables c’est à dire chiffrés, et délimités dans le temps.
Mais alors, comment passer de la Vision Produit à des objectifs quantifiables ? Là aussi, il existe plusieurs outils.
Transformer la Vision Produit en stratégie
Tout d’abord, une stratégie c’est un plan qui :
- distribue les ressources disponibles afin d’atteindre un objectif défini à l’avance
- définit les actions à prioriser afin de produire un effet de levier
- s’applique dans un contexte d’incertitude
La Stratégie Produit vise à maximiser la valeur tout en prenant en compte ce que souhaitent les utilisateurs, ce que nos équipes sont capables de faire, et les contraintes business (temps, budget alloué, viabilité).
L’outil de construction de Stratégie Produit le plus connu est le Business Model Canvas. Il permet de représenter sur une seule page l’ensemble des dimensions stratégiques du produit : les clients/utilisateurs, l’entreprise, le produit et les concurrents.
Une fois renseigné, il permet de faire émerger les priorités, les contraintes et les axes d’amélioration.
Cet outil, issu du livre Business model generation d’Alexander OSTERWALDER et Yves PIGNEUR, permet de cartographier les éléments clés et de les organiser d’abord de façon cohérente, ensuite pertinente, enfin, innovante.
C’est une sorte de mémo que l’on peut faire évoluer dans le temps, qui permet de garder la mémoire des évolutions et innovations successives. C’est aussi un moyen efficace de détecter ou penser une innovation permettant de se démarquer radicalement.
Comme pour l’élaboration de la Vision Produit, il existe une multitude d’outils pour aider le Product owner à construire sa Stratégie Produit. Là aussi, il s’agit de rester flexible, ouvert d’esprit et surtout d’être en mesure de s’adapter au contexte toujours unique de son produit et de son entreprise.
Quelle que soit la méthode employée, il existe des approches communes qui vont contribuer à la réussite d’une stratégie :
- une stratégie user centric : l’utilisateur doit être au centre de la réflexion de façon à devancer ses attentes et insatisfactions, tout en étant en permanence à son écoute. Tout, même l’action la plus minime, peut aider à instaurer une culture user centric. Avez-vous entendu parler de Starbucks et de la décision que l’entreprise a prise par rapport au papier toilette ? Pourquoi l’entreprise a-t-elle décidé de passer d’un papier toilette à un seul pli à un papier toilette à deux plis ? Pour créer une expérience client de luxe abordable et montrer à chaque client la valeur qu’il a aux yeux de l’entreprise…
- une stratégie data-driven : fixer des objectifs est le point de départ pour construire une stratégie, et les données sont au service de cet objectif. Il faut être en mesure de les formuler, de les qualifier et de les prioriser afin de déterminer la data qu’il faut collecter et la manière de l’utiliser pour atteindre ses objectifs. Ces derniers doivent être clairs, afin d’identifier plus facilement les indicateurs clés de performance (KPI) et les métriques qui ont un réel effet sur les décisions basées sur les données.
- une stratégie réaliste : une bonne définition des objectifs permet de s’assurer que la stratégie est réaliste. Une roadmap décrit de manière simplifiée et visuelle les orientations produit à prendre afin d’atteindre les objectifs fixés. Disposer d’une roadmap est un véritable atout stratégique car cela permet de s’assurer que toutes les parties prenantes sont alignées sur la Stratégie Produit. Elle représente également un bon outil de suivi et de communication sur les avancées.
- une stratégie flexible : au fil de la vie d’un produit, il faut bien garder en tête que rien n’est figé. Les besoins utilisateurs peuvent changer, tout comme le contexte de marché (arrivées de nouveaux concurrents, innovation…) ou même les objectifs de l’entreprise elle-même. On peut aussi constater, tout simplement, que la première vision stratégique n’était pas la bonne… En d’autres termes : il faut savoir se remettre en question !
- une stratégie collaborative : comme la Vision Produit, l’élaboration de la Stratégie Produit doit être construite par l’ensemble des parties prenantes. Elle doit être largement partagée, et toutes les équipes doivent être alignées sur les mêmes objectifs.
Pour conclure cette liste, une autre méthode particulièrement efficace dans l’élaboration de la Stratégie Produit et la formalisation d’objectifs clairs : les OKR (Objective and Key Result). Inventée dans les années 80, cette approche est aujourd’hui largement répandue.
En deux mots, l’objectif de cette méthode est de lier l’ensemble des objectifs (personnels, de l’équipe, de l’entreprise) à des résultats mesurables.
Pour en savoir plus sur la définition des OKR, une série de trois articles à été publiée sur notre blog Creative Tech ( ici, là, et puis là aussi).
Passer de la stratégie produit à la construction du backlog
La boîte à outil du PO/PM est désormais bien remplie pour construire la Vision Produit, puis la transformer en stratégie. Next step : la construction du backlog ! Et pour cela, l’outil incontournable est sans conteste la story map.
À noter : toutes les étapes précédentes sont indispensables à l’élaboration de la story map.
Le story mapping permet de construire les étapes successives des fonctionnalités tout en gardant l’utilisateur au centre des développements. Pour une bonne story map, il faut : une vision produit partagée, une Stratégie Produit claire et… une bonne connaissance des utilisateurs.
En effet, une story map est généralement organisée comme une suite de user stories disposées par étapes chronologiques en suivant le parcours utilisateur.
Pas de story mapping réussi sans un minimum de recherche utilisateur !
La story map a l’avantage d’être plus lisible qu’un backlog traditionnel et de pousser à la connaissance de ses utilisateurs avant tout lancement de développement. C’est un outil qui se révèle particulièrement utile pour la définition du MVP et la mise sur le marché d’un nouveau produit, mais qui peut être adapté et utilisé dans toutes les situations produits.
Une bonne story map permet de voir plus clairement la corrélation et les interdépendances entre les différentes user stories, et facilite ainsi une bonne priorisation des items du backlog sprint après sprint. C’est également un très bon outil visuel de communication autour de l’avancement des développements auprès des différentes parties prenantes.
Pour résumer, la construction d’une story map nécessite :
- une Vision Produit partagée
- une Stratégie Produit claire
- une bonne connaissance des utilisateurs
- avoir préparé des scénarios utilisateurs
- être capable de découper les fonctionnalités de notre produit en user stories
En résumé, avoir construit une story map permet de s’assurer que l’on a une bonne partie de ce qu’il nous faut pour obtenir un backlog cohérent, ordonné, découpé, priorisé et suffisamment souple pour permettre de tester et d’itérer.
Une fois la story map mise sur pied, c’est (peut-être) le moment d’utiliser un outil particulièrement intéressant mais aussi souvent mal compris : le MVP (Minimum Viable Product, ou produit minimum viable).
Largement utilisé, il est aussi souvent mal interprété. En résumé, le MVP constitue la première version d’un produit, réalisée le plus tôt possible et à moindre frais. Il permet de formaliser une idée très rapidement et de la confronter aux utilisateurs dans des délais très courts.
La story map, en permettant de visualiser l’ensemble des chemins menant à l’objectif produit, est d’une aide précieuse pour définir un MVP. Ce dernier sert ensuite de “base” pour commencer. On peut imaginer par exemple que les items qui constituent le MVP viendront alimenter le backlog pour les premiers sprint.
Mal aimé, cet outil suscite souvent de fortes craintes auprès des représentants business, car on imagine souvent qu’il en résultera un produit inutilisable, ou pas abouti.
Cette crainte est particulièrement avérée dans les structures ou le mindset projet est encore très présent et où l’on pratique un agile dit “dévoyé” : on voudrait un produit finalisé tout de suite en omettant complètement la boucle de feedback, indispensable.
Cette situation présente un fort risque d’effet tunnel et de mécontentement des utilisateurs finaux qui n’auront pas pu “tester” les fonctionnalités du produit les unes après les autres, voire d’adapter leur demande de besoin en fonction de l’évolution du produit.
Prenons l’exemple d’un groupe de personnes (représentant ici les utilisateurs) qui ont besoin d’une voiture (notre produit) afin de rejoindre leur lieu de travail. L’entreprise chargée de la construction de la voiture (représentant ici l’équipe produit) a entendu parler du MVP, mais à quoi bon présenter quatre roues et un châssis ? Six mois plus tard, la voiture est enfin prête ! Mais entre-temps, nos utilisateurs ont découvert les bienfaits du sport et auraient été ravis avec un vélo.
Que pouvons-nous conclure de cet exemple ? Des utilisateurs insatisfaits de cette voiture encombrante et désormais inutile, du temps et de l’énergie gaspillés à la construire, des équipes frustrées du résultat de leur travail.
Dans cet exemple, vous aurez sûrement reconnu une libre inspiration de l’illustration du MVP par le fameux dessin du skateboard d’Henrik Kniberg. Très utilisé, il est lui aussi souvent mal compris.
Pour éviter les malentendus, l’auteur de cette illustration a rédigé un article, disponible ici. Il permet de bien cerner la différence entre une bonne approche produit, et une méthode agile dite “dévoyée”, qui ressemble à une stratégie itérative et incrémentale mais omet les besoins et les retours des utilisateurs.
Conclusion : vous êtes prêt à démarrer
À l’issue de cet article si vous êtes PO ou PM, votre boîte à outils devrait être bien remplie et vous permettre de passer de l’élaboration de votre Vision Produit à la construction de votre backlog. Certains outils tels que la story map permettent également le suivi de vos avancements et s’adaptent aux changements et itérations qui ne manqueront pas d’avoir lieu. Car oui, rien n’est figé !
Il existe un nombre incalculable d’outils et d’adaptation de ces derniers pour aider les PO/ PM dans leur rôle en fonction de leur environnement et de leur produit, toujours uniques. De même, le résultat “final” n’est jamais immuable et il est toujours bon de reprendre certains outils pour “mettre à jour” la vision, la stratégie, le backlog… En fonction des retours utilisateurs, des tendances de marché, et du succès (ou pas !) des évolutions apportées… Une boucle itérative sans fin qui n’a qu’un seul objectif : un produit merveilleux et des utilisateurs contents !