Le jeu d’équilibriste entre Designer et Product Manager
Un peu de contexte
En septembre 2017, j’ai rejoint l’équipe LiveMentor en tant que Product Designer. LiveMentor est une école sur Internet pour les entrepreneurs, freelances et indépendants. Nous avons formé en ligne plus de 3500 élèves avec toujours le même objectif : les aider à réaliser leur projet.
Au menu, différentes formations en ligne très interactives comme :
- Comment se faire connaître sur Internet
- Comment réussir en freelance
- Comment créer son site internet en 3 semaines
- Facebook : de A à Z
Ayant suivi LiveMentor depuis ses débuts, j’ai rejoint l’aventure avec une énorme envie et la volonté d’aider sur tous les fronts. Avec Alexandre Dana, CEO et ami de longue date, nous avons établi une scorecard ambitieuse. En quelques mois, j’ai appris énormément, montant en compétences au milieu d’une équipe talentueuse, et découvrant de nouveaux métiers.
J’ai la chance de travailler avec une équipe de développeurs, qui bossent ensemble depuis longtemps et s’entendent super bien (nous recrutons d’autres développeurs Ruby d’ailleurs 👊)
J’espère éclairer une situation que connaissent beaucoup de designers en startup : les avantages et limites du rôle “couteau suisse”
Dans cet article, j’espère éclairer une situation que connaissent beaucoup de designers en startup : les avantages et limites du rôle “couteau suisse”. À mon arrivée chez LiveMentor, j’ai commencé à intervenir sur 3métiers :
- Le Product Manager : c’est celui qui a une vision transverse du produit. De ce fait, il est responsable de la roadmap à moyen / long terme, en fonction des objectifs business à atteindre. Il assure la coordination avec les autres équipes (ex : Marketing, Sales). Enfin il formalise des briefs macros pour le designer et les développeurs.
- Le Product Owner : issu de la méthode agile, il est responsable de la roadmap à court terme, et du travail quotidien de l’équipe de dev. Il est responsable des releases de son équipe.
- Le Designer UX / UI: celui qui conçoit la solution pouvant répondre au problème rencontré par l’utilisateur. Il affine sa solution avec les utilisateurs finaux. Il la construit avec les développeurs, et l’ajuste avec le PM.
Dans les faits, Product Manager et Product Owner est une distinction plutôt propre aux grands groupes. Ces deux rôles sont cumulés sur le PM dans la plupart des startups. Je vais me concentrer principalement ici sur le jeu d’équilibriste entre Designer et Product Manager.
Mais d’abord, revenons un peu en arrière, que je vous explique mon arrivée (inattendue) dans le monde du design.
2012 — La découverte du design
En 2012, j’étais étudiant en école de commerce.
Je pouvais prendre année de césure avec l’opportunité de faire deux stages de 6 mois — où l’on veut. Intuitivement j’étais attiré par le web. J’avais déjà fait 6 mois en Web Analyse chez Converteo. Mais je n’ai pas eu de coup de coeur pour les tableurs Excel 😅
Je commençais à sérieusement m’inquiéter sur mon avenir professionnel, sentant bien que la plupart des issues classiques à la sortie d’une école de commerce n’étaient pas pour moi.
J’ai donc décidé de trouver une startup à New York pour mon deuxième stage. Intéressé par l’univers de la santé, j’ai découvert ZocDoc. ZocDoc est le précurseur de Doctolib — dont la proposition de valeur est de permettre de trouver un professionel de santé en quelques clics.
Après un process de recrutement, impliquant une vidéo de motivation enregistrée dans la salle de bains de mon studio de l’époque et mentionnant les goûts du directeur RH de Zocdoc pour le guacamole, j’ai rejoint ZocDoc.
Nous sommes en janvier 2012, je débarque en plein Manhattan, avec les yeux qui brillent.
Si mon stage est officiellement en marketing, je découvre la possibilité de naviguer facilement entre les différentes équipes. Je me lie ainsi d’amitié avec les designers de ZocDoc. Très vite, ma curiosité me pique, et j’essaie de comprendre ce qu’ils font au quotidien.
Je me lie d’amitié avec le Visual Designer, qui réalise toute la journée des illustrations adorées par les visiteurs du site, mais aussi l’interface. Je participe avec le directeur UX à de nombreuses sessions de tests, découvrant un monde inconnu, où la parole de l’utilisateur compte plus que tout.
Surtout, je commence à y croire, à lutter contre mon syndrome de l’imposteur ! Il me semble possible de devenir designer, malgré mon parcours académique rempli de cours de comptabilité.
Je décide de me former dès mon retour à Paris.
Depuis 2012, une boulimie de design
Nealite
Je décide de rejoindre une agence spécialisée dans l’UX Design. L’UX qualifie l’expérience globale ressentie par l’utilisateur lors de son interaction avec un service.
Je me spécialise dans la compréhension des utilisateurs — via les tests d’interface, les entretiens in-situ, ou encore les observations terrain. Au contacts de designers confirmés, je découvre l’ergonomie web (Don’t Make Me Think a longtemps été ma bible), Axure, Sketch et les balbutiements de FramerJS.
J’apprends les bases de la Recherche Utilisateur avec le fantastique Grandin. Je fais mes armes d’UX auprès de Hugues, Julien. Je découvre le design d’ interaction avec Remy, et les subtilités de l’UI avec Clément et Anais.
Auchan:Direct
Après deux ans en agence, on me propose de rejoindre une startup au sein du groupe Auchan en tant que premier designer. J’accepte, ne sachant pas trop où je mets les pieds.. C’est une leçon que je transmets aux jeunes designers qui me contactent : n’ayez pas peur d’accepter des missions qui vous sortent de votre zone de confort, c’est la meilleure manière d’apprendre !
Chez Auchan:Direct, aux interviews et parcours de l’UX, je m’initie à l’UI. C’est la partie émergée de l’iceberg, l’interface graphique — la typographie, les couleurs, le style des boutons … tout en découvrant les notions de copywriting et d’univers de marque. Surtout, je collabore pour la première fois en direct avec des développeurs ! Je plonge dans le PM avec Laurent.
Je découvre l’importance de ce fameux design hand-off dont parlent nos amis américains : comment assurer au mieux la transition entre l’équipe design et l’équipe tech au sein de l’équipe Produit ? C’est un sujet que j’aborderai spécifiquement dans un autre article.
LiveMentor
À mon arrivée chez LiveMentor, je continue la découverte du monde du design avec un nouveau gros morceau : le rôle de Product Manager 🕵️
Pourquoi est-il difficile d’être à la fois Designer et Product Manager ?
À première vue, on pourrait imaginer que c’est super chouette d’être à la fois Designer et Product manager. Je peux choisir ce qu’on construit (PM), ensuite le concevoir (Designer), et puis demander aux développer de le construire.
“C’est génial, tu as les pleins pouvoirs !”
Oui, oui, c’est cela, oui.. 😅
En réalité, il est très difficile d’être à la fois Designer et Product manager car tout oppose ces deux métiers :
- Des objectifs différents : le Product Manager doit atteindre des objectifs business, en créant une une roadmap cohérente pour l’atteindre, et s’assure que la feature X est en production à la date Y. Il passe du temps sur les specs pour s’assurer que le problème que l’on adresse est le bon et a réellement un impact sur le business et les utilisateurs. Le rôle du Designer est de résoudre un problème précis dans ce cadre défini par le PM. Il cherche à comprendre au mieux les frustrations rencontrées par les utilisateurs.
- Des “clients” différents : le Product Manager rend des comptes aux autres membres de l’équipe sur l’avancée de la roadmap. Le Product Manager désire autant satisfaire l’équipe marketing, que l’équipe Opérations ou l’équipe Support. Alors que le Designer va naturellement avoir tendance à plus discuter avec les utilisateurs du site pour comprendre leurs frustrations, qu’avec les membres de son équipe ! Il intègre aussi les objectifs business mais passera parfois par le PM pour intégrer les besoins de son équipe.
- Des tempéraments différents : le Product Manager est par défaut un facilitateur qui doit chercher le consensus entre toutes les personnes de l’équipe et défendre une vision où “le mieux est le mortel ennemi du bien” ! Il doit aussi être capable de rebondir très vite d’un sujet à l’autre durant une conversation. Le Designer favorise davantage des phases de concentration forte, pour itérer sur ses designs. Sa productivité dépend de son niveau de concentration, et il aborde un problème à la fois.
- Des quotidiens différents : le Product Manager va passer sa journée à sur-communiquer avec tous les membres de l’équipe pour planifier et anticiper, ajuster. Le Designer va passer sa journée à se dédier à un problème, échanger principalement avec les développeurs de l’équipe Produit.
- Des outils différents : le Product Manager doit maîtriser l’utilisation de Trello, Asana ou Google Docs. Le Designer se passionne pour Sketch, Figma, InVision, Zeplin.
Un jeu d’équilibriste, n’est-ce pas ? 🙉
Un exemple de schizophrénie quand on mélange Design et PM
De manière très concrète, je me suis retrouvé dans des situations proches de la schizophrénie 😝
PM : Hello FX, la semaine prochaine on va améliorer l’expérience pour nos élèves en formation gratuite. Cela inclut le dashboard élève ainsi que tout le parcours pour prendre rendez-vous avec un responsable d’admission. Voici le brief.
Designer : Ok c’est parti, bon pour moi
Quelques jours passent, le design est prêt, on peut commencer à le coder.
PM : J’ai discuté avec Romain (notre lead Tech). Il a estimé la complexité pour intégrer le nouveau Dashboard. Ca nous rajoute quasi 3 jours, près de 40% de temps en plus. De ce fait, j’estime que le dashboard n’est pas indispensable en V1. On peut shipper juste le flow de réservation, c’est ce qui à le plus de valeur.
Designer : Tu veux dire que le dashboard élève, sur lequel j’ai passé … 4 jours, on n’intègre pas cette update dans la V1 ?
PM : Désolé mais ce n’est pas prioritaire en V1. On doit se poser la question : comment peut-on réduire au maximum la taille cette feature pour apporter un maximum de valeur en minimum de temps ? Dans le cas présent c’est en retirant le dashboard du périmètre de la release. On sortira le dashboard plus tard, si cela est encore pertinent.
Dans cette discussion, je suis le PM et le designer, vous voyez le tiraillement interne ? Le designer, quoi qu’on se le dise, tombe toujours (un peu) amoureux de ses designs, surtout quand il a passé du temps à polir cette interface. Pour autant, la valeur apportée à nos élèves en se restreignant uniquement au flow de réservation était supérieur car il y avait aussi une dimension business à prendre en compte. C’était donc une bonne décision de retirer le dashboard de la release, malgré le temps passé dessus 😢. Ce qui importe, ce n’est pas le temps passé sur un design, c’est la valeur réelle, au regard du temps à l’implémenter.
Designer et PM ont le même objectif : résoudre un problème
Attention à ce biais là, un designer peut avoir tendance à tomber à amoureux de sa solution. C’est problématique, on résoud un problème, on ne fait pas de l’art. Dans une création artistique, il n’y a pas nécessairement d’objectif, la création peut se suffir à elle même, et procurer une certaine émotion. Quand on design, ce qui importe c’est le problème, pas la solution, et c’est là que PM et Designer se rejoignent ✌
Love the problem, not the solution
Partager les deux rôles, chance ou tannée ?
Une chance dans une petite équipe 👊
Ne pensez pas que ma conclusion va être d’éviter à tout prix les situations où les fonctions Design et Product Management sont assurées par la même personne.
Au contraire. Je pense que ce jeu d’équilibriste fait grandir l’intéressé. En me baladant entre ces deux mondes, j’ai appris à estimer par exemple les besoins en temps de développement. Je pouvais avoir tendance à imaginer les interfaces les plus demandeuses d’interactions riches en Javascript. Je sais aujourd’hui penser différemment mes designs pour intégrer le niveau de complexité technique pour sa réalisation, et ainsi augmenter notre vélocité en tant qu’équipe Produit.
Enfin, ce type de situation fait évoluer naturellement toute l’équipe. Nous avons désormais adopté un mode de fonctionnement plus responsable chez LiveMentor, où les développeurs communiquent directement aux autres membres de l’équipe lors de la mise en production d’une releases par exemple.
Une évolution potentielle à long terme 🚀
Au fur et à mesure du développement de LiveMentor, nous ferons face à un produit certainement plus robuste, et potentiellement plus complexe. Il sera alors judicieux de distinguer le rôle de PM et de Designer. Il faudra être vigilant à ce moment de ne pas tomber dans une situation où les designers ne pensent qu’aux utilisateurs finaux et où les PM ne pensent qu’aux objectifs business. Savoir concilier satisfaction utilisateur et performance business 😌
Ressources
Si tu souhaites aller plus loin pour comprendre le rôle de PM :
- Maker’s Schedule, Manager’s Schedule de Paul Graham (merci Greg Jeanneau)
- Good Product Managers vs. Bad Product Manager de Ben Horowitz et David Weiden
- The Role of a Product Manager, un papier de Sillicon Valley Group, qui date un peu mais toujours très pertinent
- The BlackBox of Product Management, ancien PM chez Spotify
- Ruthless Prioritization, ancien PM chez Spotify
