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.