On parle souvent de la relation UX/PM sans vraiment savoir où s’arrête la “responsabilité” de l’un et où commence celle de l’autre. Chez Digilityx, on nous pose souvent cette question, et je pense que l'approche de Marty Cagan (véritable légende du Produit) est celle qui, pour le moment, illustre le mieux la façon dont doit se positionner le Product Manager.
La responsabilité du PM dans le modèle traditionnel
Actuellement, on a tendance à limiter les rôles de chacun de la manière suivante:
- Le Product Manager imagine des features en se basant sur un problème business
- Le Designer rend la feature accessible et belle
- Les Développeurs codent le tout
Bien sûr, ces affirmations sont fausses : les organisations qui pensent qu'elles sont vraies ne sont pas des "organisations produits". Et pour cause : il n'est pas si simple de créer une organisation produit lorsque le produit n'est pas le coeur business. Chez Meta, Spotify, Netflix, le produit est le coeur business. Mais la plupart des organisations ont des produits qui viennent en support, ou en complément du coeur business : c'est là que la question de la mise en place d'une organisation produit peut parfois être difficile à résoudre.
L'entière responsabilité est mise sur le Product Manager dont la perspective n’est pas forcément challengée.
Hors, les meilleures idées que j’ai pu voir viennent souvent de la part des UX et des développeurs.
Les développeurs ne sont pas juste là pour matérialiser les idées du PM, ils sont là pour l’aider à créer une solution à un problème. Les designers ne sont pas là pour habiller les features et les rendre belles, ils sont là pour contribuer à trouver le bon problème et trouver les solutions qui y répondront le mieux, et ce avec le PM.
Feature team vs Product team
Dans une feature team (ou du moins la réalité que l'on observe dans les entreprises essayant d'en créer), le PM fait des requirements (ou des US), le Designer fait des wireframes, puis on englobe tout cela dans une méthodologie agile pour envoyer cela en développement.
Cela s'incarne via une roadmap, souvent décidée et priorisée par des stakeholders. Le job est donc de sortir une liste de features sur un temps donné, pour s'assurer que le PM produise de manière régulière. De plus, une roadmap guidée uniquement par le business ne s'assure pas de répondre aux besoins des utilisateurs.
Dans une product team (comme nous pouvons en trouver chez Doctolib, Blablacar, ManoMano), le job du PM est d’apporter les compétences MANQUANTES au Design et Développement. Cela prend souvent forme d'une connaissance à 360º de l'entreprise.
Le PM est au même niveau que les développeurs et les designers. Le triptyque PM/Designer/Développeur est chargé de résoudre des problèmes, qui peuvent être liés aux consommateurs comme à l'entreprise.
On cherche donc à trouver la combinaison des meilleures compétences pour résoudre ces problèmes.
La bonne question à vous poser : célébrez-vous le fait d'avoir mis quelque chose en production ou le fait d'avoir résolu un problème ?
Je vous laisse deviner la bonne réponse.
La vraie responsabilité du PM
Selon Cagan, dans son livre Inspired, le produit comporte 4 risques :
Utilisabilité : s'assurer que les utilisateurs comprennent comment fonctionne la solution et puissent l'utiliser
Faisabilité : s'assurer que la solution est faisable (techniquement et en terme de temps)
Valeur : s'assurer que les utilisateurs achèteront, utiliseront ou préfèreront le produit
Viabilité business : s'assurer que la solution apporte une vraie valeur ajoutée pour l'entreprise
Sur ces 4 risques, le Designer est responsable de l'utilisabilité, les Développeurs de la faisabilité et le PM de la viabilité et de la valeur utilisateur & business.
Le Product Manager se doit de connaître tous les aspects du business (marché, marketing, finance, supply…) afin de pouvoir aider les Designers à créer des fonctionnalités. Il les aide à naviguer à travers ces risques pour qu'ils puissent créer les fonctionnalités qui résoudront les bons problèmes!
Quelles sont donc les bonnes pratiques pour mettre en place une organisation produit dans son entreprise?
- Expérimenter : obtenir l'accord des stakeholders pour tester le mode produit sur une équipe, et voir comment répliquer cela à plus grande échelle si on démontre un succès.
Pour convaincre les stakeholders, identifiez ce qui les motivent et ce sur quoi ils sont jugés. Ensuite, travaillez votre storytelling. Racontez une histoire et soulignez bien la contribution du stakeholder dans l'initiative. Enfin, travaillez la notion de valeur en appuyant sur ce que ce nouveau mode de fonctionnement va apporter en termes d'efficacité. - S'assurer que l'on travaille bien sur des problèmes, pas une liste de features.
- S'assurer que l'on peut mesurer le succès : sur quels metrics se base t'on? Quelle est notre définition du succès?
- Devenir un expert des utilisateurs : assurez-vous de régulièrement échanger avec les utilisateurs
- S'améliorer sur la partie data : comprendre comment les utilisateurs utilisent le produit, comment il évolue. La data peut permettre de faire émerger des tendances ou comportements dont les utilisateurs ne sont pas conscients.
- Apprendre et comprendre toutes les parties de l'entreprise : comment elle fonctionne de bout en bout pour savoir ce que l'on peut améliorer. En repassant sur l'intégralité du processus de fonctionnement de l'entreprise et en étant complètement immergé avec les différentes équipes, vous serez à même de détecter ce qui est chronophage, ce qui relève de l'effort inutile ou ce qui peut être une perte financière.
- Savoir ce qui se passe sur le marché : comprendre si la solution est la plus avancée ou si d'autres ont déjà créé quelque chose de similaire. Le but n'est pas forcément d'être seul sur son marché, mais de mieux résoudre le problème que les autres.
Et vous? Dans quel type de fonctionnement vous trouvez-vous?
Échangeons autour d'un café : cedric.blanchard@digilityx.com
.avif)
