La bible des product managers résumée

1. En avant
Guingamp
Inspired
Les 10 commandements de Marty Cagan

2. #1 – A&en)on à la
Discovery

3. Le Delivery, c’est cadré (ou presque)
→ Les bonnes pra,ques sont très iden,fiées,
théorisées… tests automa,ques / analy,cs /
releases en con,nu ⚙
→ 🤕 Même si on l’applique souvent mal, avec
des gros batchs de développement
→ Et du coup, on perd la no,on de MVP et de
pe,tes itéra,ons 🔄

4. Mais a?en@on à la Discovery
→ Même si le delivery roule sur des rouleEes… si
on n’apporte pas de valeur, c’est inu,le 😞
→ Mais découvrir la bonne solu,on, pour tous les
consommateurs / u,liasteurs, c’est dur 🥵
→ Pour ça :
1⃣‍ Iden,fier en amont les risques
2⃣‍ Définir et designer les produits progressivement
3⃣‍ Résoudre des problèmes > délivrer des features

5. #2 – les 4 risques à adresser
⚠
Valeur, U*lisabilité, Viabilité business,
Faisabilité technique

6. Les 4 risques…
→ ❤ Risque de valeur : pour ne pas développer
une solu,on à un problème inexistant
→ 📱 Risque d'u,lisabilité : pour expliquer
comment on résout le problème
→ 🛠 Risque de faisabilité technique : pour
sécuriser les bonnes technos / compétences
→ 💰 Risque de viabilité business : pour éviter
les obstacles business – réglementaires -
juridiques

7. … comment les évaluer ?
→ ❤ valeur : en allant voir les u,lisateurs et en
analysant leur comportement
→ 📱 u,lisabilité : avec des prototypes, et des
u,lisateurs qu’on observe
→ 🛠 faisabilité technique : en sollicitant les
équipes techniques pardi
→ 💰 viabilité business : en allant voir les
experts, market, finance, legal, sécu…

8. #3 – Analyse Quan)ta)ve
≠
Analyse Qualita)ve

9. Analyse quan@ en discovery
→ Ac,vités : A/B tes,ng, sondages, analyses sur
les données d’u,lisa,on du produit 🔢
→ U,lité : va permeEre de
1⃣‍ mieux comprendre l’u,lisateur
2⃣‍ mesurer les progrès du produit
3⃣‍ prouver que les idées marchent 💪
4⃣‍ objec,ver les décisions (data > opinion)
5⃣‍ inspirer le travail de l’équipe produit
(observa,on non biaisée)

10. Analyse quali en discovery
→ Ac,vités : entre,ens, tests d’u,lisabilité,
atelier collec,f… ☎
→ Mais aussi, demander « si l’u,lisateur est prêt
à acheter ? » 🤔 « s’il serait prêt à le montrer
à un ami » 👯‍‍
→ U,lité : pas pour valider (quan,) mais pour
apprendre rapidement, générer de l’empathie
et découvrir des insights 🔎

11. #4 – Scaler c’est difficile

12. Les étapes du Scale
→ 🐣Les start-ups : pe,te entreprise <25, besoin
d’être financièrement viable 💸 ; un
environnement stressant mais orga très agile
→ 🐥Les « growth » companies = scale-ups : a
connu des premiers succès 25 < . < 400
ingénieurs, bonne mo,va,on
→ 🐓Les entreprises classiques / grosses
structures, plus anciennes également

13. À chaque stade, ses challenges
→ 🐣Start-ups : trouver son Product Market Fit,
est-ce que des gens sont prêts à payer pour ce
que je propose ?
→ 🐥Scale-ups : comment garder notre efficacité
en grossissant sans perdre en alignement et
en adaptant le leadership ?
→ 🐓Grands groupes : comment générer de
l’innova,on en con,nu, sans être en mode
« vache à lait » / « too big to fail »

14. #5 – Le PM @ scale

15. L’évolu@on du leadership
→ Tous les leaders doivent évoluer avec le scale
de la boîte
🧐Côté PM : aligner tout le monde sur la vision
business
🎨Côté Design : assurer la cohérence du design
⚙Côté techno : contrôler la complexité à mesure
que la base de code grossit

16. Le rôle de Head of Product
→ Le plus haut rôle dans l’organisa,on produit
(parfois VP Product ou CPO)
→ Ce qu’il fait :
💪 Faire grandir les équipes
🔭 Partager la vision et la stratégie produit
🏭 Assurer que l’exécu,on ,ent la route
🤝Diffuser une culture produit

17. pause technique
Si ça vous plaît,
like/commentaire/partage❤
Pour me suivre :
Et ça
repart

18. #6 – Deux cours
incontournables pour tous
les PMs

19. Un cours de développement (1/2)
→ ⚠ Pas un cours de html, un cours sur un
« vrai langage de programma,on »
→ Pour comprendre la logique derrière le code
et le développement : pensée en hypothèse,
en boucle etc. 🤔
→ Pour développer plus d’empathie et bosser
plus efficacement avec les ingénieurs 🛠

20. Un cours de finance (2/2)
→ Parce que :
☺c’est bien un produit qui résout un problème,
😀c’est mieux un produit qui est bien conçu,
😆c’est encore mieux un produit qui se vend
→ 🪙Concrètement, il faut maîtriser les bases de
la finance appliqué à son produit, coût /
dépenses, coût d’acquisi,on, revenus par
u,lisateur, modèle de pricing…

21. #7 – Les bonnes pra8ques
pour des équipes produit
efficaces

22. La composi@on des équipes
→ La taille : pas trop grosse ! On doit pouvoir les
nourrir avec deux 🍕
→ Les compétences : le plus pluridisciplinaire 👐
possible, a minima PM + des ingénieurs
→ Le repor,ng : le PM n’est pas le manager de
l’équipe ⚠
→ Le scope : on peut découper par u,lisateur,
par device, par process ou en fonc,on de
l’archi 📐

23. L’environnement des équipes
→ 🏠La localisa,on : colocalisé, c’est plus efficace
→ 📆La durée de vie : + c’est stable, mieux c’est
→ 👦L’autonomie : par rapport aux autres équipes
et pour résoudre les problèmes
➡Pourquoi ça marche ?
1⃣‍ une meilleure rela,on dans les équipes,
2⃣‍ l’exper,se ,re l’innova,on
3⃣‍ focus outcome + ownership => ↗mo,va,on

24. #8 – La ges8on des
stakeholders
C’est presque fini

25. C’est qui ? Quel rôle pour le PM ?
→ 👑 Un stakeholder = quelqu’un qui a droit de
vie et de mort de véto sur ton produit. Par
exemple le business, le legal…
→ Les responsabilités du PM :
🧠 Comprendre les contraintes et les
préoccupa,ons des stakeholders
🔭 Assurer que tout le monde est bien aligné
dans la même (bonne) direc,on

26. Stratégies pour bien les gérer
→ Prérequis de leur côté : confiance, respect et
autonomie
→ 1⃣‍ Être un super PM 💪 (on s’en serait douté
ceci dit 😂)
→ 2⃣‍ Communiquer, beaucoup, avant, pendant
et après les releases 📣
→ 3⃣‍ Ne jamais tourner ça sur « c’est mon
opinion en tant que PM contre la vôtre » 🙊

27. #9– Des missionnaires
plutôt que des mercenaires
Avant-dernier
commandement

28. Missionnaires ≠ Mercenaires
→ 🕍 Missionnaires : les membres de l’équipe
sont ici pour résoudre des problèmes. Ils
croient en la vision du produit. Ils veulent
changer le monde et avoir un impact.
→ ⚔ Mercenaires : pas intéressés vraiment par
la réussite du produit, ou le fait qu’il délivre
de la valeur. Ici pour maximiser leur intérêt
individuel et pas celui de tout le monde.

29. Missionnaires > Mercenaires
→ ❤ On se bat pour ce en quoi on croit. Les
missionnaires feront toujours le maximum
pour le produit et l’u,lisateur.
→ 🫡 Les missionnaires seront plus
responsabilisés et ne se meEront pas juste en
posture d’exécutant.
→ 🧠 Les missionnaires auront une créa,vité
maximale et amèneront plein d’idées
innovantes pour améliorer le produit.

30. #10– L’importance de la
culture et de la
collabora8on
Dernier
commandement

31. Comment définir la culture ?
→ Pour Marty Cagan, on peut mesurer la culture
d’une orga produit sur deux dimensions :
🚂 Exécu,on <-> Delivery
🧠 Innova,on <-> Discovery
→ Exécu,on : pour délivrer des applica,ons de
qualité, bien conçues techniquement 📐
→ Innova,on : pour réussir à toujours trouver de
nouvelles idées tous ensemble 🤝

32. Pour 🚀 la dimension innova@on
→ 🧪 Encourager les expérimenta,ons
→ 💪 Responsabiliser / empower les équipes
→ 🪙 Pousser la maîtrise business
→ 👐 S,muler la diversité dans les équipes
→ 🏭 Industrialiser les techniques de discovery

33. Pour 🚀 la dimension exécu@on
→ 🤝 Diffusion de l’informa,on et collabora,on
→ 💪 Responsabiliser / empower les équipes
→ 🔎 Résultats et outcomes > features et output
→ ☎ MeEre dans la boucle les ingénieurs
→ 🥇 Reconnaître les succès

34. Si ça vous a plu,
like/commentaire/partage❤
Pour me suivre :