Bruno Jourdan.Senior PM

Senior Product Manager · Product Owner

Product judgment for regulated, high-stakes software.

Ten years building B2B SaaS across hospitality, gaming, and health technology, most recently leading an 18 person cross functional team. Now shipping LLM powered products where accuracy, privacy, and trust are not optional, including AI assisted clinical notes in European Portuguese.

Experience
10 years, B2B SaaS
Domains
Hospitality · Gaming · Health tech
Focus now
AI product, regulated domains
Based
Portugal · open to relocation
01

How I work

A through line runs across every domain I have worked in: the constraints were the product. Gaming taught compliance per market, hospitality taught integration at scale, and health tech now demands both at once. The senior move is deciding what not to build, and being clear about why.

Decide, then build

Tradeoffs over features

The scarce resource is judgment, not effort. I lead with the call I made and the option I turned down, because that is where the value sits.

Probabilistic products

Design the trust model first

With AI, the first question is where the human sits and what the model is allowed to touch. Output quality comes after that, not before.

Regulated by default

Compliance as design input

RGPD, clinical safety, and billing rules are not paperwork bolted on at the end. They shape the architecture from the first sketch.

02

Selected work

Four cases chosen for range: an AI product in a regulated domain, cross functional leadership at scale, a zero to scale growth story, and international launches under heavy regulation.

Featured · AI product
Solo founder · Star Mountain 2025 to present

AI assisted clinical session notes, built to be trusted

LLM product Human in the loop Evals European Portuguese RGPD / health data Clinical safety
The call

Chose clinician verified drafts over autonomous notes, and pt-PT clinical fidelity over a faster launch on a generic model.

Context

Star Mountain is a clinic management SaaS I am building solo for psychology and psychiatry practices in Portugal. It covers scheduling, integrated teleconsultation, electronic clinical records, AT compliant billing, and RGPD compliance. The feature explored here is optional AI assisted session notes in European Portuguese.

The problem

Clinicians lose meaningful time writing notes after every session. It is administrative drag that eats into clinical hours and feeds burnout. A language model can draft those notes, but this is the opposite of a low stakes use case: the data is sensitive mental health information under RGPD, the audience is clinicians who will not trust output they cannot verify, and a fabricated clinical detail is not a cosmetic bug, it is a safety and liability problem.

The AI specific decisions
  • Draft, never decide. The feature is framed as a first draft accelerator, not a source of truth. Nothing enters the clinical record until a clinician reviews, edits, and signs off. That sign off is not a nicety, it is the core safety mechanism of the product.
  • Human in the loop by design. Generate, then clinician edits, then explicit approval, then the record. I placed the human at the one point where a mistake is caught before it becomes permanent, rather than treating review as an optional afterthought.
  • A working definition of good enough. Quality was not defined as elegant prose. It was defined as a faithful, editable starting point that saves time without inventing clinical facts. I evaluated against clinician edit effort and time saved, with a hard rule that no invented findings are acceptable, which matters more than fluency.
  • European Portuguese, not a translation. Clinical register in pt-PT is distinct from Brazilian Portuguese and from translated English. A note that reads foreign erodes trust instantly, so I chose to invest in pt-PT specific prompting and evaluation rather than ship faster on a generic multilingual default.
  • Privacy as a purchase decision. For a clinic, how sensitive health data is processed is a buying factor, not just a compliance checkbox. I designed around data minimisation, clear consent, and explicit processing boundaries, and made those legible to the clinic rather than buried.
  • Latency budget spent on quality. Notes are generated after the session, not live, so the latency budget is generous. I used that headroom to prioritise accuracy and cost control instead of chasing real time speed the use case does not need.
Outcome

The product thesis is validated where it counts: the differentiator is not that notes are generated, it is that they are generated in a way clinicians will actually adopt, in their own clinical language, without asking them to trust a black box. The trust model, human sign off plus pt-PT fidelity plus visible privacy, is the moat, and it is a harder thing to copy than the generation itself.

Prototype

An early working prototype of the clinic dashboard. The day timeline re-divides into 15 to 60 minute slots, with a live clock, appointment counter, status KPIs, per professional load, a waiting list, and a projected revenue snapshot. Patient names are abbreviated by default, so privacy is the resting state rather than a setting. The interface is in European Portuguese by default, with a PT/EN toggle for English readers. Try the interval control, the professional selector, and the language switch.

app.starmountain.pt/agenda
Star Mountain Clinic Project Star Mountain · Seia
--:--:--
Agenda do dia
Carga por profissional
Lista de espera
€0
Receita prevista hoje
Nomes apresentados de forma abreviada por predefinição · RGPD

Open the live prototype in full screen

The lesson that carries into any AI role: with a probabilistic product, you design the trust model before you optimise the output. Deciding where the human sits and what the model may touch is the senior work. Tuning the prompt comes after.

Senior Product Owner · Shiji Group May 2023 to June 2026

Retiring one golf product cleanly while building its successor into an enterprise PMS

Product lifecycle Golf management Microservices Integrations Reservation engine UX ownership
The call

Chose to take the legacy golf product to a clean end of life and rebuild its successor inside Daylight PMS, over keeping an aging standalone system on life support.

Context

I owned golf management software inside Shiji's hospitality portfolio, which meant running two products through a transition at once: an existing golf management system, and a new one designed to live as part of Daylight PMS, the group's larger enterprise platform. Both were integration heavy and built on microservices, so neither could be treated in isolation.

What I owned
  • A full product lifecycle. I took the existing golf product through the end of its lifecycle into maintenance mode, closing it out responsibly rather than letting it drift, while its replacement was still being built.
  • The successor, built into the platform. I led the creation of the newer golf management product as a component of Daylight PMS, so it inherited the enterprise platform's reach instead of living as a silo.
  • Integrations and microservices across both. Keeping the services and integrations healthy on the outgoing product mattered as much as the incoming one, so I owned both sides of the transition, not just the new build.
  • The reservation engine and its rules. I created the reservation engine for golf, including the booking rules that make golf scheduling genuinely hard: tee time logic, availability, and the conditions that govern a valid booking.
  • UX at approval level. The entire product UX passed through me for sign off, so I was the quality gate on how the product felt, not only on what it did.
Outcome

Delivered a cleanly managed lifecycle transition: one product taken to a responsible end state, its successor stood up as part of the enterprise PMS, and a golf reservation engine built from the rules up. Specific internal metrics remain confidential under the terms of my departure, so this case is described by scope and ownership rather than numbers.

Lifecycle management is an underrated senior skill. Retiring a product well while building the thing that replaces it, and making that successor part of a larger platform, is a different discipline from a clean sheet launch, and it is where a lot of real product judgment lives.

Product & Project Support, Mobile · Nonius / B-Guest Earlier career

Scaling a guest app from 6 hotels to roughly 600

Mobile Zero to scale Productisation Android
The call

Chose a productised, standardised core over per hotel customisation, so the app could scale across wildly different properties.

Context

I supported and helped grow the Android guest app that hotels offer their guests, and helped build out the mobile department around it. The app went from a handful of properties to roughly 600.

What made it scale
  • Standardisation over bespoke. Every hotel wanted something slightly different. Scaling to hundreds meant treating that variety as a productisation problem, configurable where it mattered and standard everywhere else, rather than a stack of one off builds.
  • Onboarding as the real bottleneck. Growth was gated by how smoothly a new property could go live, so reducing that friction mattered more than any single feature.
~600
hotels reached
100x
growth in footprint
0 to 1
mobile department built out

Scaling one product across very different customers is not a sales problem, it is a productisation problem. The discipline of standardising the core is what makes hundreds of deployments possible.

Product Manager · Fabamaq Earlier career

Two international market launches in a regulated industry

Gaming technology Market entry Regulatory compliance Localisation
The call

Chose to treat each market's regulator as a first class requirement over shipping one build and adapting later.

Context

As a product manager in gaming technology, an industry regulated market by market, I led two launches into new international markets.

What the launches demanded
  • Compliance first, per jurisdiction. Gaming rules differ sharply between markets. Each launch meant meeting a distinct regulatory bar, and treating that as a design constraint from the start rather than a hurdle at the finish.
  • Localisation beyond language. Entering a market well means fitting local expectations and rules, not just translating strings.

This is where my compliance first instinct was formed. The habit of designing to the regulator from day one is exactly what a health tech AI product like Star Mountain now needs, which is why the through line matters more than any single role.

03

Skills and toolkit

Core product craft, plus the specific competencies that non deterministic products require. The AI PM skills are named explicitly on purpose, because building AI products is a different discipline from using AI tools to work faster.

AI product management
LLM product design · evaluation and quality definition · human in the loop design · hallucination and accuracy mitigation · non deterministic UX · prompt and model iteration · hands on prototyping with Claude and Kiro
Core product craft
Discovery · roadmapping · prioritisation · stakeholder management · cross functional leadership · user stories in Given / When / Then · backlog design
Regulated domains
RGPD / GDPR · sensitive health data · clinical safety framing · gaming compliance per market · billing and tax compliance (AT)
Technical fluency
REST APIs · Postman · SQL · JSON · Figma · Grafana · Jira · Confluence
CSPO, Certified Scrum Product Owner Product Roadmapping Micro-Certification Google Project Management foundations pt-PT native English, professional Spanish, professional
04

Get in touch

Open to senior product roles, with a particular interest in AI products and regulated domains. Available for relocation.

Location
Seia, Portugal
Availability
Open to relocation