En recherche d'un CDI — Product Manager
Casablanca · Paris · Remote — disponible sous un mois
Digital Product Manager. Dix ans passés à l'endroit exact où un produit se gagne ou se perd : le moment où l'on décide quoi construire, pour qui, et comment on saura que ça a marché. J'ai piloté une plateforme e-commerce à 1,2 million de visites mensuelles avec une équipe de six personnes, puis cadré une quarantaine de produits en SaaS, e-commerce et plateformes de services. Je cherche aujourd'hui un produit à porter dans la durée.
Contextes produit traversés
SaaS B2B E-commerce (1,2 M/mois) Marketplace Réservation Application mobile
DéfilerMa thèse
La plupart des produits n'échouent pas à cause de leur exécution. Ils échouent parce que personne n'a écrit, avant de commencer, ce qu'on cherchait à obtenir et comment on saurait qu'on l'avait obtenu. J'ai vu des équipes techniques remarquables livrer parfaitement, dans les délais, des fonctionnalités dont personne n'avait besoin. Ce n'est pas un problème d'ingénieurs. C'est un problème de décision.
Mon travail consiste à occuper ce moment-là. Comprendre le marché avant de croire à l'idée. Écouter les utilisateurs avant de croire aux personas. Écrire le critère de réussite avant de connaître les options — parce qu'un critère écrit après, ce n'est plus un critère, c'est une justification.
Ensuite, je fais faire. Le design revient aux designers, le code aux ingénieurs, l'analyse aux analystes. Ce que je porte, c'est le problème, l'arbitrage et la métrique. Et quand la métrique contredit ma décision, c'est ma décision qui bouge.
Études de cas
Chaque étude expose le problème de départ, ce que la recherche a révélé, les options écartées et le relevé chiffré à quatre-vingt-dix jours — y compris ce qui n'a pas fonctionné.
Le relevé
Six métriques issues des trois études de cas ci-dessus, relevées quatre-vingt-dix jours après déploiement. Chaque ligne renvoie à un projet nommé, avec sa source de mesure détaillée dans l'étude correspondante.
Ces chiffres décrivent des contextes précis, avec leurs contraintes et leurs angles morts. Je les présente pour montrer un raisonnement, pas pour promettre un rendement.
Ma méthode
Ce n'est pas un processus linéaire mais un cycle. Ce qui compte n'est pas l'ordre des étapes : c'est de savoir, à chaque instant, quelle décision est en train de se prendre et qui la prend.
Temps 01
La décision : sur quoi on travaille
Écrire le problème avant les solutions, et le critère de réussite avant de connaître les options. Si personne ne sait répondre à « comment saurons-nous que ça a marché ? », le sujet n'entre pas en sprint.
Temps 02
La décision : ce qu'on croit et ce qu'on sait
Marché, concurrence, entretiens utilisateurs, données existantes, tickets support. L'objectif n'est pas de confirmer l'idée : c'est de chercher ce qui l'invalide, tant que ça coûte encore peu cher.
Temps 03
La décision : ce qu'on ne fait pas
Trois critères écrits avant de connaître les candidats : impact estimé sur la métrique de la période, effort tel que l'équipe l'estime elle-même, et coût du retard. Le troisième est le plus discriminant et le plus souvent oublié.
Temps 04
La décision : ce qui est fini, et par qui
Découpage en incréments livrables, critères d'acceptation écrits avec l'équipe, instrumentation prévue avant la mise en production. Le design revient aux designers, le code aux ingénieurs. Mon rôle est de leur donner un problème clair et de les protéger de ce qui n'en est pas un.
Temps 05
La décision : ce qu'on corrige
Relevé à trente, soixante et quatre-vingt-dix jours. Ce que je porte devant un comité, ce n'est pas ce qu'on a livré : c'est ce qui a bougé, y compris quand rien n'a bougé. Une décision qui ne survit pas aux chiffres est une décision qu'on reprend.
Parcours
Agence, entreprise, indépendance. C'est la raison pour laquelle je parle aussi bien aux développeurs qu'aux directions générales — et pourquoi je cherche aujourd'hui à porter un produit dans la durée.
2020 — aujourd'hui
Conseil produit — Casablanca
Une quarantaine de produits accompagnés sur la phase de décision : cadrage du problème, recherche utilisateur, analyse concurrentielle, arbitrage du périmètre, définition des métriques, puis relevé à quatre-vingt-dix jours. Toujours en équipe mixte avec les designers et les développeurs internes.
2017 — 2020
Groupe de distribution en ligne, 400 salariés — Casablanca
Responsable du domaine « achat » de la plateforme marchande et de l'application mobile. Refonte du tunnel d'achat après analyse des abandons, création du design system interne, roadmap trimestrielle arbitrée sur critères écrits plutôt que sur les demandes des directions métier.
2014 — 2017
Agence de communication — Rabat
Une quarantaine de projets pour des marques nationales des secteurs banque, distribution et tourisme. Passage progressif de l'exécution graphique au cadrage : recueil du besoin, arbitrage du périmètre, coordination des développeurs.
Ce que je cherche
Un recruteur doit pouvoir savoir en dix secondes si son poste correspond. Voici les critères ; si je ne corresponds pas, je le dirai aussi vite.
Le poste
Je préfère hériter d'un produit qui a des problèmes plutôt que d'une page blanche : c'est là que le travail de décision compte le plus.
Le contexte
Au minimum un designer et deux développeurs. Une organisation où le PM arbitre le périmètre, plutôt que d'écrire des tickets sous dictée.
Les secteurs
SaaS B2B, e-commerce, marketplaces, plateformes de services. Les contextes où ce qui bouge à l'écran se lit directement dans le compte de résultat.
Le cadre
Casablanca, Paris ou remote avec déplacements réguliers. Mobilité possible. Je ne prends plus de mission indépendante.
Ce que je ne cherche pas : un rôle d'exécution sans mandat sur le « pourquoi », une organisation où la roadmap est décidée ailleurs et transmise au produit, ou un poste où je serais le seul à porter le produit, sans designer ni analyste.
Outils
Classés par moment du cycle plutôt que par catégorie technique. Un outil que l'équipe ne sait pas utiliser est un mauvais outil, quelle que soit sa réputation.
Questions fréquentes
Autant y répondre maintenant. Une question qui n'est pas ici ? Écrivez-la, je réponds sous 24 heures.
Parce qu'un mandat s'arrête au moment où le produit commence à vivre. Je livre une décision, je la mesure à quatre-vingt-dix jours, et je pars sans savoir si elle tenait à douze mois. Je veux la suite : une équipe stable, une roadmap portée sur plusieurs trimestres, et le droit de corriger mes propres erreurs. Ce n'est pas un repli, c'est le seul moyen d'accéder à la partie du métier qui me manque.
Product Manager. J'ai été les deux autres, et cela me sert tous les jours : je sais lire une maquette, contester une estimation, et reconnaître quand « c'est compliqué » veut dire « c'est cher » ou « je n'ai pas envie ». Mais je ne dessine plus les écrans et je n'écris plus le code de production. Ce n'est plus mon travail, et une équipe a besoin que ce ne le soit plus.
J'ai encadré une équipe produit de six personnes pendant trois ans, avec un comité de direction à convaincre tous les mois. En indépendant, je n'ai jamais travaillé seul non plus : les designers et les développeurs étaient ceux de l'entreprise, et une partie de mon travail consistait précisément à obtenir sans autorité hiérarchique. C'est un exercice utile — on apprend à convaincre plutôt qu'à trancher.
Trois critères écrits avant toute discussion : l'impact estimé sur la métrique de la période, l'effort tel que l'équipe l'estime elle-même, et le coût du retard — ce qu'on perd chaque semaine à ne pas le faire. Le troisième est le plus discriminant et le plus souvent oublié. Ce qui rend une priorisation crédible, ce n'est pas le cadre choisi, c'est le fait que le critère soit écrit avant qu'on connaisse les candidats.
Je sépare le désaccord sur les faits du désaccord sur les valeurs. Sur les faits, je propose la plus petite expérience qui tranche, et je m'engage à suivre le résultat. Sur les valeurs — ce qu'on veut être comme produit — la décision revient au dirigeant, et je m'aligne publiquement même quand je ne suis pas convaincu. Chez Kaya, la direction voulait recruter deux commerciaux ; je suis arrivé avec le coût d'acquisition par client payant, pas avec une opinion.
Une visite guidée interactive en cinq étapes, sur laquelle j'ai insisté six semaines contre l'avis du designer. Taux de complétion : 18 %. J'avais confondu « les utilisateurs ne comprennent pas » avec « les utilisateurs n'ont pas été assez expliqués ». Un produit qui a besoin d'être expliqué a un problème de conception, pas de pédagogie. Je l'ai remplacée par des aides contextuelles, et j'ai gardé la leçon.
Disponible sous un mois. Casablanca, Paris ou remote avec déplacements réguliers ; mobilité possible. Sur la rémunération, je préfère en parler une fois le périmètre du poste précisé — mais je réponds directement si vous préférez le cadrer d'emblée.
Prochaine étape
Vingt minutes suffisent pour savoir si le contexte correspond. Décrivez le produit, l'équipe et le problème du moment — je réponds sous 24 heures, y compris quand ma réponse est « je ne suis pas la bonne personne ».
