Easy Tech #22 - pourquoi on sous-estime la difficulté de la Delivery
Et pourquoi c'est dangereux
Salut à toi,
Très heureux de te retrouver ce dimanche soir !
On va parler d’un sujet qui me tient à coeur : la Delivery. J’en ai déjà parlé de manière un peu détournée dans plusieurs éditions (sur l’excellence technique, sur l’agile, sur le DevOps), mais je n’ai jamais abordé frontalement le sujet.
Notamment ce que je veux voir avec toi aujourd’hui c’est analyser pourquoi aujourd’hui on sous-estime trop la Delivery. Et les risques que ça fait peser sur un produit.
C’est parti 💪
Si tu veux mettre en avant ton projet, ton produit et tes services auprès d’une audience de passionnés de la tech et du Product Management, tu peux me contacter sur LinkedIn ou par mail.
Définition, histoire et contexte de la Delivery
Définition
Comme son nom l’indique, on est sur une phase de “Livraison”.
On a trouvé le bon problème et une piste pertinente de solution à celui-ci. On va donc pouvoir développer concrètement cette solution sous forme d’un logiciel, de lignes de code qu’on va livrer aux utilisateurs.
Pour une définition synthétique, on pourrait dire que l’objectif de la Delivery c’est de livrer aux utilisateurs un logiciel d’excellente qualité (niveau UX et tech) tout en respectant les contraintes business.
Pour définir cette phase on peut donc dire qu’elle répond à deux caractéristiques :
D’abord comme évoqué, la matière première de cette phase est des lignes de code pour constituer un logiciel, comme celui qu’on peut installer sur nos ordinateurs ou nos téléphones portables
Ensuite ce logiciel a vocation à être rendu accessible à des utilisateurs finaux ; c’est le premier moment où le « produit » commence vraiment à exister au sens « apporter de la valeur ». En Framing ou en Discovery, en effet, il n’existait pas encore.
Histoire
J’ai creusé l’histoire de l’agile dans l’édition sur le DevOps que tu retrouveras ici.
Aujourd’hui, je te propose donc davantage de te focaliser sur le lien entre Delivery et Product Management ce qui passe par l’analyse du lien entre l’UX et l’agile.
Le décalage originel entre UX et agile
L’agile s’est développé à partir des années 1980 pour les premiers éléments théoriques jusqu’à son explosion à partir du Manifeste agile dans les années 2000. Mais quel lien avec les sujets UX et expérience utilisateur ?
Ce qui est intéressant, c’est que les démarches UX ne sont pas vraiment intégrées nativement dans les démarches agiles. Au niveau historique ce sont vraiment deux courants qui se développent de manière assez indépendante.
À partir des années 1970, on pose des premiers principes pour renforcer l’aalyse des systèmes et problèmes complexes. Des problèmes multi-dimensionnels = il est nécessaire de mélanger différents axes pour les analyser, les comprendre et influencer dessus. Des problèmes complexes = pas de possibilité de tout rationaliser par une formule, de tout expliquer facilement
C’est pour résoudre ces problèmes que la discipline du Design Thinking va petit à petit voir le jour à partir des années 1900. Avant de s’affirmer comme une méthodologie globale et sérieuse. En particulier sous l’impulsion de l’agence de design Ideo.
Pour autant, à cette époque, le design Thinking et discipline UX ne sont pas intégrés par construction dans les processus agiles.
La difficulté à intégrer l’UX dans les process agiles
Il y a donc un décalage originel entre UX et agile. Toutefois, même lorsqu’on va se rendre compte de la pertinence de mettre de l’UX dans les processus agiles, on va tout de même peiner à réunir ces deux approches de manière efficace.
Cela peut s’expliquer par trois éléments
D’abord, les approches Design Thinking type Discovery peuvent être perçues comme un retour à du cycle en V (je prépare mes maquettes puis je développe). À l’époque il y avait sûrement un rejet plus fort des approches waterfall / cycle en V par rapport à aujourd’hui. Aussi toute démarche qui éloigne le moment où on écrit la première ligne de code, pouvait être vue comme suspecte et comme un risque de refaire tomber dans cette approche.
Ensuite, et c’est lié au premier point, l’UX est assimilé au fait de faire des maquettes et de réaliser des prototypes / interfaces. Dans les manuels d’agile comme Succeeding with agile de Mike Cohn. C’est comme ça que celui-ci envisage une éventuelle collaboration avec les équipes produit / agiles. Les Designers préparent les maquettes pendant le sprint n°1 puis les développeurs développent pendant le sprint n°2. Il y a donc une incompréhension assez forte de ce qu’est l’UX. C’est-à-dire la capacité d’identifier les bons problèmes et les bonnes solutions à mettre en face. Cela dépasse largement le fait de réaliser des maquettes !
Enfin, au niveau organisationnel, les frameworks agiles comme Scrum ne prévoient pas de profils UX au sein des équipes agiles. On leur préfère des Product Owners, Scrum Masters et développeurs. La question du nombre de Product Designers par équipe est épineuse et pas facile à résoudre. Mais je pense qu’il faut a minima un Designer à 50% pour une équipe produit avec 1 Product Owner, 1 Scrum Master et 5 développeurs. Cependant, compliqué d’aller à l’encontre de la doctrin Scrum. Notamment parce que Scrum est très prescriptif comme framework. C’est-à-dire que quand on l’applique, a priori on ne va pas trop se poser de questions et remettre en cause ce qui est expliqué dedans. D’où la difficulté d’aller à son encontre en rajoutant des UX designers dans les équipes.
Contexte personnel
J’ai commencé à bosser en 2018, à cette époque l’accent était beaucoup mis sur le Delivery et l’agile. Il y avait une vraie volonté de changer de manière de fonctionner pour passer sur des manières plus innovantes de bosser et en mettant l’utilisateur au centre.
En particulier, il y avait beaucoup de sujets de transformations pour mettre en place de l’agile à l’échelle. C’est à dire du fait de faire travailler en agile, 3-5-7 voire 10 équipes en parallèle ! J’ai beaucoup travaillé pour mettre en application le framework SAFe à l’époque (Scaled Agile Framework).
Pour autant, tout n’était pas facile. Une des grosses difficultés qu’on rencontrait, c’est que l’agile / l’agile à l’échelle était un peu pris comme une baguette magique. On prenait une organisation et on espérait pouvoir la faire passer facilement d’un état sans agile à un état avec de l’agile parfaitement implémenté. Évidemment, comme on l’a vu la semaine dernière avec l’édition sur la Culture, c’est plus compliqué que ça.
Un point important à avoir en tête, c’est qu’à l’époque, l’UX restait un sujet un peu annexe, très axé innovation. Dans les équipes de Delivery il n’y avait pas designers, on aurait même trouvé ça un peu étrange. Et le Design Thinking, aujourd’hui si central dans les phases de Discovery (Easy Tech Design Thinking) était employé dans des contextes différents, assez peu numérique.
Pourquoi la Delivery est sous-estimée aujourd’hui
Raison 1 : une volonté des PMs d’être moins opérationnel
En général un PM junior ou PO est focus sur la delivery. Et le premier poste d’un PM junior est celui de Product Owner.
Pour deux raisons :
La delivery est centrale dans le processus de construction du produit, c’est le moment où on va construire, matérialiser nos idées sous forme de lignes de code. Afin que le logiciel « prenne vie ».
Le Product Management s’est développé dans des organisations où l’agile avait été mis en place au démarrage. Aussi, c’est souvent un sujet mieux maîtrisé par l’organisation, ce qui justifie de faire travailler dessus un profil plus junior.
En tant que jeune PM ou PO, ça veut dire être focalisé sur deux types de tâche :
Interagir avec les développeurs au sens large. Vous êtes intégrés dans l’équipe au jour le jour, vous vous levez, vous mangez, vous dormez dans l’équipe. Ça revient à discuter priorisation, tester le produit et aller débugger des fonctionnalités avec les développeurs.
Effectuer de la gestion de projet / PMO. Au-delà de votre rôle opérationnel dans l’équipe de développement il va être nécessaire de piloter l’ensemble des discussions et des réunions qui permettent de construire le produit dans de bonnes conditions. C’est souvent un rôle qui échoit au PO / PM junior. C’est très bien, car cela permet de comprendre le processus et la dimension politique autour de celui-ci.
Ces tâches sont très formatrices et hyper instructives en début de carrière pour autant on constate souvent que les PMs plus expérimentés rechignent à les faire.
Il est vrai qu’on attend moins en général les PMs plus seniors sur ces sujets :
Les PMs expérimentés interviennent aussi dans les phases de Discovery et de Growth
Les Lead PMs doivent investir du temps pour développer une culture produit performante tout en se focalisant sur des tâches de management
Enfin les Head of Product / CPO vont travailler sur des aspects stratégiques et de la communication high level, comme aller présenter la roadmap produit aux actionnaires / investisseurs.
Bref, les actions liées à la Delivery ne sont plus centrales dans la suite de la carrière du PM, ce qui justifie que pas mal de PMs les délaissent. Ils ont le sentiment que ça les juniorise ou du moins, que ça les prépare moins à la suite.
Raison 2 : un mouvement de maturité pour remettre en avant la discovery et l’UX
Comme on l’a vu précédemment, il y a une sorte de désamour originel entre l’agile et l’UX. Et ce désamour est encore présent aujourd’hui ! Dans la dernière version du Scrum Guide qui date de 2020, on ne prévoit pas de rôle de Designers et pas de tâche de User Research ni de Continuous Discovery.
J’ai même envie d’aller plus loin pour voir le Product Management comme une manière de remettre l’UX au cœur du combat, avec les 3 cercles. Face à l’oubli des agilistes, le courant du Product Management va essayer de sortir le développement logiciel de son focus sur la technique pour remettre en avant à la fois les enjeux d’UX liés aux utilisateurs et également les enjeux business.
De manière très concrète, c’est pour ça à mon avis, que la phase de Discovery présente une forte représentation des méthodologies UX, pour mettre les choses sur les bons rails et partir du bon pied. Puis qu’ensuite, les processus UX sont inclus tout au long de la vie du produit, y compris en Delivery (à travers notamment la Continuous Discovery) et en phase de Growth également au cours de laquelle on va continuer à travailler cette expérience utilisateur pour l’améliorer le plus possible.
Je pense que ces évolutions sont très positives parce que les enjeux UX sont cruciaux lorsqu’on crée un produit. Mais attention à ce que ça ne se fasse pas au détriment de la Delivery.
Raison 3 : commoditisation de plusieurs briques technologiques
Enfin, c’est un autre élément plus récent. Aujourd’hui, plusieurs tâches - historiquement techniques - deviennent plus faciles à réaliser de par la création de briques techniques sur étagère pour automatiser leur mise en place et leur gestion.
Quelques exemples pour illustrer ça :
Le mouvement no code d’abord. Quand on regarde la communication de Bubble - un logiciel très connu pour créer des applications sans écrire de lignes de code -, leur axe de communication est clairement autour de “on peut créer une start-up sans CTO”. Avec des témoignages de CEO qui expliquent qu’ils ont fait toute l’application eux-mêmes sans avoir besoin d’un expert technique.
Le développement de logiciels pour les entreprises comme SAP. De tels logiciels vont directement se brancher dans les systèmes de l’entreprise sans forcément avoir besoin de développeurs pour les développer de zéro. On a souvent besoin d’experts du logiciel ensuite, mais pas besoin de rentrer véritablement dans la logique du code sous-jacente.
Les évolutions de l’infrastructure permises par les fournisseurs de Cloud. Avec AWS ou GCP, il est désormais possible de créer une architecture technique beaucoup plus facilement qu’auparavant. Il y a parfois besoin d’un peu écrire du code mais c’est largement simplifié.
Tout ceci est vrai mais attention car en réalité :
Dès qu’on veut répondre à des cas d’usage un peu spécifiques - ce qui arrive toujours dans la vie d’un produit - on est prisonniers de ces solutions qui ont l’air très pratique de prime abord mais qui nous emprisonnent tout de même un petit peu.
C’est d’ailleurs le vrai problème au fond de toutes ces solutions sur étagère. On y gagne une forme de tranquillité d’esprit mais c’est parfois compliqué d’en sortir. Il y a notamment eu de très fortes critiques à l’encontre d’applications no code qui ont fait évoluer leur prix récemment à la hausse. Les clients ayant dit qu’il était malhonnête de faire augmenter les prix dans la mesure où ils n’avaient pas d’alternatives.
Pourquoi c’est dangereux et comment s’en prémunir
Première difficulté : la prendre trop au sérieux
Premier syndrome, la tête dans le guidon
Comme évoqué, la Delivery est un moment assez grisant. On délivre des fonctionnalités et c’est très sympa comme moment. Sympa parce que déjà c’est une forme d’accomplissement de créer ces fonctionnalités. Ça concrétise les efforts déjà réalisés depuis le début sur les phases de Discovery et Framing. On commence à voir un vrai produit sortir de terre.
Or de la même manière qu’un cycliste qui est la tête dans le guidon va vite et vit un moment agréable, on peut se retrouver à ne pas réussir à prendre du recul et à avoir du mal à retrouver du sens à tout ce qu’on fait. C’est le syndrome de la tête dans le guidon. L’équipe est focalisée sur livrer des features, livrer des features, livrer des features. Mais on perd un peu le « pourquoi » de la chose. C’est dommage parce qu’on a passé beaucoup de temps à essayer de trouver le bon problème dans la phase de Discovery. On veut délivrer de la valeur. Oui mais encore une fois, livrer des fonctionnalités procure un sentiment extrêmement positif. C’est un peu comme cocher des éléments de sa TO-DO list.
Voici donc cette première manière de prendre la Delivery trop au sérieux. Elle est dangereuse pour deux raisons :
D’abord parce que comme précisé, on oublie de remettre en perspective pourquoi on fait les choses. Or, le rôle d’une équipe produit ce n’est pas de délivrer des features. De même que le rôle d’un développeur n’est pas d’écrire des lignes de code. Ou que le rôle d’un designer n’est pas de produire des interfaces. Le rôle d’une équipe produit, d’un développeur et d’un designer, c’est d’apporter de la valeur en construisant un produit qui répond à un vrai problème de l’utilisateur. (Ou qui lui permet d’exploiter une opportunité ou de réaliser un désir).
Ensuite, le risque avec la tête dans la guidon, c’est que c’est une situation qui peut facilement dégénérer. C’est une situation intense et fatigante. D’autant qu’on manque de sens, ce qui peut renforcer la fatigue mentale des équipes. « Mais pourquoi on fait tout ça ». En outre, c’est généralement difficile de ne pas être isolé et dans son coin lorsqu’on est dans ce mode là. S’isoler sans voir l’utilisateur peut par exemple expliquer pourquoi on dévie vers ce mode de livraison de feature sans penser à autre chose.
💡 Comment éviter d’avoir la tête dans le guidon ?
Quelques idées :
Repartir dans les livrables structurants autour des valeurs du produit et de pourquoi on fait les choses
Se redemander pour chaque feature planifiée “pourquoi je fais ça ?” “quel est le problème que je résous ?” “quelle est la valeur que j’apporte à l’utilisateur final ?”
Continuer à aller voir l’utilisateur final et échanger sur ces besoins pour ne jamais l’oublier
Deuxième syndrome, la roue du hamster
On imagine assez bien cette image du hamster qui tourne dans sa roue sans fin. Il est dans sa cage sans perspective d’en sortir et il ne fait que tourner sur sa roue sans qu’il y ait aucune perspective que ça s’arrête. La différence avec la tête dans le guidon - si on garde l’analogie - c’est que quand je suis sur un vélo, la tête dans le guidon, dans une descente… la descente s’arrête toujours à un moment. Pour le hamster dans sa roue, on peut potentiellement continuer jusqu’à l’épuisement.
Et c’est bien l’épuisement le problème. Lorsqu’on perd encore plus le sens et qu’on délivre pour délivrer. Il survient un moment où les équipes ressentent de la fatigue. Il faut imaginer qu’une équipe dans cette situation a énormément de fonctionnalités à développer et une grosse pression pour les faire atterrir rapidement. Elle est dans cette roue de hamster parce qu’elle fait face à un pic de charge important et veut se focaliser pour être le plus efficace possible. Le problème c’est que ce pic de charge n’est pas un événement ponctuel mais bien une continuité d’urgence et de fonctionnalités à délivrer absolument.
L’équipe se retrouve donc à passer d’urgence en urgence et de priorités en priorités. Cette situation tendue renforce encore plus la perte de sens et la compréhension de pourquoi on fait les choses. On finit par délivrer des fonctionnalités par habitude, dans l’urgence et dans la souffrance parce qu’on ne sait plus faire autrement. Évidemment les conséquences morales et psychiques pour l’équipe sont désastreuses. En outre, quand on délivre de manière très intense comme cela, on manque de marge pour traiter des sujets liés innovation ou prendre du recul pour s’améliorer en continu. Au-delà des dangers liés au moral des équipes, ce n’est pas non plus une situation optimale en termes de delivery pur. Méfiance à cette situation de « burn out » d’équipe, qui en vient à ne plus trouver de sens à ce qu’elle fait voire à détester le produit sur lequel elle bosse.
💡 Comment éviter d’être dans la roue du hamster ?
Quelques idées :
Mettre en place des respirations naturelles au sein des cycles de Delivery pour permettre de prendre un peu de recul et de repos
Éviter le terme d’urgence au maximum et toujours l’employer pour des choses très ponctuelles (1 urgence par mois maximum)
Prendre du temps régulièrement avec les différents membres de l’équipe pour évoquer leur niveau de fatigue et de motivation
Deuxième difficulté : ne pas la prendre assez au sérieux
Premier syndrome, sous-investir sur les sujets techniques et négliger l’excellence technique
N’oubliez jamais que construire un logiciel est une tâche complexe difficile. La nature immatérielle de l’informatique fait qu’on sous-estime cette tâche. Donc il faut tout le temps remettre en perspective et se demander « la qualité de la conception technique est-elle suffisante ? Serai-je aussi serein si je construisais une voiture, un bateau ou une fusée ? »
Pour être vigilant sur les sujets d’excellence technique et mettre en place les bonnes actions pour votre organisation, je vous renvoie à l’édition EasyTech #18 qui était dédiée à ce sujet.
Deuxième syndrome, le mouton à 5 pattes.
Il survient lorsqu’on considère tout simplement la Delivery comme une phase pour « créer plein de fonctionnalités » et c’est tout. Lorsque la valeur qu’on s’identifie réside principalement dans le nombre de fonctionnalités qu’on délivre, on en vient à faire perdre du sens au produit. On va rajouter des choses au risque de complexifier l’interface pour l’utilisateur.
En général, il ne s’agit pas d’un choix conscient. On tend à vouloir construire un mouton à 5 pattes lorsqu’on rencontre des difficultés à :
Prioriser, de manière générale faire des choix est toujours délicat. Choisir c’est renoncer. Et remettons nous bien en tête qu’on parle d’une équipe produit qui bosse dur, qui a envie de délivrer de la valeur. Ce n’est jamais agréable ou plaisant de renoncer à des fonctionnalités qu’on a spécifié, bossé, designé. Pire, parfois prioriser veut dire revenir sur la parole qu’on a donné à un utilisateur ou à un prospect auquel on a dit « on va développer ça rapidement pas de soucis ». Prioriser c’est difficile on va en parler plus en détail par la suite. Lorsqu’on peine à ce niveau, on tend à construire des produits fourre-tout et patchworks.
Faire des choses simples, puisque c’est un biais vu et revu, en particulier chez les constructeurs de produit. On aime construire des choses complexes. Lorsqu’on est petit et qu’on joue avec des Legos ou des Kaplas, on essaye de faire les constructions les plus grandes possibles. (Presque) Personne n’est attiré spontanément et naturellement vers la simplicité et le design épuré. On dit souvent la nature a horreur du vide, ça résume bien l’enjeu. De nombreuses équipes éprouvent donc une grosse difficulté à faire des choses simples et à ne pas empiler des fonctionnalités juste pour que leur produit ait l’air plus complexe.
Si on construit un mouton à 5 pattes ou un logiciel qui va devoir faire tout et son contraire, on risque de ne pas réussir à apporter de la valeur à nos utilisateurs. En étant trop généraliste trop vite, on ne va pas apporter de la valeur de façon suffisamment concentrée à nos premiers utilisateurs. Si on essaye de servir tout le monde, on ne va servir personne de manière suffisamment qualitative. Un jour évidemment, on pourra rendre notre produit beaucoup plus polyvalent et généraliste. Mais dans un premier temps, il faut déjà réussir à délivrer un peu de valeur. Même si cela veut dire réduire le nombre de pattes du mouton et focaliser le logiciel sur le fait de réaliser une tâche seulement.
💡 Comment éviter d’être dans la roue du hamster ?
Quelques idées :
Être très vigilant vis à vis du biais de complexité qui menace toujours à la fois les constructeurs et les utilisateurs de produit (j’en ai parlé dans l’épisode dédié aux biais que tu peux retrouver ici)
Mettre en place une démarche de priorisation focalisée sur la résolution de problèmes pour ne pas pousser des fonctionnalités superflues
Prendre des moments réguliers pour faire un brainstorming simplicité, afin d’identifier des axes de simplification de l’application (tous les mois ou trimestres par exemple)
Troisième difficulté : en rester prisonnier
Premier syndrome, la tour d’ivoire
C’est un prolongement assez logique de la tête dans le guidon. En l’occurrence ici, l’équipe produit s’isole trop et se coupe de son environnement. On livre des features entre nous, en équipe. On est bien en équipe. Et on ne veut plus s’ouvrir à l’extérieur ni prendre plus de recul parce que c’est plus confortable de rester entre soi.
D’un côté c’est très important que les équipes créent des liens forts et qu’elles soient à l’aise pour travailler ensemble de manière confortable. De l’autre il faut être vigilant parce qu’un isolement trop important nous éloigne de trois interlocuteurs importants :
L’utilisateur comme toujours. C’était déjà le problème de la tête dans le guidon. Mais à ce stade, la tour d’ivoire va encore plus loin. On n’évite pas le dialogue avec l’utilisateur juste parce qu’on est dans une phase de rush transitoire. Ce qui pourrait se justifier. Dans cette situation, on va carrément aller jusqu’à repousser le dialogue avec l’utilisateur. Parce que ces discussions nous sortent du Delivery – on ne peut pas avancer sur les features quand on discute avec son utilisateur. Parce que ces discussions sont inconfortables – on doit accepter que les features développées ne soient pas parfaites et qu’il faille les ajuster pour apporter plus de valeur. Parce que ces échanges nous sortent de notre bulle avec l’équipe produit. Il est clair que c’est parfois pénible d’avoir des discussions avec l’utilisateur. Mais mettre la poussière sur le tapis n’est pour autant pas la solution.
Le business également. Quand on parle de business, on renvoie à l’ensemble des acteurs qui ont pour but de s’assurer que le produit est rentable et viable financièrement. À la différence des UX designers ou acteurs techniques qui sont en général très intégrés aux équipes produit, c’est encore très (trop) rare qu’on ait des profils type Product Marketing Manager (PMM) pour incarner cette fonction de manière opérationnelle et régulière. La tour d’ivoire nous éloigne également de ces enjeux. On préfère se focaliser sur finaliser nos tickets de User Stories plutôt que de se demander si cela fait du sens au niveau financier. C’est plus simple et ça fait se poser des questions moins pénibles. Le risque est de ne pas maintenir un dialogue suffisamment soutenu. Et qu’on se rende compte de potentielles faiblesses de notre produit au niveau financier trop tard. Or plus on se rend compte des problèmes tard, plus on risque d’avoir du mal à les résoudre et plus ils risquent d’avoir des conséquences négatives.
Les sponsors enfin. Personne n’aime aller voir ses sponsors pour leur présenter les avancées du produit. Les sponsors sont loin des sujets, ils manquent d’empathie sur ce qu’on fait, ils ont l’air obsédés par l’argent et ils maîtrisent très peu les sujets tech. Bref, ce n’est pas une partie de plaisir. En plus, préparer ces réunions avec eux prend du temps et de l’énergie. Donc c’est un phénomène assez courant pour des équipes dans leur tour d’ivoire d’éviter au maximum de voir les sponsors et de s’en isoler pour s’éviter des soucis. Pour autant, de la même manière que le business, il faut maintenir un échange régulier. Sinon on met la poussière sur le tapis. L’écart entre l’idée que se fait le sponsor du produit et sa réalité diverge. Et le jour où il y a correction, c’est toujours très difficile à gérer et pire que si on avait juste maintenu un contact.
💡 Comment éviter d’être bloqué dans sa tour d’ivoire ?
Quelques idées :
Maintenir un lien constant avec les utilisateurs, notamment dans le cadre d’une démarche de Continuous Discovery (dont j’ai parlé ici)
Intégrer des PMMs aux équipes ou prévoir un reporting dédié aux acteurs business tous les mois
Conserver des moments d’échanges réguliers tous les 3 à 6 mois fonctionne bien. Ni trop, ni trop peu.
Deuxième syndrome, le produit Peter Pan, qui ne veut pas devenir grand
Ce dysfonctionnement possède des manifestations proches de la tour d’ivoire. En effet, il s’accompagne d’une pudeur excessive de l’équipe produit vis-à-vis de ce qu’elle construit. Cette pudeur entraîne un isolement vis-à-vis de l’utilisateur final, un isolement négatif pour tout le monde comme on l’a vu précédemment.
Cependant les causes sont un peu différentes. Il s’agit bien d’une forme de pudeur, d’une forme de sentiment que le produit n’est pas suffisamment finalisé, d’une forme de perfectionnisme. Souvent de telles équipes considèrent que le produit est en expérimentation de manière continue sans que jamais ces expérimentations doivent s’arrêter ou doivent être confrontées aux utilisateurs. En général ces équipes voudraient pouvoir développer à l’infini le produit et de nouvelles fonctionnalités. Éventuellement même en discutant avec les utilisateurs finaux.
En tout cas, le problème de ce dysfonctionnement est que la Delivery devient une fin en soi. Comme si après la Discovery, on démarrait une Delivery infinie. Cela rappelle un peu Peter Pan qui ne veut pas sortir de l’enfance. Pour tirer l’analogie avec le produit, la Delivery correspond à l’époque de l’enfance pour un individu. On y connaît ses premières expériences mais il faut en sortir à un moment pour prendre sa vie en main et vivre en autonomie. Le produit doit stabiliser à un moment son périmètre fonctionnel et être confronté de manière large à son marché. Pour voir s’il apporte de la valeur, s’il faut ré-itérer dessus ou faire des ajustements.
Cette ouverture sur le monde est effrayante pour les équipes qui présentent ce dysfonctionnement parce que ça leur fait prendre le risque d’avoir construit un produit pas efficace ou pas apprécié. Pour autant, c’est encore bien plus risqué de rester isolé sans vouloir faire passer son produit à une étape supérieure.
💡 Comment éviter le syndrome Peter Pan ?
Quelques idées :
Encore une fois ne pas faire de la Delivery une fin et mettre en place une démarche de Continuous Discovery (dont j’ai parlé ici)
Intégrer au plus tôt des early adopters ou beta utilisateurs afin de confronter notre travail à leur regard pour intégrer des feedbacks très vite
Viser de déployer une version commercialisable et payante le plus vite possible afin de forcer une vraie confrontation entre notre produit et la volonté du marché de l’utiliser
Pour les différents dysfonctionnements mis en avant ci-dessus, je me suis largement inspiré de ces antipatterns mis en avant par ProductBoard. Allez y faire un tour si vous voulez creuser 😃.
Conclusion
Merci de m’avoir suivi dans cette enquête autour de la Delivery. J’espère que ça t’a été utile. On se retrouve la semaine prochaine 🙏
Si tu es trop impatient pour attendre, tu peux :
Me contacter pour échanger sur le sujet par mail ou par message LinkedIn 💪
Me retrouver sur Instagram
Partager la newsletter à des personnes susceptibles d'être intéressées 💪
Bon courage pour la semaine 😃
Victor