Le cycle de vie du produit : parcours d'une fonctionnalité de produit

Ceci est le quatrième article d'une série en cinq parties que j'écris dans le but d'aider un aspirant produit à entrer dans le monde de la gestion de produit.

Dans mon dernier article , j'ai décomposé la discipline de la gestion de produit en quatre parties dans le but d'aider les aspirants à la gestion de produit à comprendre leur trajectoire de carrière au sein d'une entreprise ou en général. Dans cet article, je parlerai du parcours de vie d'une fonctionnalité de produit, de l'idéation à l'abandon, pour aider un aspirant à la gestion de produit à avoir une perspective à 360 degrés sur ce qu'implique le rôle d'un chef de produit.

T-30 jours

On dit que la nécessité est la mère de l'invention. C'est littéralement le cas lorsqu'il s'agit de la naissance d'une fonctionnalité de produit. Tout commence par un certain niveau d'inconfort.
Certains employés de l'entreprise sont gênés dans la réalisation d'une de leurs tâches quotidiennes - peut-être que la base d'utilisateurs a augmenté et qu'il n'est pas en mesure de la gérer avec les anciens processus. Un cadre de l'entreprise consulte une feuille Excel et pense que l'entreprise perd trop d'argent à cause, par exemple, du nombre élevé d'annulations de produits. Ou peut-être qu'un concurrent a lancé une fonctionnalité de produit qui pousse les clients à quitter le produit de ladite société. Une personne examinant l'entonnoir de conversion marketing a remarqué des baisses importantes à un certain stade et a estimé que l'optimisation qui pourrait l'aider à atteindre son objectif trimestriel. Ou il peut s'agir de 100 raisons différentes, allant d'un nombre élevé de plaintes de clients pour un problème commun à une nouvelle fonctionnalité demandée par la majorité des utilisateurs interrogés la semaine précédente. Le fait est que tout commence par un certain niveau d'inconfort.

Désormais, ce malaise est porté à la connaissance du chef de produit ; ou peut-être que le chef de produit est celui qui le remarque en premier. C'est le point qui commence une chaîne d'événements qui pourraient conduire à la naissance d'une nouvelle fonctionnalité.

T – 25 jours

Il est temps pour le chef de produit de réfléchir à l'énoncé du problème. Il va parler aux clients ou aux intervenants internes qui ont signalé le malaise puis à ceux qui le vivent réellement ; le tout dans un seul but – s'assurer qu'il a identifié l'énoncé « racine » du problème. Si cette étape est prise à la légère ou que le chef de produit ne passe pas assez de temps dessus, alors les fonctionnalités du produit nées sont fragiles, déformées et finissent assez rapidement.
Une fois que le chef de produit a identifié l'énoncé du problème principal, il décide s'il vaut la peine de le résoudre. L'inconfort est-il vraiment important ou est-il un peu exagéré ou pire, simplement inventé ? Le résoudre ajouterait-il réellement une valeur significative au client et/ou à l'entreprise ? Le résoudre n'entraînerait-il pas une pénalité importante pour le client et/ou l'entreprise ? Existe-t-il un moyen de résoudre ce problème avec une modification mineure des processus ou par le biais de toute activité qui ne nécessite pas de modifications de produit - par exemple, changer de fournisseur, négocier un meilleur prix auprès d'un fournisseur existant, obtenir un logiciel tiers pour résoudre le problème, embaucher un employé supplémentaire, des changements de contenu, des graphiques, un bouton d'appel à l'action, etc. ?

Fondamentalement, s'il existe un moyen d'obtenir une valeur ajoutée similaire à partir d'une méthode qui n'implique pas de changements de produit, nous opterions pour cela plutôt que de changer quoi que ce soit dans le produit - que cela signifie ajouter ou supprimer. Une fois que le chef de produit est convaincu que la résolution de l'énoncé du problème apportera une valeur significative et qu'un changement de niveau de produit donnera beaucoup plus de retour sur investissement (en tenant compte du temps, de l'argent et de l'effort par rapport à la valeur) qu'un changement de niveau non lié au produit, les germes d'un nouveau caractéristique du produit sont plantés.

T – 15 jours

Si le chef de produit a une certaine expérience préalable, il peut proposer une solution basée sur cette expérience. Cependant, ce n'est peut-être pas la meilleure solution dans tous les cas.
Si l'énoncé du problème nécessite une solution hautement technique, le chef de produit en discute avec les développeurs et les responsables de l'ingénierie et prend leurs conseils sur la meilleure façon de s'y prendre. Si la solution nécessite des modifications au niveau de la conception, le responsable UX peut être consulté. Il se peut que le chef de produit et la personne UX organisent un sprint de conception et choisissent la solution qui est bien accueillie par les utilisateurs réels de cette fonctionnalité. Parfois, le problème est totalement lié à l'entreprise et nécessite donc l'adhésion de la haute direction.
Ainsi, il peut y avoir plusieurs façons de finaliser une solution. Mais une fois que c'est le cas, le chef de produit est chargé de convertir cette solution théorique en une fonctionnalité de produit active.

T = 0 (c'est-à-dire la naissance de la caractéristique du produit)

Lorsqu'une solution particulière est identifiée, le chef de produit, en collaboration avec l'équipe concernée, élabore une esquisse de base de la solution. Il peut inclure ou non un prototype de la solution. Parfois, il s'agit simplement d'une feuille Excel de base avec des conditions "si-alors" écrites pour savoir quand montrer un CTA particulier à un utilisateur, etc.
Le Product Manager met en mots la solution dans le PRD (Product Requirements Document) correspondant. Si la fonctionnalité est petite, il peut s'agir simplement d'un paragraphe dans un PRD existant pour une fonctionnalité plus importante. Parfois, la fonctionnalité est si énorme qu'elle nécessite un PRD complet juste pour la détailler correctement. Le PRD est piloté par les équipes concernées et le Product Manager s'assure qu'il existe un large consensus autour de la fonctionnalité.

T + 15 jours

Les petites fonctionnalités peuvent prendre moins d'une journée pour être gelées. Les grandes fonctionnalités prennent parfois plus de 30 jours pour obtenir le feu vert de tout le monde.
Prenons en moyenne 15 jours pour dire que c'est le moment où la fonctionnalité nouveau-né est présentée aux développeurs. Une conception appropriée et un transfert PRD ont lieu où les développeurs qui travaillent sur le projet sont informés des 5W (quoi, pourquoi, quand, où, qui) et des cas de test (comment la fonctionnalité doit se comporter ou non une fois qu'elle est publiée) .
Avec le responsable de l'ingénierie, un calendrier de publication approprié est décidé pour la fonctionnalité avec des délais pour la fin du développement, le début des tests, le moment où les bogues signalés seront corrigés et la date de sortie finale. Ensuite, toute la chronologie est divisée en sprints mesurables (généralement 15 jours). Une fois que les développeurs sont satisfaits, le développement commence.

T + 30 jours

Le sprint 1 se termine. Une partie de la fonctionnalité du produit est déployée. Ce n'est peut-être pas encore en contact avec les clients, mais la plupart des équipes suivent aujourd'hui les méthodologies Agile pour le développement de logiciels, ce qui signifie que nous construisons de manière incrémentielle et itérative. Ainsi, plutôt que de créer une grande fonctionnalité en 6 mois et de la publier en une seule fois, nous divisons le tout en parties indépendantes qui peuvent fonctionner par elles-mêmes (un tas de User Stories) et sont rapidement prêtes à être révisées et itérées.
Le chef de produit s'assure que le calendrier de publication est sur la bonne voie grâce à des réunions scrum quotidiennes et à des discussions avec le responsable de l'ingénierie concerné travaillant sur le projet. En cas de retard, les délais sont ajustés en conséquence, ou de petites parties des fonctionnalités sont supprimées pour s'assurer que la publication est à l'heure. Après chaque sprint, les progrès réalisés sont présentés au chef de produit et aux parties prenantes concernées lors d'une réunion, et après approbation, ils sont publiés.
Un an de programme de gestion de produits UpGrad

T + x jours

Après 'n' nombre de sprints, le développement est terminé et la fonctionnalité entière est sortie. Il n'est pas nécessaire que les clients n'utilisent la fonctionnalité qu'une fois complètement libérée. Ils pourraient l'utiliser depuis la sortie à la fin du sprint 1 lui-même. Chaque version ultérieure du cycle de sprint ne fait que rendre la fonctionnalité plus robuste et la rapproche de ce qu'elle est censée être.
Lancer une fonctionnalité est en soi un art et implique de nombreuses étapes que nous allons sauter et supposer simplement qu'après beaucoup de tambours et de coups de poitrine, il a été déclaré au monde qu'une fonctionnalité a été publiée. Cela peut être aussi complexe qu'un communiqué de presse complet avec le PDG lui-même parlant du nouveau lancement, ou cela peut simplement être quelque chose sur lequel un courrier est envoyé à un service particulier qui va utiliser la fonctionnalité et l'a probablement demandée dans la première place. Alors maintenant que la fonctionnalité est disponible, donnons un nom à cette fonctionnalité - M. Feature.

T + y jours

Même après la version finale, les choses tournent parfois mal. M. Feature, qui était autrefois tout brillant et précieux, pourrait ne plus être le même et il pourrait y avoir plusieurs raisons à cela. Cette phase du cycle d'un produit consiste à soutenir le produit. Un beau jour, une autre version a été publiée, ce qui a amené M. Feature à fonctionner de manière involontaire (c'est-à-dire devenir bogué) ou peut-être qu'une autre fonctionnalité a été supprimée qui avait des dépendances sur M. Feature et cela a provoqué le comportement bogué. Il se peut également que lorsque la fonctionnalité a été créée, nous ayons sous-estimé le nombre d'utilisateurs qui l'utiliseront ou n'avons pas planifié tous les cas d'utilisation et que la fonctionnalité ne soit plus en mesure de s'adapter à ces nombreux utilisateurs ou cas d'utilisation.

Ceci est soit signalé par l'équipe de test dans son examen périodique, soit signalé par un membre de l'équipe qui vient de le découvrir en utilisant lui-même la fonctionnalité. En cas de fonctionnalités destinées aux clients, ces plaintes peuvent provenir des clients réels du produit et être communiquées au chef de produit via l'équipe de l'expérience client.

Le chef de produit essaie de comprendre la cause première du bogue et, selon la priorité, planifie le correctif pour le prochain cycle de publication - il pourrait être ajouté dans le sprint en cours s'il est hautement prioritaire ou même dans les sprints suivants. Une fois le bogue corrigé et publié, M. Feature vit pour voir un autre jour, bien que sous une forme réformée - M. Feature 2.0 - grâce au chef de produit et à l'équipe d'ingénierie. Gloire!

T + z jours

On dit que toutes les bonnes choses ont une fin. Malheureusement, c'est aussi le cas avec Mr. Feature, quelle que soit sa version - peut-être Mr. Feature 9.263.75 ! Cela signifie que M. Feature a vécu une vie longue et heureuse, mais maintenant la fin de la route est là.
Cela peut être dû à diverses raisons. Une nouvelle fonctionnalité est apparue qui a rendu le besoin de M. Feature complètement redondant. Cela pourrait aussi être quelque chose d'extrême - comme la société a décidé que même si la fonctionnalité apportait une valeur ajoutée à ses utilisateurs, elle n'avait plus de sens économique pour eux.

Peu importe la raison, il est communiqué au chef de produit (ou c'est lui qui lance la discussion) que les services de M. Feature ne seront plus nécessaires. Maintenant, aussi déchirant que cela puisse paraître, le chef de produit a le devoir de mettre M. Feature au repos. Bien qu'avant cela, il doive s'assurer de certaines choses comme informer les utilisateurs qui utilisaient Mr. Feature qu'il ne sera pas disponible à partir d'une certaine date, la nouvelle fonctionnalité fonctionne bien avant de supprimer Mr. Feature, pas d'autre le flux est affecté lorsque M. Feature est parti, et ainsi de suite.

Il est donc temps de dire RIP à M. Feature. Dans votre carrière en gestion de produits, vous devrez le faire plusieurs fois. Mais rappelez-vous, la fin d'une fonctionnalité est le début d'une autre et le cycle continue. Telle est la vie de la gestion des produits !

Étudiez les cours de gestion de produits en ligne dans les meilleures universités du monde. Gagnez des programmes de maîtrise, Executive PGP ou Advanced Certificate pour accélérer votre carrière.

Programme en vedette pour vous : programme de certification Design Thinking de Duke CE