Six schémas pour expliquer les concepts de gestion des produits



Quelques images utiles pour comprendre et expliquer les idées clés de la gestion des produits


Ils disent qu'une image vaut mille mots, mais pour être honnête, je pense que c'est même un euphémisme: la visualisation aide à assurer une compréhension commune de l'idée, à simplifier la communication et à éliminer la plupart des nuances inhérentes au langage écrit et parlé.

Je voudrais vous montrer six schémas que j'utilise souvent lorsque je discute des idées liées à la gestion des produits. Ils sont bien reçus par le public et transmettent parfaitement l'essence. Ces régimes sont les suivants:

  • «Product Manager as a Bottleneck».
  • "Entonnoir de livraison des produits."
  • "La cascade classique de l'impasse - Agile."
  • «Taille de l'initiative, risque et implication du leadership.»
  • "Des bunkers de connaissances."
  • L'importance de la segmentation.

Vous pouvez les utiliser dans votre travail comme vous le souhaitez.

Traduit en Alconost

«Le chef de produit comme goulot d'étranglement»


L'une des erreurs les plus courantes que je remarque avec les chefs de produit est le désir de participer à toutes les discussions. Oui, c'est la bonne intention: il faut tout comprendre pour pouvoir répondre à toute question sur le produit.

Malheureusement, cette approche présente de nombreux inconvénients. Tout d'abord, cela n'est pas pratique: vous serez rapidement surchargé d'informations, ce qui affectera non seulement l'efficacité de l'équipe, mais également votre bien-être. Croyez-moi, j'ai vécu cela par moi-même. Deuxièmement, vous détruisez ainsi l'autonomie de l'équipe.

Un bon chef de produit sait quand intervenir et quand il vaut mieux se retirer - ils parleront et le découvriront par eux-mêmes. La création d'une équipe autonome a pour objectif d'éliminer autant de dépendances que possible.

Considérez l'exemple dans l'image ci-dessous. Imaginez la situation de gauche lorsqu'un développeur Web demande quel algorithme de suivi mettre en œuvre et que le chef de produit se tourne vers les analystes qui disent que vous devez vous en tenir à l'implémentation iOS. Ensuite, le gestionnaire va au développeur iOS, reçoit les informations nécessaires, puis revient au développeur Web et lui explique tout. Cette approche ajoute non seulement du travail supplémentaire au chef de produit, mais retarde également la résolution du problème.

Comparez cela à l'exemple de droite: le développeur Web s'adresse directement à l'analyste (qui explique ce qui est requis), puis au spécialiste iOS (qui fournit les informations nécessaires). Remarquez combien il y a moins d'interactions dans ce cas (flèches rouges).



Si nous développons notre exemple et ajoutons quelques flèches (vertes et bleues), cela sera beaucoup plus proche du nombre réel de problèmes résolus simultanément dans l'équipe. Le nombre d'interactions augmente rapidement et elles sont toutes liées au manager.



Comment appliquer le schéma. Si vous êtes constamment surmené, demandez-vous si l'interaction au sein de l'équipe est ajustée de manière optimale: avez-vous vraiment besoin d' être à chaque réunion? Le travail normal se poursuit-il pendant vos vacances ou tout s'arrête-t-il? Si ce dernier est vrai, alors vous devez consciemment faire des efforts qui simplifieront l'interaction en votre absence.

«Entonnoir de livraison des produits»


C'est l'un de mes schémas préférés: il me permet d'expliquer le concept d'un entonnoir de productivité d'équipe en fonction de la taille des projets sur lesquels on travaille. Souvent, je dois faire face à la déception des partenaires commerciaux et des développeurs concernant le temps nécessaire pour que le produit entre sur le marché: il leur semble que le travail est trop lent.



Habituellement, ce problème est dû au fait que le travail n'est effectué que sur des tâches volumineuses (entonnoir à gauche). Par conséquent, une équipe ne peut faire qu'une seule chose à la fois. Cette approche peut être correcte si nous sommes sûrs qu'une certaine fonction sera certainement demandée - et c'est rare. Si quelque chose sort de la chaîne de montage (dans notre cas, de l'entonnoir) et se révèle inutile, à la fin, vous dépensez plus d'efforts pour comprendre cela que ce qui était nécessaire.

La raison pour laquelle, dans une approche flexible du développement, ils ont tendance à diviser le travail en fragments plus petits, c'est qu'il vous permet d'obtenir rapidement un résultat tangible et précieux pour l'entreprise, et avec moins de risques. L'entonnoir à droite donne beaucoup plus de marge de manœuvre: les tâches plus petites (points bleus) peuvent passer plus rapidement à travers l'entonnoir, ce qui signifie qu'elles seront testées plus rapidement en pratique. Si le résultat est réussi, vous pouvez investir plus d'efforts (cercle rose). Si le résultat n'est pas satisfaisant, nous passons à autre chose, mais nous limitons les ressources allouées. Chaque test en pratique vous permet d'augmenter les ressources investies. En conséquence, nous avons de nombreux petits projets, plusieurs moyens et très peu de grands. Ainsi, le risque est réduit et le retour sur investissement est augmenté.

Comment appliquer le schéma. Rappelez-vous sur quoi vous avez dû travailler ces derniers mois (y compris ce qui a été abandonné). Toutes les tâches étaient-elles de grande envergure et de complexité, ou s'agissait-il d'une combinaison de diverses tâches courantes (à la fois sur un sujet et sur des sujets différents)? Attribuez une taille à chaque tâche (par exemple, sur l'échelle S, M, L) et imaginez à quoi ressemblera l'entonnoir.

«La cascade classique - Agile»


Il existe de nombreux exemples sur Internet à ce sujet, mais je voudrais attirer l'attention sur les efforts déployés. De nombreuses entreprises alimentaires ne disent pas directement que le temps d'équipe est également un investissement. Si les chefs de produit avaient les rapports de profits et pertes de leur idée originale, ils verraient que les salaires sont souvent le poste de dépenses le plus important. Par conséquent, vous devez rechercher toutes les opportunités d'augmenter les bénéfices (retour sur investissement).

Lorsqu'une équipe donne du travail en gros morceaux, nous espérons obtenir un effet immédiat. Mais même si nous supposons que nous publions immédiatement la solution parfaite sans problèmes techniques (je vais vous dire un secret: c'est très peu probable), il s'avère que notre équipe (si vous regardez la chronologie) a fait de gros investissements qui n'ont pas fonctionné (graphique à gauche).

En libérant le produit plus souvent, en plus petites pièces, vous perdez votre travail progressivement - et cela commence à porter ses fruits immédiatement, car vous pouvez apprendre plus rapidement des erreurs et comprendre ce qui est nécessaire et ce qui ne l'est pas. Dans le deuxième graphique, la valeur d'un produit pour une entreprise est presque toujours supérieure au coût de l'effort dépensé - c'est ce que vous devez viser.



Comment appliquer le schéma. J'utilise souvent ces graphiques lorsque j'ai besoin d'expliquer pourquoi ajouter autre chose aux fonctionnalités du produit à l'itération actuelle n'est pas toujours dans notre intérêt. De plus, avec leur aide, il est pratique de vous rappeler, ainsi qu'à l'équipe, l'aspect commercial du problème.

«Taille de l'initiative, risque et implication du leadership»


Ce graphique reflète deux aspects. À gauche, la pyramide des initiatives. Son ampleur montre combien d'initiatives peuvent être travaillées simultanément: une base large - beaucoup, étroite - un peu. En même temps, les tâches avec un risque plus élevé sont en haut (il y en a peu) et avec un petit risque - en bas (il y en a plus).



À droite, un indicateur de la participation de la direction. Plus il est large, plus l'implication de la direction dans le travail est nécessaire ou attendue - c'est-à-dire qu'avec un nombre plus élevé de gestionnaires de rang supérieur, il est nécessaire de consulter. Plus l'indicateur est étroit, moins il est nécessaire de se référer aux "plus élevés".

Vous avez probablement beaucoup de petites tâches - comme vérifier des textes écrits ou des images dessinées: elles ont un risque très faible, les résultats peuvent être constamment optimisés. Ici, les dirigeants ne seront pas très intéressés à participer - et cela ne sert à rien. Mais les tâches au sommet de la pyramide auront un risque plus élevé (par exemple, ce pourrait être le lancement d'un produit complètement nouveau) - c'est là que la participation et le soutien de la direction seront nécessaires.

Comment appliquer le schéma. D'après mon expérience, ce schéma est un excellent outil pour les dirigeants et les équipes elles-mêmes: il explique pourquoi le leadership devrait être impliqué dans certains cas, et pourquoi cela ne devrait pas être fait dans d'autres.

Le sujet de la participation des managers au travail est assez compliqué. Je l'ai examiné plus en détail dans l'article Pourquoi «Spotify Model» ne résout pas tous les problèmes .

"Bunkers de connaissances"


Ce graphique est le résultat d'une vérification trimestrielle de la situation dans l'équipe où travaillait mon collègue. C'est un excellent moyen de visualiser l'impact de l'isolement des départements et des équipes par rapport au partage des connaissances. Il est impossible d'être à 100% compétent dans tous les domaines concernés par le produit, mais si vous vous rendez compte du manque de connaissances, cela vous aidera à vous concentrer sur la communication entre les services.

Un employé individuel connaît généralement bien ce sur quoi il travaille. Mais plus vous êtes loin des autres, moins ils sont conscients de «votre» sujet.



Comment appliquer le schéma. Rappelez-vous et rappelez aux autres que le travail dans l'organisation va nécessairement ralentir du fait que personne ne peut tout savoir et, plus important encore, s'il y a un conflit, l'une des raisons les plus probables sera le manque d'informations et non une intention malveillante ( voir l'article Malentendu, pas d'intention malveillante ).

L'importance de la segmentation


L'une des erreurs courantes que je rencontre lorsqu'une entreprise envisage des initiatives et des expériences est l'optimisation par des valeurs moyennes et non par segments. Mon exemple préféré est déformé par rapport à la perception moyenne: "En moyenne, une personne a moins de deux jambes."

Si les hypothèses et les zones de couverture deviennent trop étendues, elles limitent naturellement l'impact potentiel du test. En fait, vous essayez de satisfaire de nombreuses personnes en même temps - et cela ne fonctionnera probablement pas. Dans le diagramme ci-dessous, le plus courant est le troisième cas (à droite), dans lequel il n'y a pas de changements significatifs.

Voici trois expériences hypothétiques. Dans le premier, nous avons obtenu une augmentation, dans le second - une baisse, dans le troisième, il n'y a pas eu de changement. Cependant, souvent, si vous plongez dans les résultats, vous pouvez trouver de nouvelles opportunités potentielles ou des limitations. Dans le premier cas, bien que l'expérience dans son ensemble ait réussi, dans le segment B, vous pouvez voir une diminution des indicateurs - ici, il serait nécessaire de comprendre quelle était la raison de la détérioration et, éventuellement, de l'exclure lorsque le produit a été libéré.

Voyons maintenant le troisième cas. En général, il n'y a pas eu de changements significatifs, cependant, il y a des résultats positifs dans les segments B et C - et ils sont compensés par une baisse dans les segments A et D. Ainsi, ici, nous avons également reçu une direction qui peut être étudiée plus avant.



Comment appliquer le schéma. Essayez de formuler des hypothèses plus spécifiques et étudiez les résultats pour des possibilités et des limites supplémentaires. Au sujet des hypothèses et des expériences, je recommande fortement de lire quelque chose de Rick Hyam - consultez son Centre expérimental . Créez des archétypes grâce à la recherche d'utilisateurs et aux données démographiques ( Nikki Anderson ) - cela vous aidera à mieux comprendre le segment de consommateurs que vous ciblez.

Conclusion


C’est tout. J'espère que les diagrammes et diagrammes ci-dessus aident à visualiser certains concepts et à les expliquer aux autres!

À propos du traducteur

L'article a été traduit par Alconost.

Alconost localise des jeux , des applications et des sites dans 70 langues. Traducteurs en langue maternelle, tests linguistiques, plateforme cloud avec API, localisation continue, chefs de projet 24/7, tout format de ressources de chaîne.

Nous réalisons également des vidéos de publicité et de formation - pour les sites qui vendent, présentent des images, de la publicité, des formations, des teasers, des explicateurs, des bandes-annonces pour Google Play et l'App Store.

En savoir plus

Source: https://habr.com/ru/post/fr485176/


All Articles