Replay
AMA x Product Management 4 clés indispensables pour créer un produit qui compte — avec Eric Tholomé-20251202_170442-Enregistrement de la réunion(1).mp4
Dans un écosystème où tout va vite — idées, features, concurrents, attentes clients — le vrai défi n’est plus de construire un produit… mais de construire le bon produit.
Ask me anything exceptionnel avec Eric Tholomé, dirigeant tech reconnu et ancien Director of Product chez Google, qui vous partagera 25 ans d’expérience dans la création et le lancement de produits d’envergure internationale.
Comment prendre les meilleures décisions produit, éviter les pièges classiques et accélérer votre impact ? Rendez-vous le mardi 2 décembre à 17h en visio .
1. Ancrez chacune de vos décisions dans la valeur utilisateur
Un bon produit commence toujours par une question simple : « Quel besoin utilisateur cherche-t-on vraiment à adresser ? »
Quand vous prenez une décision, ayez toujours l’utilisateur en tête. Perdre de vue l’utilisateur, c’est probablement la mauvaise direction.
2. Mieux vaut répondre à un besoin existant que créer un besoin artificiel
Il est bien plus simple — et plus efficace — de s’attaquer à un besoin réel déjà exprimé.
Mais attention, la résistance au changement des utilisateurs est énorme. Il faut apporter une solution franchement plus rapide, franchement meilleure ou franchement moins chère que ce qui existe, pour augmenter vos chances de réussite considérablement.
3. La simplicité est une force… et une discipline
Un produit simple et performant change tout.
Ajouter des fonctionnalités est facile ; gérer leurs effets pervers l’est beaucoup moins.
Créer un produit qui semble évident et fluide pour l’utilisateur est l’un des défis les plus complexes du product management, qui débouche sur les plus grands succès.
4. L’idée, la techno, ce n’est que 1% du succès
On a souvent l’impression qu’une fois qu’on a la bonne idée, ou la nouvelle techno qui va tout changer, c’est gagné.
En réalité, il reste 99% du travail à faire, la moitié étant de concevoir le bon produit, l’autre moitié étant de faire en sorte que le produit rencontre son public (le “go to market”).
5. Trouvez l’équilibre entre écoute des utilisateurs et vision stratégique
Perdre de vue les utilisateurs pour poursuivre une vision hypothétique coûte que coûte risque de finir dans le mur de l’innovation inutile.
A l’inverse, ne se focaliser que sur le retour des utilisateurs, c’est rester dans l’incrémental, passer à côté de l’innovation qui va vraiment changer la donne et nous permettre de rester en avance sur les autres.
C’est un mix harmonieux des deux qui conduira au succès le plus grand et le plus pérenne.
6. Trouvez l’équilibre entre exécution immédiate et vision long terme
Vous serez constamment tiraillé entre urgences court terme et ambitions futures.
La clé, c’est la discipline : allouer volontairement du temps à chaque horizon.
La règle proposée par Éric :
-
70 % sur le court terme,
-
20 % sur des opportunités prometteuses à moyen terme,
-
10 % sur la vision et la stratégie à long terme.
C’est ce qui permet d’être performant aujourd’hui tout en construisant demain.
7. Les meilleures équipes cultivent la friction constructive
Une équipe qui fonctionne n’est pas une équipe où tout le monde est d’accord.
La friction positive est essentielle : elle clarifie la pensée, renforce le produit et sert l’utilisateur.
Le problème, ce n’est pas le désaccord — c’est le désaccord qui n’est pas constructif.
Verbatims
Quel produit pour quel besoin ? Ramenez une décision à chaque fois que vous pouvez à un utilisateur. Quel impact pour l’utilisateur ?
Beaucoup plus facile de répondre à un besoin existant que de créer un nouveau besoin.
Si vous répondez à un besoin existant en y répondant plus vite, mieux ou moins cher, c’est plus facile.
Important de faire un produit simple et efficace. La performance d’un produit change beaucoup de choses. C’est facile de rajouter une fonctionnalité mais ça a beaucoup d’effets pervers. Faire un produit simple, c’est beaucoup plus compliqué que ça en a l’air.
Concernant les metrics, très vite vous allez être tiraillé entre objectifs court terme et long terme.
L’importance c’est d’avoir une discipline qui vous impose de passer du temps sur chacun de ces sujets. Règle du 70/20/10 > 100 minutes disponibles = 70 sur le truc court terme, 20 sur le truc prometteur positif à moyen terme, 10 sur le futur, la vision & la stratégie
Une équipe qui fonctionne, c’est une équipe qui n’est pas d’accord. Mais il faut que cela reste constructif. La friction positive, elle est indispensable pour l’entrepreneur, le produit et l’utilisateur.
📋 Synthèse automatique
- Essentiel en 60 secondes
- La techno ne vaut presque rien si elle ne résout pas un besoin clair. Le vrai job, c’est de transformer une techno en produit utile, vendable, distribuable.
- Répondre à un besoin existant est beaucoup plus simple que créer un besoin. Si vous pouvez faire “mieux / moins cher / plus vite”, vous augmentez fortement vos chances.
- La simplicité est un avantage compétitif. Chaque fonctionnalité ajoutée augmente la confusion, les tests, la maintenance et le coût d’arrêt futur.
- Vous n’êtes probablement pas un utilisateur normal. Il faut parler aux vrais utilisateurs, pas projeter votre expertise sur eux.
- Écouter les utilisateurs sans vision est un piège. Il faut des retours terrain + une direction forte.
- En B2B, évitez de devenir une boîte de service. Le sur-mesure client peut tuer la scalabilité et exploser la complexité.
- Le bon arbitrage court terme / long terme n’est pas “intelligent”, il est disciplinaire. Garder du temps réservé au futur évite de mourir trop tôt ou de stagner.
- Les vrais leviers
- Partir du besoin, pas de la techno
- Insight : la question centrale n’est pas “qu’est-ce qu’on sait faire ?” mais “qui a vraiment ce problème ?”
- Pourquoi c’est critique : une techno sans besoin massif = pas de produit, pas de marché, pas de traction.
- Ce que ça change concrètement : vous arrêtez de construire “par admiration technique” et vous forcez chaque décision à revenir à l’utilisateur.
- Action immédiate : pour chaque fonctionnalité / idée, écrire en une phrase :
- utilisateur cible
- problème douloureux
- fréquence
- alternative actuelle
- pourquoi c’est meilleur maintenant
Si une case est floue → non précisé / à tester.
- Préférer un besoin existant à un nouveau besoin
- Insight : créer un besoin demande énormément de force de marché ; répondre à un besoin déjà là est plus simple.
- Pourquoi c’est critique : les startups sous-estiment la difficulté d’éducation du marché.
- Ce que ça change concrètement : vous priorisez les marchés où les gens ont déjà un comportement d’achat ou une douleur claire.
- Action immédiate : classer chaque opportunité :
- besoin existant mal servi
- besoin existant mieux servi
- nouveau besoin à créer
Écarter tout ce qui est “nouveau besoin” tant qu’il n’y a pas un avantage énorme.
- La simplicité est un multiplicateur
- Insight : chaque ajout de fonctionnalité augmente la complexité produit, QA, support, maintenance et risque de confusion.
- Pourquoi c’est critique : la complexité ralentit l’exécution et fragilise le produit.
- Ce que ça change concrètement : vous devenez plus strict sur les “non”.
- Action immédiate : instaurer une règle :
- une feature n’entre que si elle sert plusieurs utilisateurs / un segment stratégique
- sinon, non
Si une demande est spécifique : chercher un plugin / workaround / configuration avant de l’intégrer au cœur du produit.
- Mesurer la vitesse et la friction du produit
- Insight : un produit plus rapide adopte mieux ; quelques secondes de trop font déjà perdre des utilisateurs.
- Pourquoi c’est critique : l’adoption dépend beaucoup de la spontanéité et de l’effort requis.
- Ce que ça change concrètement : la performance n’est plus un détail technique, c’est un levier d’adoption.
- Action immédiate : identifier le “temps jusqu’à la valeur” du produit et le réduire.
- temps de chargement
- nombre d’étapes
- nombre de décisions demandées à l’utilisateur
- Parler aux vrais utilisateurs, pas à votre intuition
- Insight : fondateurs et équipes sont biaisés ; ils connaissent trop le produit et le domaine.
- Pourquoi c’est critique : vous pouvez construire quelque chose d’élégant pour vous, mais inutile pour le marché.
- Ce que ça change concrètement : la découverte terrain devient une fonction centrale, pas un exercice marketing.
- Action immédiate :
- faire des interviews courtes
- observer les usages réels
- tester un proto simple avant de coder
Si vous faites un sondage : le tester sur 2–3 personnes avant diffusion.
- Les bons sondages testent un trade-off, pas un intérêt abstrait
- Insight : demander “est-ce que ça vous intéresse ?” produit des réponses inutiles.
- Pourquoi c’est critique : les gens disent oui à l’idée, puis non à l’usage réel.
- Ce que ça change concrètement : vous passez de feedback vague à signal exploitable.
- Action immédiate : poser des questions du type :
- “Est-ce un bon usage de votre temps ?”
- “Est-ce que vous l’utiliseriez si ça prenait 30 minutes ?”
- “Si ça coûte X, est-ce encore intéressant ?”
On teste le coût réel : temps, argent, effort.
- En B2B, vendre d’abord à l’utilisateur, pas au décideur
- Insight : souvent, l’acheteur n’est pas l’utilisateur et le décideur ne comprend pas la douleur terrain.
- Pourquoi c’est critique : vendre “par le haut” avant d’avoir un usage réel est souvent plus lent et plus fragile.
- Ce que ça change concrètement : stratégie de diffusion organique dans l’entreprise.
- Action immédiate : construire une offre que l’utilisateur peut adopter rapidement, puis laisser l’usage créer la demande interne.
- exception probable : secteurs très régulés, ex. santé → non précisé sur la faisabilité exacte.
- Éviter de devenir une société de service
- Insight : trop écouter les grands comptes peut transformer un produit en custom sur-mesure.
- Pourquoi c’est critique : le code spécifique augmente la complexité et bloque la scalabilité.
- Ce que ça change concrètement : vous devez arbitrer entre “faire plaisir à un client” et “protéger le produit”.
- Action immédiate :
- limiter les custom requests
- n’accepter que celles qui servent plusieurs clients
- documenter strictement les exceptions
- si custom obligatoire : l’isoler du cœur du produit
- Le bon arbitrage court terme / long terme doit être forcé
- Insight : sans discipline, tout le monde choisit le court terme.
- Pourquoi c’est critique : trop de court terme = mur ; trop de vision sans exécution = mort avant traction.
- Ce que ça change concrètement : le planning devient un outil de survie, pas juste de priorisation.
- Action immédiate : réserver explicitement du temps aux trois horizons :
- court terme
- moyen terme
- futur
Référence donnée : 70 / 20 / 10.
- Ce que la plupart des gens font mal
Erreur 1 : construire trop tôt pour la techno
- Pourquoi elle arrive : biais ingénieur, excitation du “c’est possible”.
- Conséquence réelle : produit sophistiqué, marché absent.
- Correction concrète : partir du problème client et de la douleur mesurable.
Erreur 2 : confondre intérêt verbal et adoption réelle
- Pourquoi elle arrive : les gens aiment dire qu’ils aiment une idée.
- Conséquence réelle : faux positifs, features inutiles.
- Correction concrète : tester le coût réel d’usage, pas l’enthousiasme.
Erreur 3 : empiler les features
- Pourquoi elle arrive : pression interne, demandes clients, envie de couvrir tous les cas.
- Conséquence réelle : complexité, dette, confusion, lenteur.
- Correction concrète : n’ajouter que ce qui sert la vision et plusieurs cas d’usage.
Erreur 4 : écouter uniquement les utilisateurs
- Pourquoi elle arrive : peur de se tromper.
- Conséquence réelle : excellente exécution locale, absence de direction.
- Correction concrète : écouter les retours, mais garder une vision forte.
Erreur 5 : écouter uniquement sa vision
- Pourquoi elle arrive : arrogance ou conviction trop forte.
- Conséquence réelle : décalage marché, produit hors-sol.
- Correction concrète : remettre régulièrement la décision au terrain.
Erreur 6 : personnaliser pour chaque gros client
- Pourquoi elle arrive : pression commerciale immédiate.
- Conséquence réelle : dette produit, support compliqué, scalabilité détruite.
- Correction concrète : custom minimal, documenté, isolé du core.
Erreur 7 : penser que le fondateur peut tout porter trop longtemps
- Pourquoi elle arrive : volonté de contrôle.
- Conséquence réelle : goulot d’étranglement.
- Correction concrète : recruter un PM quand l’équipe grossit et que le fondateur ne peut plus tout tenir.
- Frameworks utiles
A. “Tech → Produit → Marché → Distribution”
- Description : séquence mentale pour éviter de s’arrêter à l’idée.
- Logique : une techno ne devient valeur que si elle trouve un besoin, un prix et un canal.
- Quand l’utiliser : à chaque nouvelle idée / feature / pivot.
- Limite : ne dit pas quoi faire exactement, seulement quoi valider.
- Exemple concret : une techno vidéo ne vaut rien si elle ne rend pas l’usage simple et distribuable sur le web.
B. “Vrai trade-off”
- Description : cadrer les questions autour du temps, du prix, de l’effort.
- Logique : l’adoption dépend des arbitrages réels, pas de l’intérêt abstrait.
- Quand l’utiliser : sondages, interviews, validation de concept.
- Limite : les réponses restent biaisées, mais moins inutiles.
- Exemple concret : “Est-ce un bon usage de 30 minutes de votre temps ?”
C. “70-20-10”
- Description : répartir l’effort entre court terme, pari proche, futur.
- Logique : éviter de tout sacrifier à l’urgence.
- Quand l’utiliser : gestion d’équipe, roadmap, allocation de temps.
- Limite : ce n’est pas une loi, juste un garde-fou.
- Exemple concret : 70% sur ce qui génère valeur immédiate, 20% sur ce qui est prometteur, 10% sur la vision.
D. “Passer par la fenêtre”
- Description : vendre par l’utilisateur pour créer une adoption organique en B2B.
- Logique : le besoin terrain pousse ensuite l’organisation à acheter.
- Quand l’utiliser : B2B où les décideurs sont éloignés du problème.
- Limite : plus dur dans les secteurs régulés.
- Exemple concret : usage spontané d’un outil dans une équipe puis demande d’achat au niveau direction.
- Adaptation intelligente
Early vs late
- Early
- focus absolu sur le besoin, l’usage réel, la simplicité
- beaucoup d’écoute terrain
- peu de custom
- Late
- plus de structure
- plus de discipline sur la roadmap
- davantage de gestion des comptes, du support et de la dette produit
B2B vs B2C
- B2B
- risque de sur-mesure
- acheteur ≠ utilisateur
- la diffusion interne peut être clé
- B2C
- importance extrême de la simplicité et de la rapidité
- le bouche-à-oreille ne marche que si la valeur est très nette
Solo vs équipe
- Solo
- le fondateur garde le rôle produit
- attention au biais personnel
- Équipe
- besoin d’un PM plus tôt
- friction utile entre PM, ingénieurs, design
- si tout le monde est d’accord, c’est suspect
- Lecture stratégique
Si j’applique ça sérieusement :
- Meilleur cas : je trouve un besoin douloureux, je garde un produit simple, j’évite le custom inutile, et je crée une traction nette vers le PMF.
- Pire erreur possible : je construis une machine trop complexe pour un marché pas assez douloureux, puis je m’enferme dans le sur-mesure client.
- Signal que ça marche :
- les utilisateurs reviennent sans forcing
- ils demandent moins d’explications
- ils paient / poussent pour l’adoption
- les demandes deviennent plus homogènes
- le produit est utilisé sans dépendre du fondateur
-
Punchlines utiles
-
La techno n’est pas le produit.
-
Si le besoin n’est pas douloureux, la startup l’est.
-
Chaque feature a un coût caché.
-
Les utilisateurs ne veulent pas “une solution”, ils veulent gagner du temps ou de l’argent.
-
En B2B, le danger numéro un, c’est de devenir une société de service.