Construire le bon produit : le Pourquoi, le Quoi et le Comment

Rappel : ne faites pas confiance aux noms de méthodologies fantaisie

J’ai tendance à me répéter dans tous les articles que je publie ici, mais laissez-moi le faire encore une fois pour ce sujet particulier : je ne crois pas aux dogmes.

Je crois que beaucoup de dogmes sont davantage aspirationnels et théoriques que des pratiques réellement et factuellement mises en oeuvre. Surtout dans le contexte des workflows de livraison logicielle.

J’ai eu la chance de travailler avec différentes méthodologies prétendument strictes, que ce soit Scrum, Kanban, XP, le modèle Spotify ou Shape Up. Toutes ont vu à un moment un thought leader publier un billet plus ou moins long pour expliquer comment les choses devraient fonctionner. Devraient, pas peuvent. D’ailleurs, les gens de Spotify ont eux-mêmes admis plus tard que leur modèle n’avait jamais été entièrement adopté et présentait des défauts majeurs.

Arrêtons-nous là sur ce chapitre, car vous pouvez lire mes réflexions à ce sujet dans une publication passée.

Il y a pourtant un texte, que l’on pourrait considérer comme un dogme mais qui est davantage, à mon avis, une collection de directives sensées : le Manifeste Agile. Le début de tout. Eh bien, de nombreux frameworks de livraison au moins. Si vous croyez encore que l’agilité consiste à mettre des post-its sur un mur, allez lire cette page.

Ce qui a fonctionné dans les équipes avec lesquelles j’ai travaillé

Ce qui est clair, c’est que nous cherchons tous un workflow de design et de livraison approprié qui nous permette quand même de faire de la maintenance et de trouver du temps pour l’innovation. Et comme chacun des fameux dogmes a tenté de le faire, chacun a des choses intéressantes à considérer.

Pendant mon temps chez Traveldoo (une entreprise Expedia qui construisait des solutions logicielles de gestion des voyages et des notes de frais), nous avions une implémentation plutôt correcte de Scrum. Pourtant, après avoir essayé pendant un moment de l’appliquer à la lettre, notre équipe souffrait de sa rigidité et de certaines parties non pertinentes. Donc, comme le Manifeste Agile le conseille, nous avons fait de l’introspection, itéré et amélioré pour trouver notre propre voie.

C’était encore plus de travail chez SensioLabs et Blackfire. Quand j’ai rejoint, j’étais tellement content du framework que j’avais mis en place que je voulais le reproduire. Croyez-moi, j’ai vu de grands ingénieurs comme Grégoire Pineau ou Romain Viovi trembler d’anxiété et de frustration quand je leur ai dit qu’on allait commencer à utiliser Jira. Énorme échec de ma part. Et énorme courbe d’apprentissage. Sur huit ans, nous avons itéré sur nos processus. Et à chaque fois que je ramenais un vocabulaire lié à Scrum, je voyais l’un des ingénieurs me lancer un regard furieux.

Ce qui a finalement fonctionné, c’est quand Alexandre Salomé a rejoint l’équipe et que nous avons travaillé conjointement pour trouver un moyen simple d’exprimer comment délimiter le travail et les responsabilités. Il y a un peu plus que ça, mais l’essentiel est dans la définition du Pourquoi, du Quoi et du Comment.

Le Pourquoi

En tant que Product Manager (peu importe l’ancienneté ou le titre de poste), c’est votre domaine. C’est l’agrégation et le résumé de votre discovery, la vision et la stratégie, et l’innovation (d’un point de vue produit).

Il dit les choses très clairement : il s’agit du pourquoi vous voulez construire une fonctionnalité donnée.

Il donne tous les éléments de contexte clés, justifie la valeur ajoutée et définit idéalement des métriques que ça devrait aider votre produit à atteindre. C’est une définition critique qui devrait aider les développeurs à comprendre pourquoi et quand prioriser les développements liés à cette fonctionnalité. Il est de votre responsabilité d’avoir un briefing très complet, même s’il est tout à fait normal de manquer certains éléments la première fois que vous le présentez à l’équipe d’ingénierie. C’est bien, collectez simplement leurs retours et questions, et itérez jusqu’à ce que ce soit prêt.

Oubliez les specs et les user stories, oubliez les wireframes et les maquettes. Ce n’est pas le bon moment, ce n’est pas le bon endroit.

Où l’écrire ? C’est vous qui voyez, vraiment. Ça peut être un Google Doc, une page Confluence, une carte ProductBoard. Nous l’avions dans ProductBoard, et dans GitHub, comme introduction à une issue qui nous aidait à suivre l’avancement de la livraison.

Le Comment

J’espère que vous m’excuserez de sauter directement à celui-ci, alors que nous ne savons pas encore quoi nous allons construire, mais je trouve plus facile de commencer par définir les extrêmes, les limites du périmètre de responsabilités.

Cette partie appartient aux ingénieurs (donc vous, si vous n’étiez pas le product manager qui lisait les lignes précédentes). Évidemment, un PM ne vous dira pas comment coder, concevoir l’architecture, construire l’infrastructure, sélectionner les librairies et les composants tech. C’est votre expertise et votre jugement.

Et pour faire votre travail avec les ressources appropriées, avoir une compréhension cristalline du pourquoi est essentiel. Pour le dire simplement, vous ne construirez pas la même infrastructure pour une charge de quelques centaines de pages vues par mois, ou un LLM qui recevra des requêtes de plusieurs milliers d’utilisateurs par jour.

Au fil des itérations sur la définition et le design du “quoi”, nous avons trouvé une bonne pratique consistant à planifier toutes les tâches qui seraient nécessaires pour livrer complètement une fonctionnalité donnée. En partant des tâches les plus critiques (comme le provisionnement de machines) jusqu’aux moins critiques (changer la couleur bleue du design system pour la 10ème fois dans l’année).

Toutes seraient listées sous forme de liste de cases à cocher dans l’issue GitHub d’origine. C’est un conseil très tactique, issu des nombreuses améliorations que nous avons expérimentées avec les fonctionnalités GitHub, qui nous ont facilité la vie. Pourquoi faire ça ? Parce que GitHub supporte directement la création d’une PR à partir d’un item de liste de cases à cocher, ou de le lier, et aidera à suivre l’avancement global de la livraison au niveau de l’Epic, euh… de l’issue.

Le Quoi

Traditionnellement la partie où il y a le plus de dissensions. Héritage des pratiques Waterfall, c’est habituellement le moment où les Product Managers veulent briller en décrivant plus ou moins en détail comment la fonctionnalité fonctionnera et à quoi elle ressemblera, éventuellement avec le soutien de Product Designers.

C’est un travail considérable, si c’est fait correctement, puisque vous voudrez tenir compte de tous les cas limites et de tout impact sur les parties existantes du produit. Vous pouvez finir par passer des semaines, voire des mois en design.

Et vous finirez par devoir le soumettre aux équipes d’ingénierie dans un super grand document qu’elles ne liront jamais, ou dans une présentation live très courte qui ne vous permettra jamais de couvrir tous les aspects.

Et encore, à condition que vous n’ayez rien oublié, que les yeux de faucon des développeurs repéreront directement et feront s’effondrer votre partie de Jenga.

Ça ne signifie pas que vous ne devriez pas y avoir réfléchi, ni avoir rédigé une description ou une maquette ; ça donne un point de départ.

Mais le quoi est clairement le lieu de collaboration entre ingénierie et product management. Concevoir le quoi est un processus itératif, de sorte que dès le premier jour, on évite d’imaginer reconstruire Facebook, quand tout ce qu’on voulait c’était poster une note sur un graphique.

C’est le moment où vous négociez ce qui est vraiment critique pour atteindre le pourquoi et les métriques associées, et ce qui n’est que du superflu fantaisiste. Vous négociez le 80/20. Les 80% du périmètre fonctionnel utile (espérons-le réalisés dans les 20% du temps), pour ne pas gaspiller 80% du temps sur les 20% du superflu.

C’est le moment où vous pouvez finir par décomposer l’issue GitHub d’origine en plusieurs issues, si vous réalisez que certaines des choses que vous vouliez construire ne contribuent pas directement au pourquoi, mais pourraient quand même présenter un intérêt plus loin dans la route.

En pratique

Cet article commence déjà à être long, donc je n’entrerai pas dans les détails exacts de la façon dont nous construisions les tableaux de projet, quels outils nous utilisions pour donner quel niveau de détail dans les designs visuels.

Vous voudrez probablement vérifier les critères INVEST, car cette partie nous a été super utile pour décomposer le travail à faire, atteindre une capacité à estimer la charge de travail pour construire une fonctionnalité donnée et obtenir une certaine prévisibilité de roadmap. Oui, c’est possible.

Je n’oserais de toute façon pas écrire ici une autre de ces méthodes fantaisie, même si en toute humilité je suis conscient que mon site personnel ne génère pas tout à fait autant de trafic que le blog Spotify.

Le Pourquoi, le Quoi et le Comment ont été déterminants pour nous aider à déterminer un workflow de design et de livraison approprié, et des responsabilités claires. J’espère que ces principes de base pourront vous aider !

Note : la partie drôle, c’est qu’au fil des années, nous avons abouti à un framework qui était en réalité super proche de Scrum, y compris le rythme de livraison et les rituels, même si nous avons toujours veillé à ne pas utiliser son vocabulaire. Et pourtant, ce n’était pas du Scrum. C’était ce qui avait du sens pour notre équipe, notre produit et notre entreprise.