Les 5 meilleurs diagrammes utilisés pour expliquer les concepts de gestion de produit

Publié: 2020-02-27

Il y a beaucoup de choses dont les chefs de produit sont responsables et responsables. Un chef de produit est non seulement susceptible d'élaborer une stratégie en créant une feuille de route, mais doit également articuler le cycle de sortie d'un nouveau produit à l'équipe ainsi que tout ce qui se trouve entre les deux.

Ils sont également tenus d'avoir l'expertise nécessaire pour savoir comment identifier les tâches prioritaires et gérer l'équipe en conséquence. Non seulement cela, mais les chefs de produit mobiles ont également la responsabilité d'analyser les fonctionnalités ajoutées à un produit (application mobile) et si elles sont en phase avec les objectifs du client.

Dans l'ensemble, chaque processus, activité et décision associé à un produit est synchronisé et aligné par le chef de produit mobile. Ce qui aide ces chefs de produit à atteindre leurs KRA, c'est un certain ensemble de compétences .

Maintenant, évidemment, ils devront expliquer certaines idées de gestion de produit aux membres de leur équipe afin qu'ils soient tous sur la même longueur d'onde. Mais ce qu'il faut se demander, c'est comment expliquent-ils tous les concepts de gestion de produit et les idées clés ?

Eh bien, je pense que quelques diagrammes utiles pour les chefs de produit font l'affaire. Si vous souhaitez savoir quels sont ces diagrammes et comment et quand ils sont utilisés par les chefs de produit mobiles, tenez-vous-en à la fin.

Schéma 1 – Goulots d'étranglement de la communication

Il est entendu qu'en tant que gestionnaire, vous devez être conscient de ce qui se passe dans votre équipe et de la façon dont les membres de l'équipe gèrent leurs tâches. Mais, il est ridicule qu'une personne soit impliquée dans chaque communication et chaque décision – une personne ne peut pas gérer toutes les choses par elle-même, n'est-ce pas ? N'est-ce pas pour cela que la délégation a été inventée ?

Maintenant, il est naturel que vous vouliez être inclus dans toutes les conversations importantes inter/intra-équipe, mais vous devez réfléchir à une chose : est-ce nécessaire ? Est-ce quelque chose que vous devriez faire en mettant de côté vos autres responsabilités ?

La réponse est - analysez si l'équipe est capable de communiquer sans dépendre de vous. Et si c'est le cas, vous devez prendre des décisions conscientes pour vous assurer que des choses importantes comme une communication fluide ne dépendent pas uniquement de vous. Un diagramme qui peut efficacement expliquer le cas en question est donné ci-dessous.

Disons qu'un ingénieur Web doit discuter de quelque chose avec l'analyste produit, puis le PA dit qu'il doit discuter de quelque chose avec le développeur iOS à cet égard. Désormais, l'ingénieur Web devrait idéalement approcher directement le développeur PA et iOS, au lieu d'être dépendant du PM (comme le montre l'image de gauche).

Communication bottlenecks

Le diagramme de gauche montre la dépendance de l'équipe vis-à-vis du chef de produit pour communiquer avec les autres membres d'autres équipes, ce qui affecte négativement le flux de travail et le ralentit. Et à droite se trouve le diagramme affichant un flux de communication efficace qui n'est pas dépendant, éliminant instantanément les points de contact inutiles.

Diagramme 2 : cascade vs agile

Bien qu'il existe de nombreuses ressources sur Internet participant au débat sur l' approche Agile vs Waterfall , cela peut encore sembler être un concept vague par rapport à la gestion des produits. Dissipons donc le brouillard de l'ambiguïté.

Il est généralement connu que le coût de développement d'une application mobile est calculé sur la base des heures nécessaires pour développer ce produit.

Waterfall vs agile Diagram

Maintenant, si le chef de produit de cette société de développement d'applications mobiles choisit d'utiliser l'approche Waterfall (c'est-à-dire une version importante du produit), cela signifierait que le produit sera lancé en une seule fois.

Désormais, lorsqu'un produit est lancé, on s'attend à ce qu'il devienne un succès instantané - ce qui ne sera pas facile dans ce cas, car le produit est lancé en une seule fois et est certainement à l'origine de certains problèmes. La valeur qu'ils retireront de cette version ne sera pas équivalente à l'investissement (temps) fait par les développeurs. C'est parce qu'ils auraient besoin de résoudre les problèmes dès le départ.

Au contraire, l'approche agile prenant en charge de petites versions et itérations afficherait des résultats de valeur instantanés, puisque vous identifiez simultanément les erreurs et les corrigez. Le diagramme ci-dessus montre clairement la différence dans le résultat final du choix de ces approches de gestion de produit .

Schéma 3 : Représentation de la taille de livraison

Lorsqu'il s'agit de livrer un produit à temps, c'est une partie cruciale de l'ensemble du processus de développement . Il peut littéralement faire ou défaire l'avenir de n'importe quelle application mobile. Si le délai de mise sur le marché est trop long, une autre application pourrait capturer le marché et cela rendrait l'application mobile en question inutile.

Voici une représentation de la taille des initiatives prises lors du développement d'une application -

Representation of delivery size

Le diagramme de gauche montre le débit de la taille de livraison qui ne traite que du travail sur de gros projets (gros morceaux de travail en même temps). Il est absolument clair que travailler uniquement sur de gros projets d'un produit créerait un blocage à un moment donné dans le futur, puisque ces projets nécessiteraient plus de temps, d'attention, de ressources, etc. Et si quelque chose tourne mal, l'impact serait dévastateur sur l'ensemble du processus, augmentant inévitablement le time-to-market.

{Lire aussi notre article sur « Chefs de projet vs chefs de produit : Différence, rôles et défis »}

Le schéma de droite est un classique « à faire ». Les avantages de l'adoption de l'approche Agile se sont également répercutés sur cette étape du processus de gestion des produits . Cette approche préconise le mélange d'exécution de petites tâches avec de gros morceaux de travail (bleu), ce que nous suivons également chez Appinventiv.

Comme visible sur le diagramme, contrairement à celui de gauche, ici de petits morceaux de travail (Rose) peuvent facilement passer à travers l'entonnoir (peut être fait facilement). En cas de succès, les chefs de produit peuvent poursuivre cette idée (cercles jaunes) et investir à fond. Et si c'est le cas, ils peuvent recommencer et investir en conséquence.

{Découvrez cet article très détaillé sur "les 10 documents les plus importants que les chefs de produit doivent préparer "}

Diagramme 4 : Niveau d'implication de la direction

Le schéma ci-dessous comprend deux modèles d'élaboration de ce concept de gestion de produit . L'une de gauche affichant la taille de l'initiative, le nombre de tâches réalisées à la fois, et le facteur de risque dans celles-ci, et l'autre portant sur le niveau d'implication des chefs de produit (leadership) correspondant à ces tâches et initiatives.

Level of leadership involvement

Celui de gauche est une pyramide de tâches/initiatives à réaliser par l'équipe. Le bas de la pyramide signifie que de nombreuses tâches sont exécutées à la fois, et le diagramme de droite montre le degré d'implication par rapport à ces tâches subalternes présentant un risque faible à nul.

Au fur et à mesure que l'on se déplace vers le haut de la pyramide, le nombre de tâches diminue tandis que les risques associés à ces tâches augmentent également, c'est là que le chef de produit DOIT être consulté, alors que dans le formulaire il peut être simplement informé. Ce diagramme aiderait non seulement les responsables de produits mobiles, mais également les membres de l'équipe à savoir quand dépendre de la direction.

Diagramme 5 : Analyse de la valeur de segmentation

Il existe quelques pratiques que les organisations sont habituées à suivre. L'un d'eux étant l'habitude d'optimiser pour la moyenne au lieu d'un segment. Cela signifie qu'ils ont tendance à se concentrer sur la moyenne plutôt que sur des segments particuliers qui doivent être améliorés.

Dans les circonstances où les cibles et les hypothèses sont assez larges, il devient difficile pour les chefs de produit et les équipes de développement de créer un impact via le produit. C'est parce que vous essayez ici de satisfaire une variété d'objectifs en même temps, ce qui n'est pas du tout possible.

Les diagrammes, tels que ceux présentés ci-dessous, sont un moyen d'analyser chaque segment pour identifier ceux qui ont un impact sur les performances des autres. Tout cela pour résoudre les problèmes actuels.

Analyzing segmentation value

Le diagramme ci-dessus se compose de trois expériences hypothétiques 1, 2 et 3 avec les segments A, B, C et D. Sur trois expériences, dans le premier cas, il y a eu une élévation du segment A, suivie d'une diminution de la deuxième cas, et troisième sans changement.

D'un point de vue individuel, dans l'expérience 1, le segment A s'est bien comporté avec les autres, sauf le segment B. Or, le schéma a mis en évidence le déclin de ce segment juxtaposé aux autres. Cela pourrait aider les chefs de produit à trouver les raisons de ce qui se passe, ce qui finira par améliorer la moyenne à plus long terme.

Une situation similaire se produit dans l'expérience 3, où les segments A, C, D sous-performent dans le segment d'opposition B qui a montré un changement significatif. Encore une fois, une étude éclaircirait les raisons de ce qui se passe.

Ces diagrammes utiles pour les chefs de produit peuvent facilement être personnalisés en fonction de leurs besoins, quel que soit le secteur d'activité des chefs de produit. En ce qui concerne Appinventiv, je pense que ces modèles aident vraiment nos équipes à simplifier le processus et à maintenir une communication ouverte entre les /intra-équipes.

Questions fréquemment posées

1. Qu'est-ce qu'un cadre de gestion de produit ?

Tous les frameworks sont essentiellement des outils utilisés dans le cycle de vie de la gestion des produits . Ils sont utilisés à diverses fins, par exemple pour illustrer des idées et des concepts de gestion de produits et pour faciliter d'autres tâches.

2. Quel est le processus de gestion des produits ?

Le processus de gestion des produits se compose de différentes étapes. Cela comprend la gestion des idées, la feuille de route, l'ajout et la détermination des spécifications, la hiérarchisation, la livraison, l'analyse et les commentaires des utilisateurs.