EasyTech #13 - Devenir un PM exceptionnel
Mes enseignements issus de plusieurs années de théorie & pratique
Salut à toi,
Désolé pour le petit raté la semaine dernière. Je voulais prendre le temps de bien écrire cette édition de qui me tient à ❤️
Il y a 2 semaines j’ai animé un webinaire “Devenir un PM exceptionnel”. Aujourd’hui, j’aimerais te détailler un peu plus par écrit ce que je mets derrière tout ça.
Pour les plus pressés voici la partie synthétique.
→ La vidéo du replay est ici.
→ Les slides sont là :
C’est parti !
0 - Pourquoi cette question du “PM exceptionnel” ?
Exceptionnel, ça veut dire quoi ?
C’est important de s’épanouir dans sa vie perso mais également dans sa vie pro. Or dans ma vie pro, devenir PM m’a permis d’être très heureux et de beaucoup grandir.
Du coup, exceptionnel ne renvoie pas seulement pour moi à “performant”, ça va un peu plus loin. Ça renvoie au fait de réussir à disposer des éléments, des armes pour s’épanouir et trouver SA manière d’être PM.
La volonté de synthétiser beaucoup de théorie
Depuis plusieurs années je consomme beaucoup de contenus autour du Product Management : livres, articles, confs, podcast…
J’ai envie de créer quelque chose de cohérent, global et exhaustif. Pour résumer tout ça. Car je trouve ça dur quand on démarre de ne pas partir dans tous les sens avec la centaine de livres sur étagère.
L’importance de ne pas négliger la pratique
Je suis fan de théorie mais aussi hyper conscient de l’importance de la mise en pratique. De bien comprendre les activités à réaliser. De bien voir les points d’attention.
J’ai essayé au max d’être très concret là dessus. De bien rentrer dans le détail des choses. Par la suite, je vais développer tout ça encore plus. Et je veux absolument donner des exemples concrets, de la vraie vie pour rendre ça plus clair.
Apporter une petite pierre à l’édifice
Comme je le disais, j’ai beaucoup progressé grâce à tout ce que cet écosystème m’a apporté. Du coup, ce travail, c’est aussi une opportunité de “give-back”, d’apporter ma modeste contribution à l’édifice de tous ces contenus produits sur la tech et le produit.
1 - Les bases du Product Management
Définitions
Le produit
Un produit c’est quelque chose qui apporte de la valeur en résolvant un problème ou en réalisant un désir ou en permettant d’adresser une opportunité.
Par exemple, l’application Uber m’apporte de la valeur en me permettant de rentrer chez moi quand il est tard, qu’il n’y a plus de métro et qu’il n’y a pas de taxis.
En général, j’ai un focus plutôt orienté “informatique” avec produit = logiciel. Pour autant, une très large majorité des principes s’appliquent au hardware ou à des produits physiques.
Le Product Management
Le Product Management c’est un ensemble de méthodes, d’outils et un état d’esprit pour créer des produits de qualité.
En général on résume ça en disant que le Product Management est à l’intersection de 3 mondes :
→ Le monde de la tech, celui des ingénieurs qui écrivent des lignes de code et qui s’assurent que le produit est bien conçu techniquement.
→ Le monde de l’UX, celui des designers qui s’assurent que le produit est facile et agréable à l’utiliser, pour que l’utilisateur ait une expérience agréable.
→ Le monde du business, qui comprend à la fois la partie finance (= est-ce que le produit est rentable ?) mais aussi la partie juridique (= est-ce que le produit est légal ?).
Les RH du PM
Quelle formation ?
De mon expérience, il n’y a pas vraiment 1 formation qui fonctionne mieux que les autres. J’ai vu d’excellents PMs issus tous de formations très diverses.
→ Des formations spécialisées en Product Management se développent, soit dans des écoles d’ingénieur, soit avec des bootcamps plus “professionnalisants”.
→ Des formations classiques comme les écoles d’ingénieur ou les écoles de commerce fonctionnent également hyper bien. Les ingés ont une bonne compréhension tech et les alumni d’écoles de co ont une bonne compréhension business.
→ Des formations plus spécialisées par exemple dans les sciences humaines ou dans le droit, permettent aussi d’avoir de supers PMs
→ Des parcours plus atypiques comme des auto-didactes ou des reconversions, anciens développeurs, anciens UX designers, anciens sales…
Bref tout marche 😃
Quelles compétences ?
Classiquement, je distingue ça entre les soft et les hard skills.
→ Les Soft Skills
Il s’agit de compétences relationnelles. Qu’on va souvent plutôt apprendre “sur le tas”. Pour moi, les soft skills du PM sont :
(1) la communication,
(2) l’empathie
(3) l’organisation (càd capacité à organiser son temps, ses journées)
→ Les Hard Skills
Il s’agit de compétences plus théoriques. On peut souvent davantage les apprendre dans les livres. Le PM a l’embarras du choix sur les compétences à développer. Pour simplifier, je pense qu’il faut se calquer sur la définition du Product Management entre tech, business et UX.
Donc ça donne en termes de hard skills :
(1) UX design ;
(2) tech niveau code, architecture, DevOps ;
(3) tech niveau organisation du delivery, agilité ;
(4) business (finance et marketing / growth).
Quelles activités ?
Dans la vie de tous les jours, un PM fait plein de trucs. Il faut souvent jongler entre différentes tâches (d’où le besoin d’être fort en organisation).
Pour moi, il y a 3 principales activités :
→ L’amélioration du produit
C’est le travail que tu fais avec les dévs, à regarder le produit, à le tester et à améliorer les moindres recoins. Les réflexions autour de comment le rendre plus efficace et plus agréables.
C’est le coeur du job du PM.
→ La réflexion stratégique
On a aussi besoin de prendre un peu de recul de temps en temps. De se demander où est-ce qu’on veut être dans 3, 6, 12 mois voire 3 ans ? C’est bien de prendre quelques minutes voire heures régulièrement pour se demander ça.
Une stratégie produit, ça vit dans le temps.
→ La communication
Un PM c’est un gros communicant. Il va inlassablement présenter son produit, présenter les dernières avancées et les prochaines étapes ! L’objectif, récupérer des soutiens.
J’aime bien distinguer :
la communication horizontale = pour toucher de nouveaux utilisateurs principalement ;
la communication verticale = pour donner de la visibilité aux sponsors, ou en trouver de nouveaux.
Comment se distinguer en tant que PM ?
On a vu le b.a.-ba du PM. Mais qu’est-ce qui permet à un PM de se distinguer ? Qu’est-ce qui fait que tu passes du ventre mou du peloton aux meilleurs de la course ? Bref comment être dans le top 1% ?
J’identifie 5 éléments :
→ Le Leadership
Attention leader ≠ manager. Mais l’impact d’un PM dépend beaucoup de sa capacité d’influence. Auprès des gens de son écosystème. Ça demande du leadership. Surtout car un PM n’a souvent pas d’équipe qu’il manage. Il faut qu’il convainque d’autres personnes.
→ Curiosité sans fin
Sur tous les sujets. Les sujets “métier”, de ses utilisateurs. Les sujets “tech”, en général : nouvelles technologies, nouvelles méthodes, nouvelles tendances.
→ Machine à simplifier
Ça renvoie à la qualité de la comm’ du PM. Il faut dire des choses simples et claires. Qu’il s’agisse de sujets techniques, métier ou juste de présenter un problème d’une manière limpide pour mener à une décision éclairée.
→ Gestion de la pression
Attention, ici il ne s’agit pas de dire que le PM doit être une machine à délivrer comme un dingue sous pression.
Je dirais plutôt qu’il faut qu’il soit capable de créer un environnement sain. Dans lequel il sait doser entre :
(1) les choses qui dépendent de lui et sur lesquel il peut agir ;
(2) les choses qui ne dépendent pas de lui et sur lesquels il doit activer d’autres personnes.
→ Artisan du Product Management
Dans tout excellent PM, il y a un côté “artisan”.
Comme un artisan, le PM cherche inlassablement de meilleurs outils pour faire son job. Comme un artisan, le PM cherche à théoriser du mieux qu’il peut sa science pour faire avancer la cause. Comme un artisan, le PM ne prend rien pour acquis et tente d’aller plus loin, de progresser toujours plus.
Les briques indispensables
Brique 1 : le Design Thinking
Le Design Thinking est une discipline pour t’aider à identifier rapidement et efficacement des solutions innovantes à des problèmes.
Elle se compose de 2 phases. La première est focalisée sur l’identification du problème. La seconde est focalisée sur la définition de la solution.
J’ai détaillé tout ça dans ma newsletter EasyTech #10 sur Le Design Thinking.
Brique 2 : l’agile
En quelques mots, l’agile te permet de délivrer des produits informatiques de qualité. À la fois en apportant de la valeur aux utilisateurs finaux. À la fois en t’assurant que la conception technique soit d’un niveau suffisant.
J’ai détaillé tout ça dans ma newsletter EasyTech #8 sur Les Bases de l’Agile.
Brique 3 : le cycle de vie du produit
Pour moi c’est extrêmement structurant de bien comprendre les différentes étapes de la vie d’un produit. D’où ma volonté aussi de bien définir le cycle de vie du produit.
Ça a l’air linéaire mais il y a évidemment des aller-retours. En revanche, je pense que certaines activités ou actions sont bien plus efficaces lorsqu’on se trouve à un moment et pas à un autre.
2 - Le cadrage / framing
Objectif
Quand on démarre, on a envie de partir à mille à l’heure ! C’est top. Mais ça vaut le coup de se poser un petit peu pour définir grosso modo, où on va, comment on y va, quelle est l’énergie qu’on veut y mettre.
On perd un peu de temps pour en gagner beaucoup par la suite.
C’est l’objectif du framing / cadrage : cadrer nos efforts pour qu’ils soient focalisés au bon endroit.
Activités
Définir son why
À ce stade, les idées produits qu’on peut avoir ne sont pas claires. D’ailleurs en symétrique, le problème précis de nos utilisateurs ne l’est pas non plus.
En revanche, ce qui doit commencer à être clair à ce stade, c’est notre vision. Pourquoi on veut faire ça ? Qu’est-ce qui nous tire, nous inspire et nous motive à faire ce qu’on fait ?
J’ai détaillé tout ça dans ma newsletter EasyTech #7 sur Trouver son Why.
Faire des premiers entretiens
Les entretiens utilisateurs sont une activité clé tout au long de la vie du produit.
À ce stade on est encore sur des échanges très exploratoires. Pas de solutions à proposer. Le problème qu’on veut résoudre n’est pas hyper précis. On veut identifier des opportunités et des grands types de problèmes.
On va commencer à apprendre dès ce stade de nos futurs clients / utilisateurs.
Souvent on se dit “c’est trop tôt, je vais ennuyer les utilisateurs” : dites-vous bien que ça vous permet d’avoir des premiers feedbacks.
Si vous échangez sur les grandes lignes de ce que vous avez envie de faire, et qu’on vous répond que ça n’a aucun intérêt.
Alors peut-être qu’il faut réfléchir à autre chose. Plus tôt on s’en rend compte, mieux c’est.
Cartographier son écosystème
Il ne faut pas être obsédé par la concurrence. On finit par imiter ce que font les autres plutôt que de développer ce qui fait sens pour nous.
En revanche, dans cette phase amont, c’est intéressant de regarder ce qui se fait ailleurs :
→ 1 Pour savoir où on met les pieds : notre approche ne sera pas la même si l’industrie / secteur qu’on vise a déjà beaucoup de solutions qui existent ou si c’est un marché beaucoup plus nouveau.
→ 2 Pour voir en quoi on se différencie : quel est notre positionnement ? Par quels aspects veut-on être reconnu par nos utilisateurs, et pourquoi ils nous achèteraient nous et pas les autres ?
Comment faire ? 🤔
→ Premièrement il faut chercher, passer du temps sur Internet, en parler à des gens. L’idée n’est pas d’avoir un panorama exhaustif, mais plutôt d’avoir une bonne idée de ses concurrents, des gros leaders inspirants de ce monde.
→ Deuxièmement, on réfléchit aux axes par rapport auxquels on veut se différencier d’eux. Par exemple, si je lance une application d’ecommerce, comment je me différencie d’Amazon ? Plus rapide, difficile… plus spécialisé, possible.
Livrables
(Tous les livrables sont dans les slides, je ne peux pas tous les faire apparaître car sinon ça ne sera plus lisible en un seul mail.)
Le benchmark de l’écosystème
Et oui, c’est à la fois très puissant comme activité, mais également comme livrable final. Ça nous permet de visualiser notre écosystème et là où on veut apporter de la valeur et être différent.
Le communiqué de presse
C’est une activité assez atypique. Ça consiste à imaginer le communiqué de presse qu’on voudrait qu’on écrive sur nous le jour où on sortira vraiment notre produit ! Évidemment c’est prématuré à ce stade, le produit n’existe pas.
En revanche, se demander comment on a envie qu’on en parle, va beaucoup nous aider à identifier la valeur qu’on veut apporter aux utilisateurs.
La stratégie produit
Avec les entretiens exploratoires, le travail de recherche réalisé, le communiqué de presse… on peut commencer à définir une stratégie produit.
Globalement, cette stratégie se compose de trois grandes parties :
→ La vision du produit : quel est le changement qu’on veut apporter dans le monde ? Quelle est notre vision à 10 ans ?
→ Les enjeux internes du produit : quels sont nos utilisateurs cibles et quel est le problème qu’on veut résoudre ?
→ L’environnement business du produit : quels sont les compétiteurs ? Quelles sont les sources de revenu et charges anticipées ?
Ces questions peuvent paraître un peu prématurées. Mais elles sont pertinentes même à ce stade. Toutefois, évidemment, on va faire évoluer ces réponses dans le futur.
Pour passer à la suite, on veut une première traction marché
Livrable principal : un MVP
Pour finaliser cette phase de cadrage, on produit un MVP (Minimum Viable Product). Pour tester très rapidement notre idée auprès du marché, en donnant l’impression que notre produit est quasiment déjà prêt.
Attention, ce n’est pas pour être malhonnête ou envoyer du rêve sans qu’il n’y ait rien derrière.
Mais pour vérifier que notre idée est pertinente, le plus efficace, c’est de proposer à de potentiels clients / utilisateurs s’ils seraient intéressés pour regarder voire acheter notre produit.
Par exemple :
→ Payer une publicité Facebook, Instagram… sur laquelle on présente le produit et on évalue le taux de click - est-ce que les gens ont envie d’en savoir plus ?
→ Lancer une campagne de Crowdfunding, on va vraiment voir si les potentiels clients sont prêts à mettre de l’argent à ce stade, parce qu’ils croient en le produit. Avant même qu’il existe !
Comment mesurer cette traction marché 🤔 ?
L’idéal serait de :
→ D’abord définir l’expérience qu’on veut mener pour identifier cette traction (typiquement un des deux exemples ci-dessus)
→ Ensuite définir un seuil à partir duquel on considère qu’il y a une traction marché et que ça vaut le coup de continuer. Et surtout, un seuil en-dessous duquel il faut pivoter / persévérer et faire autre chose.
Par exemple récemment j’ai mesuré la traction marché sur mon produit AI Jiminy pour aider les créateurs de contenu à avoir plein d’idées de posts LinkedIn ! Mon MVP = un post LinkedIn avec un lien vers une page web sur laquelle laisser une adresse e-mail.
Mes seuils :
< 10-15 adresses mail, pas de traction marché.
Entre 50-100 adresses mail, traction marché.
> 100-200, alors c’est la folie 😂
Au final j’en ai eu à peu près 80-90 donc ça a validé ma traction marché.
Une fois qu’on a cette traction marché, on enchaîne avec la discovery 🙌
3 - La discovery
Objectif
Comme son nom l’indique, on est sur une phase de “Découverte”.
Pour trouver le bon problème.
Puis identifier une piste de solution pertinente à celui-ci.
J’ai détaillé tout ça dans ma newsletter EasyTech #10 sur le Design Thinking. Donc je vais me focaliser davantage sur l’esprit des activités / livrables sur lesquels on bosse pendant cette phase.
Problème - activités
Dans un premier temps, on va se focaliser sur la compréhension du problème de notre cible. Comme dit plus haut, problème, opportunité, désir…
L’objectif à ce stade, c’est vraiment de ne pas partir bille en tête sur une idée de produit, de solution, de logiciel qu’on va développer. Pour deux raisons :
→ 1 ça coûte cher
→ 2 on risque de faire qqch qui ne sert à rien
Les activités vont donc consister à bien comprendre l’ensemble des problèmes des utilisateurs.
Problème - livrables
Les livrables vont donc nous permettre de fixer nos idées sur les utilisateurs qui nous intéressent et leurs problématiques :
→ Les Persona nous permettent de décrire les types d’utilisateur. Ça nous permet regrouper un ensemble de pbs cohérents.
→ La cartographie du process suivi par ces utilisateurs nous permet d’identifier ce qu’il se passe aujourd’hui. les solutions existantes et les problèmes éventuels dans ce parcours
→ On double cette cartographie en général d’une “Experience Map”. Celle-ci rajoute un volet émotion. L’utilisateur effectue telle action, mais que ressent-il en le faisant ? Plus la frustration est élevée, plus l’opportunité est grande pour nous.
Solution - activités
Dans un second temps, on essaye de trouver les bonnes idées de solutions à mettre en place pour résoudre le problème identifié.
Encore comme avant, on essaye d’itérer très vite et de ne pas partir bille en tête sur une idée qu’on a eue. On essaye de diminuer au maximum le risque lié au développement de logiciels. Grosso modo, on a deux risques principaux :
→ Risque lié à l’ordinateur : la technique ne marche pas
→ Risque lié à l’humain : l’utilisateur n’aime pas
En prenant le temps de défricher les solutions possibles et de construire des prototypes pour valider les bonnes pistes. On limite ces risques.
Solution - livrables
Les livrables ont pour objectif de donner une image réaliste et fidèle de ce à quoi ressemblerait la solution en cible.
Il y en a 3 principaux :
→ Le processus cible, pendant du processus actuel sur la partie problème. On décrit la trajectoire qu’on voudrait que l’utilisateur suive dans un monde idéal avec notre produit. Ça nous permet de supprimer les pain points identifiés auparavant.
→ Le prototype, donc un produit “fake”, mais qui ressemble énormément au vrai produit. Il va nous aider à faire des test en condition réelle mais à moindre coût.
→ Une roadmap, c’est à dire une forme de planification / priorisation, pour avoir une idée de ce qui doit être développé au démarrage et de ce qui peut attendre. À ce stade, on ne détaille pas trop.
Pour passer à la suite, on veut un PSF (Problem Solution Fit)
Livrable principal : le fameux prototype identifié !
C’est important et très utile.
Ça va nous permettre d’itérer rapidement avec nos utilisateurs.
→ Est-ce qu’ils comprennent bien notre valeur ajoutée ?
→ Est-ce qu’ils arrivent à naviguer entre les écrans ?
→ Est-ce qu’il faut simplifier certains aspects ?
Au delà de ça, c’est aussi un super outil pour communiquer en interne et aligner tout le monde.
Comment mesurer le Problem Solution Fit ?
Pas de secret, on va faire des tests utilisateurs et organiser une session pour qu’ils testent le prototype.
→ 1 on définit des hypothèses vis à vis de l’utilisation de notre produit et de la satisfaction anticipée
→ 2 on recrute des utilisateurs auxquels le faire tester
→ 3 on observe et on mesure en quoi cela confirme ou infirme nos hypothèses
→ 4 on conclut = soit on avance, soit on pivote
Si on a un PSF, on peut commencer à développer et à écrire des lignes de code 💪
4 - La delivery
Objectif
Comme son nom l’indique, on est sur une phase de “Livraison”.
On a trouvé le bon problème et une piste pertinente de solution à celui-ci. On va donc pouvoir développer vraiment cette solution sous forme de lignes de code, d’un logiciel.
J’en ai longuement parlé dans l’édition EasyTech #8 Les Bases de l’Agile. Comme pour la Discovery, je vais me focaliser davantage sur l’esprit des activités / livrables sur lesquels on bosse pendant cette phase.
Activités
On va s’organiser en équipe pour construire petit à petit un logiciel qui soit le plus qualitatif possible.
Quand on parle de qualité on renvoie :
→ à la fois au fait qu’il apporte de la valeur
→ à la fois au fait qu’il fonctionne bien et qu’il ne présente pas de bugs
Dans ce genre d’approches, l’équipe décide de travailler sur un petit nombre de fonctionnalités, pour une période donnée. Par exemple, 3 jours, 1 semaine, 2 semaines… C’est souvent ce qu’on appelle des sprints.
Pendant cette période, ce sprint, on essaye de développer les petites fonctionnalités identifiées.
Découper le plus possible la quantité de fonctionnalités sur laquelle on travaille entraîne deux avantages :
→ Récupérer très vite le feedback de l’utilisateur
→ Modulariser davantage les applications et rendre les composants plus autonomes
Livrables
En delivery, il y a deux grands types de livrables.
→ Premièrement, le MVP = du code et des “trucs technique”.
Quand on parle de code / trucs techniques, ça peut renvoyer au code qui définit la base de données, au code qui définit l’interface mais aussi le code qui permet de tester automatiquement des fonctionnalités… ou le code qui permet d’installer les environnements.
J’aime bien parler également de MVP à ce stade, lorsque tout ce code écrit donne un ensemble cohérent au niveau fonctionnel.
💡 Il y a deux MVPs ? 🤔
Oui ! En tout cas, c’est comme ça que j’aime présenter les choses.
Le premier en phase de cadrage. On l’a vu plus haut est le MVP de l’approche Lean Start Up.
Le second en phase de delivery, maintenant, est souvent appelé MMP (minimum marketable product) ou MLP (minimum lovable product). J’aime bien garder la notion de MVP personnellement. On veut avoir le produit avec un nombre de fonctionnalités minimal pour être commercialisé et adresser notre marché. Sans aller trop loin.
→ Deuxièmement, la documentation autour de ce MVP produit.
Ça renvoie à tous les documents qui ne sont pas du code, mais qui vont avoir leur importance.
Par exemple, le prototype qu’on continue à faire évoluer, les transcripts des entretiens avec les utilisateurs qu’on continue à réaliser, la stratégie produit, le communiqué de presse.
Pour passer à la suite, on veut atteindre notre PMF (Product Market Fit)
C’est quoi le PMF ?
Le Product Market Fit traduit le fait qu’on a un produit suffisamment abouti pour adresser le marché qui m’intéresse.
Schématiquement :
→ Le produit, c’est une solution à un besoin
→ Le marché, c’est des gens qui ont un besoin
→ Le PMF, c’est quand la solution au besoin qu’on développe, correspond au besoin ressenti par le marché
Quand est-ce qu’on sait si on l’a ?
C’est compliqué à dire ! D’ailleurs je prévois de faire un épisode Easy Tech sur le sujet !
Mais on identifie souvent de trois types de signaux faibles :
→ Un produit dont la proposition de valeur est comprise
→ Un produit dont la valeur ajoutée est directement perçue par les utilisateurs
→ Un produit dont les gens ont envie de parler autour d’eux
Post-PMF, on arrête la delivery ?
Évidemment non ! On va voir qu’on passe ensuite en phase de Growth. Ou globalement, comme on voit que notre produit fonctionne bien, on va pouvoir l’étendre beaucoup beaucoup plus. Et faire plein de comm’ autour !
Néanmoins on va continuer à faire évoluer le produit et à rajouter des fonctionnalités. Parce qu’il reste un MVP, un produit minimal ! Et on veut aller plus loin que ça.
Mais ce qui est sûr, c’est que lorsqu’on a trouvé son PMF, il ne reste plus qu’à exécuter (et à ne pas le perdre), donc on a généralement moins de pression.
On a bien avancé, on a notre PMF, on va rentrer en phase de growth 😍
5 - Le growth
Objectif
Vendre le produit et étendre sa base d’utilisateurs. Tout simplement. On a vu qu’on avait un produit top. Il ne reste plus qu’à trouver les bonnes personnes qui vont être intéressées par lui.
Et on va souvent aller plus loin en essayant de trouver des nouveaux relais de croissance.
Par exemple :
→ Rajouter des fonctionnalités pour toucher plus d’utilisateurs, par exemple Uber a fait ça en rajoutant d’autres offres comme UberX, UberPool etc… pour s’étendre au-delà du marché historique
→ Aller chercher de nouveaux marchés, par exemple c’est ce que fait Uber lorsqu’il s’attaque à un nouveau pays ou à une nouvelle ville
Activités
Modéliser et stimuler la croissance
On va utiliser pour ça le modèle AARRR.
💡 Le funnel AARRR
Acquisition : j’entends parler du produit
Activation : je vois ce qu’il peut m’apporter
Rétention : je l’utilise souvent
Referral / Recommandation : j’en parle
Revenu : je suis prêt à payer pour l’utiliser
Grâce à ce modèle, on va mieux comprendre comment notre activité croît au niveau économique. On va ensuite pouvoir se focaliser sur des aspects spécifiques de cette croissance en fonction de ce qu’on fait bien ou moins bien.
Définir sa North Star
De manière symétrique à l’utilisation du modèle AARRR. On va également définir sa “North Star” qui va nous permettre d’identifier comment on délivre de la valeur, et de prioriser nos actions les plus importantes.
J’en ai parlé en détail dans cette édition EasyTech #6 sur Mesurer le Succès de son Produit.
💡 Quel lien entre l’AARRR et la North Star Metric ?
Ils sont complémentaires avec quelques mini différences.
AARRR va te permettre de faire plus de croissance, de gagner plus d’utilisateurs et plus d’argent.
La NSM est liée à la valeur que tu apportes à chacun de tes utilisateurs. Plus tu apportes de valeur, plus ça va être facile de les activer (A), plus tu vas les garder longtemps (R), plus tu vas pouvoir les faire payer (R), plus ils vont en parler autour d’eux.
Donc,
Différence 1 : la NSM ne permet pas de stimuler directement l’Acquisition.
Différence 2 : la NSM va plus loin qu’une vision économique.
Mais ça reste très proche
Utiliser le branding
💡 Qu’est-ce que c’est le branding ? 🤔
C’est ce qui fait qu’on se rappelle de toi. Au delà du produit que tu vends.
Par exemple quand on pense à Apple, on pense à l’esthétique du produit, au marketing imagé, à leur finition toujours nickel chrome qui renvoie à une image de luxe et d’excellence. On ne pense pas juste à un produit comme un iPhone ou un Mac.
C’est le branding.
C’est pertinent d’utiliser le Branding pour se créer un univers de marque ! Derrière lequel les utilisateurs vont se retrouver.
Pour se lancer là dedans, c’est pertinent de définir sa MVB (Minimum Viable Brand) - désolé encore un acronyme :
→ Les valeurs
Ça peut être la simplicité, l’excellence, la performance… Il faut que ça soit précis mais pas trop ; différenciant sans l’être trop également.
→ Les ennemis
Contre quoi on se bat ? Quels sont nos concurrents ?
Par exemple, on peut dire que des néobanques Qonto essayent de lutter contre la complexité des systèmes bancaires traditionnels, c’est ça l’ennemi.
→ Les armes
Avec quoi on va se battre ? Qu’est-ce qui va nous permettre de gagner face à nos ennemis ?
Par exemple, une marque comme Yuka essaye de sensibiliser les consommateurs sur les choses qu’ils mangent ; leur arme c’est la transparence et la simplicité.
→ La tonalité
De quelle manière veut-on parler à nos utilisateurs / à notre audience ? Tutoiement, vouvoiement ? Consensuel ou clivant ?
→ L’apparence
À quoi on veut ressembler ? Quelles couleurs ? Quelle charte graphique ?
Ça peut paraître secondaire mais l’apparence a des racines très profondes et est en fait extrêmement interconnectée avec les autres aspects vus au-dessus.
C’est fini pour le cycle de vie du produit !
Maintenant, j’aimerais aborder un sujet central pour les Product Managers : organiser le Product Management. C’est à dire réussir à transformer les organisations pour qu’elles mettent en place le Product Management de manière durable.
6 - Organiser le Product Management
Préparer la transformation
1- Se demander pourquoi on le fait
Pourquoi on y va ?
Quel est le why pour notre transformation “Product Management” ?
En gros, on applique la méthodo produit à cette transformation.
Typiquement, veut-on aller plus vite ? Avoir des produits mieux faits ? Gagner plus d’argent ?
2- Trouver les bons appuis
Il faut ensuite préparer le terrain en identifiant les personnes qui vont soutenir la transformation en interne. Ils sont susceptibles de vous faciliter les choses et de convaincre d’autres personnes dans leur entourage proche.
Ça ne concerne pas que les chefs mais aussi les opérationnels.
En symétrique, il faut aussi repérer les personnes qui vont être très hostiles ou opposées à ce genre de transformation. Il faudra gérer de manière spécifique ces profils. Donc c’est très important de voir qui c’est en amont.
3- Identifier le point de départ
Par où on commence ?
Deux types de questions
→ Nouvelle application ou application pré-existante
Si je mets en place du Product Management sur une nouvelle application, a priori j’ai les coudées plus franches. Je vais être plus libre et ça va être plus facile.
En revanche, sur une application pré-existante, je vais pouvoir démontrer beaucoup plus d’impact, en résolvant des pain points concrets.
→ Transformation big bang ou projet pilote
Si je fais une transformation big bang, je mets en place le Product Management tout d’un coup dans l’organisation. Approche “top down”. Ça pique et ça peut être mal vécu. Mais une fois que c’est fait, c’est fait.
Avec un premier projet pilote sur lequel on va bosser, on va moins perturber l’orga et on va démontrer de la valeur rapidement. Mais ça peut mettre du temps pour transformer tout le monde.
Réaliser la transformation
1- Constituer une équipe motivée
Une fois qu’on s’est préparé et que la stratégie est claire. Il faut y aller, il faut exécuter.
La première équipe qui va travailler en mode Product Management sur un produit a une importance cruciale. Tout simplement, si l’équipe n’est pas assez motivée ou n’a pas les bonnes compétences, ça peut faire capoter tout le process.
Dans ce genre de démarrage, des prestataires peuvent aider pour récupérer les bonnes compétences, le bon volume de personnes au bon moment.
2- Se focaliser sur les early adopters
Derrière, il faut identifier ce qu’on appelle des “early adopters”. Ce sont les primo-utilisateurs, qui vont avoir envie de tester la nouvelle méthode.
Ce qu’on voit sur cette courbe, c’est que c’est plus simple de convaincre au début les personnes sur la gauche.
Donc il faut identifier les personnes motivées par le fait de mettre en place le Product Management, soit pour les prendre dans l’équipe, soit pour les mettre dans les boucles, pour aider la transfo.
3- Capitaliser sur les premières victoires
Une fois qu’on a démarré, il faut très rapidement mesurer l’impact et capitaliser dessus pour montrer au reste de l’organisation que ce qu’on fait n’est pas une chimère. Mais que ça marche bel et bien !
La chance qu’on a, c’est que souvent les premières phases de ce genre de transformations se passent bien. L’équipe est motivée comme on l’a vue donc elle va avoir de l’impact vite. Par ailleurs, la mise en place d’une méthodo génère aussi de l’impact parce que c’est souvent plus efficace que les démarches un peu “artisanales” et empiriques mises en place.
Pérenniser la transformation
Une fois que la transformation est bien engagée. Qu’on a pu capitaliser sur les premières victoires pour étendre petit à petit les personnes soutiennent cette transformation, ce n’est pas fini.
1- Mettre en place de l’amélioration continue
On va continuer à mesurer au fur et à mesure l’efficacité de notre transformation. Est-ce qu’on atteint bien les objectifs qu’on s’était fixés ? Si oui, peut-on aller plus loin ? Si non, peut-on mettre en place des actions en ce but ?
D’ailleurs, c’est pertinent de mettre les actions dans un “backlog” et de piloter leur mise en place dans le temps.
2- Rationaliser
Très vite, on risque d’avoir plusieurs cellules qui bossent sur du Product Management. Donc il faut synchroniser et rationaliser tout ça.
C’est là que les approches “Product Ops” sont pertinentes !
On va faciliter le travail des Product Managers en leur mettant sur étagère des outils, des bonnes pratiques…
3- Être conscient que ça ne finit jamais
Le Product Management ça ne finit jamais. On progresse toujours. Il faut rester en mouvement perpétuel et continuer à améliorer les choses petit à petit.
Ça peut sembler frustrant, mais une fois qu’on l’a accepté, on est 10 fois plus motivé.
Voilà ! C’est fini pour ce guide du PM exceptionnel. J’espère que ça t’a plu 😃
Conclusion
On se retrouve la semaine prochaine pour le prochain numéro !
Merci de m'avoir lu 🙏
Si tu es trop impatient pour attendre, tu peux :
Me contacter pour échanger sur ce qui fait qu’un PM est exceptionnel par mail ou par message LinkedIn 💪
M'envoyer des feedbacks sur ce numéro, positifs... ou négatifs bien sûr ! C'est comme ça qu'on progresse 💪
Partager la newsletter à des personnes susceptibles d'être intéressées 💪
Bon courage pour la semaine 😃
Victor
Super complet.
L'article est long mais se lit bien car il récapitule l'ensemble des phases de la vie d'un produit / entreprise.
Merci c'est un super pense bête pour tout PM.