The scope has never been set
The team is building, but nobody can say precisely which problem is being solved or how you will know it has worked. Every meeting reopens the debate, and the roadmap is rewritten every month.
Home Product and web applications
You have a product intuition, an engineering team, and a gap between the two. I step in to turn a vague need into an executable scope, then hold the delivery rhythm all the way to production.
For the same need (someone whose job is to decide what to build), here are the orders of magnitude on the French market and what you pay here.
An external product manager doesn't need to be there five days a week to hold the trade-offs: they need to be there at the right moments, with the context in mind. The rest of the time you pay for with a permanent hire is availability, not decision-making.
The first two columns are orders of magnitude on the French market, given as a benchmark: your situation may differ. The third is the rate applied here.
If you recognise yourself in one of them, scoping is probably worth more than the extra development you are considering.
The team is building, but nobody can say precisely which problem is being solved or how you will know it has worked. Every meeting reopens the debate, and the roadmap is rewritten every month.
You are promised gains everywhere, your board wants an answer, and nobody in-house can separate what really works from what will cost a lot for nothing.
Cycles slip, tickets pile up, designers and developers work out of step. The problem isn't velocity, it is the lack of decisions.
Most product work happens in writing. A need voiced in a meeting becomes an epic, then user stories, then tickets that each carry their acceptance criteria. A developer who opens a ticket knows what to build and how to check it is finished.
As an operations manager, I want to export the month's customer requests, so that I can prepare the monthly review without re-entering data.
Acceptance criteria
Out of scope
PDF export, automatic sending by email.
Linear brings the specification, tickets, cycles and projects together in one place. You follow progress whenever you like, without waiting for a report.
One to two weeks, with a scope committed at the start. Whatever isn't finished is carried over or split again, and the reason is written down.
Requests and bugs come in through a single queue. Each one is qualified, prioritised or set aside, with its justification.
Epics are grouped into dated projects. You see what is moving, what is slipping, and why.
Every cycle ends with a viewable version. Your feedback becomes tickets straight away.
The full range, or a single part. Most engagements start with a short scoping phase before going further.
Fifteen minutes to understand the context, the deadline and the budget. If the subject isn't for me, I say so and point you in the right direction.
A short document that sets the problem, the scope, the deliverables and the acceptance criteria. It is the basis of the quote.
Cycles of one to two weeks, a progress review at the end of each one, a board you can read at any time. You change direction whenever you want.
Documentation, skills transfer to your team and, if needed, a period of light follow-up after the engagement ends.
The quote is always drawn up after scoping, never before.
One week to go from a vague need to an executable scope. A short, closed engagement: at the end, your team can get started, or you decide to build nothing.
Discuss itWhen scoping leads to a tool to build: I design it and take it to production, with a scope and a price written down before we start.
See the web application offerA part-time product manager, every month, for a fraction of the fully loaded cost of a permanent hire. You scale the volume up or down with the workload, without recruiting or terminating a contract.
Discuss itNo VAT charged: VAT exemption scheme for small businesses, art. 293 B of the French General Tax Code.
Five questions, 20 seconds. You get the service that fits, a budget range and a timeline. No email address asked. The questionnaire is in French.
Take the questionnaireNo, unless you explicitly ask. Most often, I support an existing team or fill a vacant role while you recruit. The goal is for your team to be self-sufficient when I leave, not to depend on me.
Because recruitment takes one to two quarters, an experienced PM costs significantly more once fully loaded, and you need to be able to stop if the need changes. PM-as-a-Service starts within two weeks, adjusts every month and stops with one month's notice. When the volume becomes constant and lasting, a permanent hire becomes the right choice again, and I will tell you so at that point.
Linear for specifications and tracking: both in the same place, so that a spec doesn't live apart from the ticket that implements it. Figma for design, Notion or Google Docs for working notes and shared meeting notes, GitHub for code. If your team uses something else, I adapt to your stack rather than imposing one.
Fifteen minutes is enough to know whether we should work together. The call is free and you leave with an opinion either way.