Revenons à notre cartographie. Il est possible que la solution intègre une certaine complexité qui rassemble différents cœurs de métiers. C’est pourquoi on décompose les caractéristiques du produit en « modules » et « composants ». Les modules sont fonctionnels et les composants sont techniques. Par exemple, avec le verre de champagne, il y a le module de maintien et le module conteneur. Le module de maintient est doté d’un cylindre que saisi l’utilisateur et d’un pied pour poser le verre. Le conteneur comprend la partie du verre qui permet de recevoir le liquide.
Parfois, le même composant sert deux modules différents. C’est le cas dans les solutions complexes comme les logiciels informatiques.
Cette approche est très adaptée à l’agilité puisque les modules peuvent permettre de réaliser des validations fonctionnelles, les composants peuvent permettre de faire des validations techniques, et le tout peut permettre de définir un MVP : une solution avec le minimum de caractéristiques qui apportent déjà de la valeur et sur lesquelles le client est intéressé d’investir. Cette façon de faire permet ensuite de structurer chaque évolution.
Graphiquement, la cartographie se construit de droite à gauche : du client et des opérateurs vers les fonctionnalités (modules et composants). Les équipes qui réalisent les « composants », lorsqu’elles vont vouloir faire des arbitrages et prendre des décisions, le ferons en cherchant l’origine de chaque composant en lisant de gauche à droite.
Elles pourront ainsi remonter jusqu’aux groupes de clients et éventuellement les sonder. (« pourquoi je dois développer cette fonctionnalité ? Ah ok, parce que ça lui apporte ça… »). Il est très important pour les équipes techniques de connaître le sens de ce qu’elles font car les décisions techniques sont constantes et les spécifications ne sont jamais assez complètes. C’est un point de grosse frustration pour les développeurs informatique par exemple. Il y a toujours de nouvelles questions qui émergent pendant un projet, et des arbitrages à réaliser.
Comment alors construire cette cartographie ? C’est tout l’objet des blocs présentés dans l’article Comment organiser le Product Management ? qui sont une évolution de la cartographie des 5 cercles Lion-up présentés en 2020 sur mon ancien blog Shy Robotics et dont j’ai repris certains paragraphes ici.
Les documents de référence du product manager
La dynamique du management de produits nécessite une compréhension solide des divers outils et méthodes à la disposition d’un product manager. Chaque document, du Job to be Done (JTBD) aux Product Requirement Documents (PRD), en passant par les Objectifs Key Results (OKR), joue un rôle crucial dans le cycle de vie du développement de produits. Penchons-nous sur chacun de ces éléments.
