Entre 2023 et 2025, j'ai été Product Owner sur le CRM B2B de QHARE, un SaaS utilisé tous les jours par des commerciaux, des équipes support, des managers, sur web et sur mobile. Deux ans, c'est long. Assez long pour que les bonnes intuitions du début se cassent la figure, et que les vraies leçons remontent. Voici les cinq qui m'ont le plus servi, et que je ramène aujourd'hui chez les clients de Horyond.

1. Toutes les fonctionnalités ne se valent pas, et c'est OK de le dire

La fiction la plus dangereuse en B2B SaaS, c'est « tout est important ». C'est faux, mais c'est confortable pour un PM qui veut éviter d'arbitrer. La réalité, c'est qu'environ 20 % de la roadmap fait 80 % de la valeur, et qu'il faut savoir le dire à voix haute.

Le framework que j'ai fini par utiliser à QHARE :

  • Must-do : la feature débloque du revenu déjà signé ou en train d'être signé, OU elle fait chuter un volume de tickets support critique, OU elle creuse un moat concurrentiel mesurable. Trois critères, et au moins deux doivent être verts.
  • Should-do : elle améliore l'expérience d'un segment identifié, mais ne change pas la trajectoire à court terme. Elle attend une fenêtre.
  • Never-do : la catégorie la plus utile et la plus oubliée. Une liste écrite, partagée, des choses qu'on ne fera pas, avec la raison. Ça évite de re-débattre la même fonctionnalité tous les six mois.

Le simple fait d'avoir un « never-do » officiel a fait baisser nos réunions de priorisation de moitié.

2. Les métriques qui comptent (et celles qui flattent)

Sur un produit utilitaire comme un CRM, le piège c'est de suivre des métriques qui font plaisir au board mais ne disent rien sur la santé du produit. Le nombre de features livrées dans le trimestre, par exemple, est une vanity metric. Ce qui m'a vraiment guidé :

  • Daily Active Users : pour un outil utilisé tous les jours par des commerciaux, le DAU est le seul vrai signe de vie. Une feature qui n'augmente pas le DAU sur 30 jours est suspecte.
  • Time-to-value sur les nouveaux comptes. Combien de jours entre le signup et la première action de vraie valeur (créer un deal, logger un appel, déclencher une relance). On l'a fait passer de 9 à 4 jours en un trimestre, et c'est ce chiffre que la sales team préférait au-dessus de tout.
  • Support deflection rate : la part de tickets support évités par une amélioration produit. Je le mesurais en demandant à l'équipe support de tagger les tickets « aurait pu être évité par X ». Brutal, lisible, actionnable.
  • Résolution utilisateur : sur la période, on a poussé ce chiffre de +20 %, avec 200 impressions hebdo remontées en 2 semaines. C'est ce qui a calmé les débats internes sur l'utilité de la refonte mobile.

Ce que je ne trackais plus après le premier semestre : le nombre de features livrées, le burn-down rate, le NPS global. Trop bruités, trop déconnectés de la décision.

3. Aligner une équipe : la mécanique hebdo

Une roadmap n'est pas un fichier. C'est un rythme. Ce qui a marché chez nous :

  • JIRA pour l'exécution : un seul board, des swimlanes par squad, pas de personnalisation exotique. Si on ne peut pas l'expliquer à un nouveau en cinq minutes, on simplifie.
  • Confluence pour la mémoire : un document de spec par feature, structuré en « problème / hypothèse / solution / métrique de succès ». Pas plus de deux pages. Si je n'arrive pas à tenir en deux pages, je ne comprends pas encore la feature.
  • Hebdo avec l'engineering : 45 minutes, format figé : démo de ce qui a été livré, blocages, prochaine semaine. Pas de roadmap-grooming dans cette réunion-là.
  • Mensuel avec la sales team : où je ramène les métriques de la section 2, et où la sales ramène ses trois plus gros pain points clients. Trois, pas trente. La contrainte force le tri.
  • Le briefing 3-questions : pour chaque nouvelle initiative, je demandais trois réponses écrites à l'équipe avant de démarrer : (1) quel utilisateur fait quoi de différent ? (2) à quoi on saura que ça marche dans 30 jours ? (3) qu'est-ce qu'on n'inclut pas explicitement ? Si les trois cases sont vagues, on ne démarre pas.

4. La discipline du « non »

Un PM passe plus de temps à dire non qu'à dire oui. Mais un non vague (« on verra plus tard », « pas dans cette release ») crée plus de frictions qu'un non explicite. Ma règle : un non doit toujours être assorti d'une raison écrite, partageable, qui revient au framework de la section 1.

Concrètement, j'ai mis en place un canal Slack #feature-requests où chaque demande recevait une réponse en trois lignes maximum : décision, raison, prochaine évaluation. Les commerciaux ont mis quatre semaines à arrêter de se plaindre, puis ont commencé à filtrer leurs propres demandes avant de les poster. C'est le moment où la dette politique a baissé pour de bon.

5. Ce que j'amène aujourd'hui chez Horyond Agency

Tout ce qui précède n'a de valeur que s'il rentre dans une organisation. C'est exactement ce que je fais maintenant avec Horyond Agency : auditer une roadmap, installer les rituels, écrire le premier « never-do », brancher trois métriques qui comptent vraiment, et partir une fois que l'équipe tourne sans moi. Le mandat n'est pas de faire du produit à leur place : c'est de leur laisser un système qui survit à mon départ.

Si vous pilotez un produit B2B et que vous reconnaissez deux ou trois symptômes de cet article (roadmap qui ressemble à une liste de courses, sales et engineering qui ne parlent pas la même langue, features livrées mais DAU plat), écrivez-moi à contact@thanaelfontaine.eu ou bookez un appel depuis la page contact. Le premier échange est gratuit, et souvent suffisant pour clarifier où ça bloque.