Founding Product Manager, AI Legal-Tech Agent

Founding Product Manager, AI Legal-Tech Agent (Paris)

400 notary offices, 20,000 transactions a month, over €2M ARR, six engineers, and nobody in product. The co-founder writes specs between two meetings. You come in to turn product into a real discipline. Ideally, you learned the craft at a leading product-led scale-up.

• Product Management
• Specs & Discovery
• PostHog
• Agents IA / LLM
• B2B SaaS
• Legal-Tech

The company

Our client is building the AI colleague for French notaries. The product lives inside Outlook and Word, where notaries already work: it reads the emails on a case file, drafts the replies, fetches missing documents from a dozen public and partner registries, extracts the legally relevant facts and flags what needs a human.

More than 400 notary offices use it. Over 20,000 transactions go through the product every month. ARR has passed €2M. Six engineers, and not a single person in product yet.

The product covers the whole asset-transfer chain: collecting and interpreting administrative documents, drafting deeds, filing with the land registry.

The goal is €4M ARR by year end and €20M within two years. The engineering team went from three to six engineers in two months. Users are demanding professionals working on legal deeds where mistakes are not an option: reliability is as much a product topic as a technical one.

Why this role exists

Today, the co-founder IS the product function. He writes the specs, ranks the backlog, decides what ships, talks to notaries and chases what happened after a release went out. He does all five, and does each of them about half as well as they deserve.

The result is predictable: specs that are too thin, engineers who build the wrong thing or stop to ask a question, priorities that move because he moved them, and features that ship without anyone checking they do what was asked. The loop almost never closes: it ships, and nobody measures whether it changed anything.

You are here to make product a discipline in its own right, instead of something a founder does between two other things.

What you own

• Specs engineers can build from without tracking down the founder. Problem, expected behaviour, edge cases, definition of done. Written. It is the highest-leverage item on this list, and it starts in week one.
• The backlog and the mechanics around it. The team runs on Linear, with 80% of capacity allocated to cycles and 20% to an interrupt lane. The tooling is good, the discipline is irregular. You own the ranking, the grooming, and saying no to the founder when he reshuffles the deck.
• Acceptance. Nothing reaches a notary because a ticket was dragged into "Done". You check in the product that it actually does the thing, before it counts.
• Closing the loop. What shipped, for whom, and whether it moved anything. PostHog for behaviour, Productlane for what customers say. Using them to answer "did it work?" is on you.
• Discovery. You talk to notaries directly, not through the founder, not through a summary. You come back with problems he had not seen and a view on which ones matter.

What the founder keeps, and what comes next

Today he keeps the roadmap and the strategic direction. He also wants to build a company that runs without him, and would rather grow someone ambitious than manage someone comfortable. So the scope grows with trust: the more operational work you take off his plate by doing it better than he does, the more of the strategic half he hands over.

Who this is for

• Ideally, you have been a PM at a leading product-led scale-up (fintech, insurtech, SaaS: think N26, Qonto, Alan, Pennylane...). You kept the reflexes: discovery that never stops, decisions made on data, short iterations, and the habit of killing what does not work.
• You have done product in a small B2B SaaS company where the process did not exist yet. Not inherited a set of rituals and ceremonies: built one from scratch, and kept it light enough that people actually use it.
• You write specs people actually read. You can take a fuzzy problem in a complicated domain and turn it into something an engineer picks up without a meeting. Ambiguity is something you remove, not something you pass on.
• You go to the source. You will be on video calls with notaries, in the support tickets, watching someone misuse the product without explaining how they should use it.
• You have judgment on what not to build. The constraint here is not a lack of ideas: you will spend more time killing and sequencing than generating.
• You are comfortable close to the material. Today the founder specifies and the frontend engineer produces a v0 mock-up; that loop works and can continue with you in his place. Being able to get your hands in and iterate on those