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.

Between 2023 and 2025, I was Product Owner on QHARE's B2B CRM — a SaaS used every day by salespeople, support teams, managers, on web and on mobile. Two years is long. Long enough for the early intuitions to break, and the real lessons to surface. Here are the five that helped me most, and that I now bring to Horyond clients.

1. Not all features are equal — and it's OK to say so

The most dangerous fiction in B2B SaaS is "everything matters". It's false, but it's comfortable for a PM who wants to avoid trade-offs. The reality: about 20% of the roadmap delivers 80% of the value, and you have to be able to say it out loud.

The framework I ended up using at QHARE:

  • Must-do — the feature unlocks revenue that's already signed or being signed, OR it kills a critical volume of support tickets, OR it carves out a measurable competitive moat. Three criteria, and at least two need to be green.
  • Should-do — it improves the experience of a known segment but doesn't change the near-term trajectory. It waits for a window.
  • Never-do — the most useful and most ignored bucket. A written, shared list of the things we will not do, with the reason. Stops you re-debating the same feature every six months.

The simple act of having an official "never-do" list cut our prioritization meetings in half.

2. The metrics that matter (and the ones that flatter)

On a utility product like a CRM, the trap is to track metrics that please the board but say nothing about product health. Number of features shipped per quarter, for example, is a vanity metric. What actually guided me:

  • Daily Active Users — for a tool salespeople use every day, DAU is the only real sign of life. A feature that doesn't move DAU within 30 days is suspect.
  • Time-to-value for new accounts. How many days between signup and the first real-value action (creating a deal, logging a call, triggering a follow-up). We moved it from 9 to 4 days in a quarter, and that's the number the sales team loved above all others.
  • Support deflection rate — the share of support tickets avoided by a product improvement. I measured it by asking support to tag tickets "could have been avoided by X". Brutal, readable, actionable.
  • User resolution — over the period, we pushed this up by +20%, with 200 weekly impressions climbing within 2 weeks. That's the chart that ended internal debate on the mobile redesign.

What I stopped tracking after the first six months: features shipped, burn-down rate, global NPS. Too noisy, too disconnected from any decision.

3. Aligning a team: the weekly cadence

A roadmap isn't a file. It's a rhythm. What worked for us:

  • JIRA for execution — one board, swimlanes per squad, no exotic customization. If you can't explain it to a new hire in five minutes, simplify.
  • Confluence for memory — one spec doc per feature, structured as "problem / hypothesis / solution / success metric". Two pages max. If I can't fit it in two pages, I don't yet understand the feature.
  • Weekly with engineering — 45 minutes, fixed format: demo of what shipped, blockers, next week. No roadmap grooming in that meeting.
  • Monthly with sales — where I bring the metrics from section 2, and sales brings their three biggest customer pain points. Three, not thirty. The constraint forces the triage.
  • The 3-question briefing — for every new initiative, I asked the team for three written answers before kicking off: (1) which user does what differently? (2) how will we know in 30 days that it worked? (3) what are we explicitly not including? If the three boxes are vague, we don't start.

4. The discipline of "no"

A PM spends more time saying no than yes. But a vague no ("we'll see later", "not this release") creates more friction than an explicit no. My rule: a no should always come with a written, shareable reason that points back to the framework in section 1.

Concretely, I set up a Slack channel #feature-requests where every request got a three-line answer: decision, reason, next review. Sales reps took four weeks to stop complaining, then started filtering their own requests before posting. That's when the political debt dropped for good.

5. What I now bring to Horyond Agency clients

None of the above matters unless it lands in an organization. That's exactly what I now do with Horyond Agency: audit a roadmap, install the rituals, write the first "never-do", wire up three metrics that actually matter, and leave once the team runs without me. The mandate isn't to do product for them — it's to leave a system behind that survives my departure.

If you run a B2B product and recognize two or three symptoms from this piece (a roadmap that looks like a shopping list, sales and engineering speaking different languages, features shipping but DAU flat), email me at contact@thanaelfontaine.eu or book a call from the contact page. The first conversation is free, and often enough to surface where it's actually stuck.