Both. Direct is simpler: a single point of contact, trade-offs settled with the person who owns the budget, and no filter between what the team sees and what leadership hears. But an agency that brings me an engagement has done real work, and that work gets paid for. If you go through a middleman, my rate does not change - whatever the middleman adds, they bill on top. The market measures a 20 to 30% gap between the two channels: that is their margin, not mine, and it is not mine to fund.

What you are buying is a Technical Product Owner across six domains: AI & GenAI, API, Platform, Cloud, DevOps, B2B & B2C SaaS. That is what the rate reflects, not the rate of a proxy taking notes on other people's decisions. 500 € excl. VAT per day, all in: in the Paris area, no travel expenses, no meetings or commutes billed separately, no onboarding fee. Elsewhere, I work remotely. If your product needs none of the six domains, say so: you would be paying for a skill you will not use, and it is not a good engagement for you.

You are paying for a Technical Product Owner. I decide the what and the order; the team designs the how, and that is their call, not mine. What "technical" adds: I open the repository, I read what the code actually does, I write acceptance criteria a developer does not have to translate, and I recognise an architecture cost when someone describes one. What I do not do is take stories from the sprint I prioritized: a Product Owner who codes their own backlog arbitrates with themselves, and stops arbitrating. If it is a developer you need, that is another craft, another page and another rate.

Three months minimum, five days a week by default. Three or four days is very much open to discussion if the product does not need more - I would rather have an honest part-time than a full-time where meetings get invented for me. Below three months I decline: framing takes a few weeks, but the first hard trade-off rarely lands before the second month, and leaving just before it means leaving you the hardest part. Below two days a week too: a Product Owner who is away on the day the call is made is not a Product Owner, they are a minute-taker.

Immediately - it is what the rate card says, and it is true on the day you read this page. On an engagement in the Paris region I can be on site for the kick-off and move to remote afterwards: the first days are the ones where you meet people, and that goes badly through a screen. The rest is arranged around what the product needs.

You do, entirely. Full assignment of rights on payment, covering everything the engagement produces: the code, but also the backlog, the specifications, the diagrams, the documentation and the decision records. I keep no usage rights, and I reuse nothing at another client. What stays mine is the know-how - the way of working, not what it produced at your company. A non-disclosure agreement is signed without difficulty, and I will sign it before the first detailed conversation if you prefer.

I invoice through OMBREMIMS, my company - you contract with a registered French company, not with an individual. A services agreement is signed before day one: it carries the scope, the rate, the pace and the notice period, and nothing starts without it. Invoicing is monthly, in arrears, payable within 30 days, against a timesheet you approve; VAT added at the applicable rate. The company registration extract (Kbis) and the URSSAF compliance certificate go to your procurement team on request.

Because it is not the status that decides, it is how long the need lasts: contract work makes sense when the need has an end, a role when it does not - and there are products you do not take on for six months. Three things change, and nothing else. The rate: there is no day rate in employment. The figure shown on this site is a price for contract work, it does not convert; salary expectations are discussed in the first conversation, on what the role is worth. The contract: the answers that follow - notice period, exclusivity, insurance - along with invoicing and ownership of deliverables above describe contract work. On a permanent or a fixed-term contract, employment law applies, and I have nothing particular to add to it. And OMBREMIMS: the company does not close, it changes role. It stops every consulting and contracting activity for the duration of the employment contract - it is the exclusivity clause every employer writes, and I sign it without argument. Photography and the products remain, outside working hours and declared on hiring.

One month's notice, on both sides, with no reason required. It is symmetrical on purpose: a clause that protects only one side always turns around in the end. But notice is the safety net, not the mechanism. The real mechanism sits upstream: at the end of the first month I call a check-in that is not about the product - is this working, am I filling the place you expected, what is bothering you that you have not said. It is deliberately kept apart from the reviews, because a fundamental disagreement slipped into a sprint review never gets said. A disagreement left unsaid costs more than an engagement that ends.

No. One engagement, full time, from start to finish. That is the counterpart of the three-month floor: someone arbitrating for two products arbitrates badly for both, because the cost of a bad trade-off only shows up in the next sprint - and by then they are somewhere else. OMBREMIMS carries two other activities you will see on this site, three products under construction and a photography practice: they live outside engagement days, and none of them takes a day you are paying for. If you want the rule in writing, it goes in the contract.

Yes. Professional indemnity insurance taken out in the name of OMBREMIMS, currently valid. The certificate reaches you together with the company registration extract and the URSSAF compliance certificate, on request - and before day one if your procurement team makes it a condition of entry. These are the three documents almost every client asks for: better to have them ready than to go looking for them the week you wanted to start.

It gets prepared, it does not get announced. A month before the end, I list what only lives in my head: the pending trade-offs, the people you need to know to make a call, and the reasons behind choices that left no written trace. Whatever is missing gets written where your team will go looking for it - in the backlog, in the repository, in your own tools - and not in a handover document nobody reopens. If there is a successor, we overlap: they run the ceremonies while I am still there to answer. The finish line is not my last day, it is the first trade-off made without me. An early exit, on the other hand, is not this question but the notice period.

Yes. People I worked with on the engineering application suite are happy to take a call. I hand over their details at offer stage, once the conversation is serious on both sides - not on the first message: a reference is not a document you hand around, it is a person whose time you are spending. What I ask in return is symmetrical, and I often ask first: to speak to whoever held the role before me, or failing that to the team. You learn more about an engagement in ten minutes with them than from the job description.

I do not ship an LLM feature without a reference test set written before development: around thirty real cases, each with the expected answer and the failure mode we want to rule out. We measure the share of acceptable answers, and the threshold is part of the story's acceptance criteria, not of some side report. I separate two kinds of failure, because they are not fixed in the same place: a wrong answer is addressed through the context we feed the model, an out-of-scope answer through the system prompt and the guardrails. Every regression seen in production joins the test set, which never shrinks.

In practiceSituation: a text generation feature that convinced in demos and disappointed in use. Task: make quality measurable before spending another euro on it. Action: a set of 40 real cases, a threshold of 85% acceptable answers written into the acceptance criteria, and every user report added to the set. Result: two iterations took the rate from 61% to 88%, and the team stopped arbitrating on gut feel.

I treat a hallucination as a product defect, not a technical incident: it has a frequency, a severity and a cost to the user, so it has a place and a rank in the backlog. I act in three places. The source: if the model has to state facts, it does not invent them, it reads them - that is what RAG is for, and I watch the coverage of the knowledge base more than the elegance of the prompt. The guardrail: an explicit refusal beats a plausible answer, and “I don't know” counts as a success. The interface, last: cite the source, allow correction, and on anything with real stakes, require human review and own it in the flow.

Three sliders on one budget, and it is a product trade-off. I start from the acceptable unit cost: what a call may cost for the feature to stay profitable at the price we sell it. Then tolerable latency, which depends on where you are in the flow - three seconds are invisible while a report is generated, unbearable in a search field. The most capable model is almost never the right one everywhere: I route simple cases to a small fast model and keep the large one for what justifies it. On build versus API, my criterion is explicit: we consume an API as long as the cost per call stays below the cost of running a model of our own.

I start from the problem, not the technology. An LLM earns its place when the input is free-form language and the cases cannot be enumerated: classifying incoming messages, extracting from a document whose layout varies, rewriting. As soon as the cases can be enumerated, a rule wins on every criterion I care about - deterministic, free, instant, testable. So I ask three questions: could I write the rule? is an error tolerable here? does the value justify a cost per call and a share of the unpredictable? And even when I go ahead, I often start with the rule anyway, keeping the model for what the rule misses: less spectacular, far more solid.

I set the rule before the first line of code, because afterwards it is rework. Three decisions. What leaves: which data crosses our boundary and under what contract - a vendor who reserves the right to train on our inputs is ruled out, not negotiated with. What is minimised: we send only what is needed, and most use cases do not need a name to work. What is retained: how long prompts and answers are kept, and who may read them back - a conversation history is a personal-data store like any other, and it is very often forgotten. These three points sit in the Definition of Done of every AI story.

In practiceSituation: an assistance feature was to consume customer conversations. Task: make it acceptable to security before building it. Action: a map of what actually left our boundary, removal of identifiers the use case did not need, a vendor contractually barred from training on our data, retention set to thirty days. Result: approval obtained in a single review instead of the expected back-and-forth.

An API is a promise made to code you do not control: breaking it costs more than what you would gain by fixing it. My default rule: add, never remove - a new field is optional, new behaviour is opted into. When a breaking change becomes unavoidable, it goes through a new version, both served in parallel, with an end date announced on day one and not on the day we want to switch the old one off. I look at who calls what before deprecating: without that measurement, a deprecation is a decision made blind. And the written contract and the changelog are deliverables of the story, exactly like the code.

In practiceSituation: an internal API consumed by five teams, two of them outside my scope. Task: change a response format that had become wrong. Action: a v2 opened in parallel, calls instrumented to learn who used what, end of v1 announced six months ahead, both external teams supported through it. Result: shut down within the announced window, with no outage at all on the consumer side.

The principle does not change - value, cost, risk - but the signals do. A developer does not fill in a satisfaction survey: they work around you. So I hunt for the workarounds: the homegrown script three teams each rewrote separately, the question asked ten times on the same channel, the step everybody skips. Each one is an unspoken request, and often the most profitable of the lot. I track time to first successful call for a team discovering the platform, because that is where adoption is won or lost. And I am wary of the internal-product trap: with no competitor, mandatory use passes for wanted use.

An API is a commitment that outlives the screen: you can redesign an interface on a Tuesday, you do not remove an API field on a Tuesday. So I look at who consumes it, and why. If a single team needs the data once, an export or a screen costs ten times less. An API earns its place when a third party wants to compose the capability into their own flow, when integration volume exceeds what a human would click, or when the capability must outlive the interface redesign. Publishing an API before knowing its consumers means buying a constraint without buying a user.

In practiceSituation: a data readout requested by two client teams. Task: decide between a screen and an API endpoint. Action: shipped the screen first, instrumented the exports, waited for the third request before opening a contract. Result: the API shipped three months later with a contract already written by real usage, and never needed a v2.

A quota is a product decision, not an ops setting. I start from the unit that actually costs: the call, the token, the row returned. A free tier has to let someone succeed once, otherwise it only drives people away. Paid tiers index on that same unit, and a hard limit protects the platform, not the invoice. A limit that is hit must return something actionable: which one, and when it resets. On abuse, I separate the accidental loop from the deliberate one: the first is a documentation defect, and it gets fixed in the documentation.

In practiceSituation: one endpoint whose cost per call was ten times the others. Task: stop the drift without closing access. Action: per-key quota, a 429 response carrying the reset time, and documentation naming what the call costs. Result: consumption divided by four in two weeks, without a single ticket, because the cost had become visible.

It is the product's first interface for a developer, and it is judged on one criterion: someone from outside makes a successful call without asking a question. Hence the order: a runnable example before the reference, errors documented as carefully as successes, and the contract generated from the source rather than retyped, otherwise it lies at the first change. Who writes it: the team, inside the story, never later. Documentation written after the fact describes what was built; documentation written with the story catches contract mistakes while they are still free.

In practiceSituation: an API consumed by three teams, documented on a wiki page updated twice a year. Task: bring the support load down. Action: contract generated from the code, runnable examples, an error catalogue, and documentation moved into the Definition of Done. Result: questions on the channel dried up, and two contract inconsistencies surfaced while writing it.

By what it saves, never by what it contains. Three families. Adoption: how many teams out of how many possible, and whether the curve is rising - a service catalogue nobody calls is a cost, not a platform. Friction: time to first successful call, share of requests settled self-service without us, number of round trips before a team is autonomous. Reliability of the promise: SLOs met, and above all a contract that stays stable over time. I deliberately leave out the flattering metric - the number of APIs published - because it rewards output rather than use. And I publish these figures to the consuming teams.

Never by memo: an imposed adoption produces surface compliance and a workaround six months later. I do three things. I make my path shorter than theirs - if integrating our service takes more effort than keeping their script, they are right to keep it, and that is my problem. I take a pilot team with a real need, support it myself, and its integration becomes the argument: one working example convinces better than a pitch. And I name what my platform does not do: the credibility of an internal platform is built as much on refusals as on promises.

In practiceSituation: two teams each maintained their own component where the platform was meant to consolidate. Task: obtain a migration with no hierarchical authority. Action: integration cost cut to a few lines, one pilot team supported end to end, and a published list of what the platform did not cover yet. Result: the second team migrated of its own accord after the first one had shown the way.

I change roles: during an incident, I do not arbitrate the engineering, I hold the communication and protect the aftermath. One channel, one voice: blocked teams need to know where to look, not to ask the same question five times. A status rather than a promise: what we know, what we do not, and when I will speak again - an announced deadline that is met beats an optimistic one. Then I protect the post-mortem: no personal blame, dated actions, and those actions enter the backlog at the same rank as features - otherwise they do not exist and the same incident returns.

You build what differentiates and buy what has become a commodity. But the real question is the second one: what it costs to maintain three years from now. A platform component is never finished. So I do not compare a price against developer days, I compare totals: integration, migration, on-call, and exit cost. That last one decides more often than price does. A component I can replace within a quarter is worth more than a cheaper one that locks me in, which is why I always isolate the vendor behind an interface of our own.

In practiceSituation: a team that wanted to write its own enterprise SSO. Task: arbitrate. Action: costed the three years including on-call and compliance, compared against a managed provider, and named what we would lose in control. Result: bought, with the integration isolated behind our own interface: the provider stays replaceable.

An internal platform where every request goes through its own team has already failed: it swapped a technical problem for a queue. So the measure that counts is the share of what teams do without us. Hence three reflexes: self-service before features, escape hatches documented rather than forbidden (a team that has to work around you will do it anyway, better to know how), and a contribution path so a team that needs something can add it. And the roadmap says out loud what the platform will not do, so nobody waits for it.

In practiceSituation: a platform team with a six-week queue. Task: cut the wait without hiring. Action: took the three most repeated requests and turned them into self-service, opened a reviewed contribution path, published the list of what we would not do. Result: the queue collapsed, and two teams shipped their own additions.

Like any product cost: against what it produces. I want cost per active user and per transaction, not the global invoice - a bill that rises because usage rises is good news, and without that ratio you cannot tell. Then I look for what costs without serving: environments left running, data kept by default, jobs running more often than needed. Those are short stories, highly profitable, easy to get accepted. Finally I name the threshold beyond which a feature is no longer profitable at the price we sell it: giving something up on the strength of a unit cost holds up in front of any steering committee.

In practiceSituation: an infrastructure bill that doubled in two quarters with nobody knowing why. Task: make the cost legible before trying to cut it. Action: cost per active user and per transaction, a monthly review, three short stories on dormant environments and data retention. Result: unit cost brought back below its starting level while usage kept growing.

By refusing two traps: the big bang, and a promise of value that does not exist. I do not sell a migration as a feature - I sell it on the risk it removes and the cost it avoids, with figures: end of support, recurring incidents, time lost, the invoice. Then I cut it so that every step is reversible: two systems in parallel, a progressive switch by population, rollback possible as long as the old one runs. A migration you cannot stop halfway is a bet, not a plan. I reserve a constant capacity rather than a dedicated sprint. And the definition of finished is decommissioning the old system, not commissioning the new one - otherwise you pay for both.

In practiceSituation: a platform at end of support whose replacement had no visible effect for the user. Task: secure capacity without promising functional value. Action: the cost of inaction quantified, reversible switches by population, a fixed capacity reserved every sprint, decommissioning written in as the definition of finished. Result: switch completed with no outage, and the old system switched off - so no longer paid for.

The cloud is not a change of hosting, it is a change of operating model: who pays, who gets woken at night, who is allowed to create a resource. So I do not start with the migration, I start with one real workload, small and reversible, and I let the team learn the bill, the identity model and the on-call on it. Training is a workload, not a session. And the success criterion at the start is not cost, it is autonomy: does the team deploy without us.

In practiceSituation: a fully on-premise team asked to go cloud within a year. Task: not fail on the first workload. Action: picked a non-critical internal service, gave the team its budget and its alerts from day one. Result: one workload in production within three months, and a team able to discuss the rest with figures rather than opinions.

It is a constraint that decides the architecture, so it enters the backlog before the design, not in a review at the end. I ask three questions of every feature that stores anything: which data, in which region, for how long. The answers become acceptance criteria, verifiable ones, not a policy line nobody rereads. And I write down what we will refuse to do: a compliance rule that has never blocked anything has never been tested.

In practiceSituation: a client requiring European residency for a feature that called a US model provider. Task: keep the feature. Action: identified what actually left the region, moved that flow to a European-hosted provider, documented the quality gap, and put the region into the acceptance criteria. Result: feature shipped, contractual constraint held, and the quality gap named rather than hidden.

Managed by default, and it takes a reason to leave it. The reason is rarely the price on the first invoice: it is a real constraint, residency, latency, or a capability nobody offers. Self-hosting is a permanent commitment, not an installation: patching, on-call, capacity, version upgrades. So I cost it as a recurring team cost, never as setup days. And I decide it with the people who will carry the pager, because they are the ones paying for the decision.

In practiceSituation: a database whose managed cost had tripled with volume. Task: decide. Action: measured what self-hosting would demand in operations time, put the question to the team concerned, and compared it against reducing the volume itself. Result: stayed managed, retention divided by three, bill down 40 % with no migration at all.

I make it an acceptance criterion and something I negotiate with the business. Reliability is not free: aiming for 99.9% or 99.99% asks for neither the same team nor the same budget. So I turn the question around: how much downtime per month is acceptable for this use, and what do we accept not building in order to get it. Once the SLO is set, the error budget becomes my best arbitration tool: while it is unspent we ship features; the moment it is exhausted, priority moves to reliability. And that switch is decided before the incident, not during it.

In practiceSituation: a team torn between feature requests and repeated incidents. Task: get out of arbitrating in the heat of the moment. Action: an SLO negotiated with the business, the error budget tracked in sprint review, and the switch to reliability written down before it was needed. Result: the “features or stability” question disappeared from meetings: it had already been settled.

By treating them as users of my product, not as a downstream service: what they live through at night is the direct consequence of my daytime trade-offs. I bring them into refinement as soon as a story touches reliability or volume, because the question “what does this do under load” is only asked well beforehand. I put what serves them into the Definition of Done - useful logging, actionable alerts, a rollback procedure - and I refuse to treat it as the bonus you cut at the end of a sprint. And I read their metrics as my own: a drowning operations team is a product signal.

By picking metrics you cannot improve by cheating, and by never reading them alone. Velocity in points does not leave the team: it is for planning, not for comparing, and it inflates within three sprints the moment it becomes a target. I prefer flow metrics - deployment frequency, lead time from start to production, change failure rate, time to restore - because they describe the system rather than people's effort. And I read them always in pairs: shipping more often is worth nothing if the failure rate climbs. Finally, I tell the team what I measure and why.

In practiceSituation: a management request to compare one team's velocity with another's. Task: provide a useful measure without putting teams in competition. Action: velocity replaced by four flow metrics read in pairs, published openly to everyone, with an explanation of what they do not measure. Result: comparison between teams stopped, and the two useful conversations began.

Like everything else: through what it changes for someone. A pipeline that takes forty minutes costs the team several breaks in attention a day, and that is a number. So I refuse the backlog's technical bucket, because a separate bucket is the bucket you cut first. These subjects are written as stories with an observable effect and prioritised against features, on the same board. What I do not do: promise them for a later sprint, which never comes.

In practiceSituation: a 42-minute integration pipeline, releases batched to Friday. Task: raise deployment frequency. Action: wrote the pipeline as three stories with a measured target, prioritised against features, and showed the frequency curve at every review. Result: 11 minutes, and deployment moved from weekly to daily.

I do not weigh debt against features, because framed that way it loses every time. I weigh an effect against an effect. Debt with no observable cost waits, and I say so. Debt that shows up in lead time, in the change failure rate, or in what nobody dares touch any more becomes a story, with that indicator as its acceptance criterion. And I hold a standing share of capacity rather than renegotiating it every sprint: a share you renegotiate is a share you lose.

In practiceSituation: a test suite so slow that nobody ran it locally any more. Task: bring it back into the loop. Action: named the effect (defects found at review rather than at commit), took a standing share of capacity, and split the suite. Result: the suite back under three minutes locally, and the rework rate at review down.

I resist the average, which satisfies nobody. In B2C the user decides in thirty seconds and the product has to explain itself. In B2B, whoever pays is not whoever uses it, the cycle is long, and a regression costs a contract. In practice I keep a shared core - functional heart, authentication, billing - and two surface layers. On prioritisation I weight B2B by committed revenue and B2C by volume and learning value, which makes them comparable without conflating them. And I name the requests that serve a single customer: they get quoted or declined, but they do not pass themselves off as product features.

In practiceSituation: a product sold both self-serve and on annual accounts. Task: a roadmap that is not renegotiated at every signature. Action: a shared core split from two surfaces, prioritisation weighted by committed revenue on one side and volume on the other, and a named line for single-customer requests. Result: the roadmap stopped being reopened at every contract, and bespoke work found a frame instead of a free pass.

Far more than people think, which is why I refuse to let pricing be decided away from the product team. A tier is a technical boundary: the moment an offer exists, you must know who is entitled to what, check it on every call, handle moving between tiers, pro-rata, failed payment, downgrade. That is backlog work, not a communication decision. So I weigh packaging against its build cost: three well-drawn offers beat seven that force an entitlement system nobody will maintain. And monetisation metrics belong in the same reviews as usage metrics.

I refuse to treat it as an end event: by the time a customer cancels, the decision is long made. So I look at churn by cohort and by tier, because a global rate says nothing - losing free trials and losing annual accounts are two different problems. Then I look for the earlier signals: usage frequency dropping, a key feature never reached, an incident lived through. The most profitable lever is almost always activation: a user who never reached their first value will not be retained later. And I let those who leave talk, without trying to win them back in the conversation.

In practiceSituation: a cancellation rate that looked stable and hid two opposite behaviours. Task: find out where to act. Action: a split by entry cohort and by tier, one onboarding step identified that leavers never crossed, and that single step redesigned. Result: the next cohort crossed it twice as often, and its three-month retention followed.

Around a single question: what is the first value, and how long the user takes to reach it. I name it explicitly - not “having created an account”, but the first moment the product did something for them. Then I count the steps in between and remove some without negotiating: every field asked for before the first value is paid for in drop-offs. I defer everything that can be deferred, I prefer a default to a choice, and a pre-filled example to a blank page - an empty screen is the worst first impression a product can give.

In practiceSituation: a sign-up in five screens before any use at all. Task: shorten it without losing the information we needed. Action: the first value defined explicitly, three requests deferred past that moment, a pre-filled example in place of the blank screen. Result: the share of sign-ups reaching first value went from 34% to 58%.

As a design constraint, not a document to produce. Three things live in my backlog. The register of what we collect: every field has a purpose, and a field without one gets deleted - which is also the best way to simplify a product. Data subject rights made executable: access, export and deletion must be features rather than tickets handled by hand. And the retention period, decided per data type and applied automatically - infinite retention by default is the most common case and the least defensible. I also keep the list of sub-processors and of what leaves the EU: that is exactly what a B2B buyer will ask for.

The Scrum Guide does not know this title, and that is the first thing to say: "Technical Product Owner" is not a Scrum role, it is a way of holding the Product Owner one. The role itself does not move - the order of the backlog, the value, the decision on the what. What changes is the ground the trade-offs land on. A generalist Product Owner arbitrates between features; across the six domains I take on - AI & GenAI, API, Platform, Cloud, DevOps, B2B & B2C SaaS - half the trade-offs do not have the shape of a feature: an answer-quality threshold, an API end-of-life date, an error budget, a cost per active user. These are product decisions written in technical vocabulary, and they get made badly when it takes three meetings to understand the question. That does not mean I code your product - that boundary sits higher up, under "The engagement". It means I read an API contract, a latency table or a cloud bill without an intermediary, and that I know what a yes costs.

The three do not overlap, and it is precisely when all three are in place that you see it. The Product Manager owns the why: strategy, the market, the overall lifecycle, often across several teams or products. The Scrum Master owns the how: they facilitate Scrum, remove impediments, protect how the team works. The Product Owner owns the what - and above all the in what order: turning a market intention into an ordered backlog whose every item is clear enough to be picked up tomorrow morning. What I add to that particular setup is someone who decides, and who is there at the moment a decision is needed: a Product Manager stretched across four products has no time to settle a refinement disagreement, and it is not the Scrum Master's job to do it in their place. When that seat is empty, the backlog is not what suffers first - it is the delay between a question and its answer.

Professional Scrum Product Owner I (PSPO I), awarded by Scrum.org. It is the assessment that requires 85% correct answers, with no mandatory training beforehand, and that never needs renewing: it does not expire and does not have to be bought again every two years. What it proves is precise and limited - that I know the Scrum framework as written, and what it says about maximizing value and the total cost of ownership of a product. What it does not prove is that you can make trade-offs under pressure: no multiple-choice test measures that, and that is what the rest of this page is for.

No SAFe train and no PI Planning, and I am not going to pretend otherwise. What I did hold is another shape of the same problem: five interconnected applications, a team of eight, and one data reference model shared by all five. The hard part of a scaled environment is not the ceremony, it is dependency - a decision made inside one perimeter breaks the one next door, and nobody notices before production. I took two rules from it that I still carry: the list of consumers on every story touching shared ground, and one person per application in the group that signs off. If your organisation runs SAFe, I fit into it without difficulty: that is not where the work is.

Yes, both, and daily: ceremonies, backlog and specifications in English, with people who are neither on the same site nor in the same country. TOEIC 945/990, level C1 - but a score says what you understand, not what you can hold in a review where two people disagree. What being distributed really changes is not the language anyway, it is that the corridor no longer exists: what used to be settled in thirty seconds standing up has to be written down, and a badly written story no longer costs a question, it costs a time zone. So I write more, and I decide less in meetings.

I build the product vision by combining market research, user feedback and company objectives. I draft an initial product backlog that embodies that overall vision. Then I build a roadmap - a development plan across several releases - detailing the features that will deliver the most value. I lean on product discovery workshops (benchmarks, prototypes, customer interviews) to establish value hypotheses. The roadmap stays flexible: it is reviewed regularly, quarterly for instance, with the steering committee and the team, so we can adjust course based on what comes back from the field.

I prioritize by weighing customer value, business impact, development effort and timing. I use agile prioritization frameworks - RICE or MoSCoW - to make my choices objective. With MoSCoW for example, I sort features into Must have (essential to the MVP), Should / Could have (important but secondary) or Won't (not for this release). In practice, I run a backlog workshop with the team and stakeholders, where we assess items on return on investment and business urgency. I also make a point of keeping the chosen criteria transparent.

In practiceSituation: on an e-commerce product, the team wanted to build an advanced chatbot while mobile traffic was falling. Task: decide between improving the mobile app or building the chatbot. Action: I ran a workshop with the data scientists and marketing, where we estimated the ROI of each option. Result: we reworked the mobile experience first; mobile sales rose by 15%. The chatbot followed.

Technical debt is not a taboo: I put it in the backlog as stories. I assess its impact - bug risk, slowdown, architectural debt - and its effort. I deal with it continuously: if the team finishes a sprint early, we pull in a refactoring or dependency-upgrade story. I also make the implicit cost of that debt visible to stakeholders: future refactoring, security, performance. If a critical item threatens the release, it goes to the top of the backlog. For the rest, I reserve 10 to 20% of each sprint for debt.

The MVP is the simplest version of the product that can validate a business or user hypothesis. It contains only the features that deliver immediate value. To define it, I list every possible need, then isolate the ones that are indispensable to solving the customer's core problem. I then assemble a minimum prototype to test. On a delivery app, the MVP was limited to item search and the cart, with no complex payment module. Launch early, correct course on the first feedback, add the secondary pieces afterwards.

A good backlog item meets the INVEST criteria: Independent, Negotiable, Valuable, Estimable, Small, Testable. For example: "as a user, I want to sign in with Google so I can reach my account faster". It must carry precise acceptance criteria. I write them with the developers, to be sure they understand the business goal. I also break oversized stories into sub-stories of one to two days of work: the backlog stays transparent, and both estimation and tracking become possible.

In practiceOn a telecom product, one user story read "build a customer portal". Far too vague. I reframed it into several concrete stories - sign-in, dashboard, invoice management - each with clear acceptance criteria. The team could then estimate and plan every story precisely.

Under Scrum, once the sprint has started, the sprint backlog must stay stable. If a requirement changes, I first assess how critical it is. If it truly is urgent - a blocking defect, say - I consult the Scrum Master and the team to weigh the impact. We usually put two options on the table: absorb the change if the urgency is critical, or schedule it for the next sprint. The point is not to deviate from the running sprint unless it is vital. Then I explain to stakeholders why we are holding or changing the sprint, and we adjust the plan together. That is the Agile spirit: adapt quickly when needed, but with transparency and the whole team's agreement.

In practiceMid-sprint, a regulatory change forced a new data field on us. After talking it through with the developers and the sponsor, we slotted an impact-study task in at the end of the sprint - a spike. The developers clarified the technical need without compromising the planned stories, and the regulatory story entered the next sprint.

I keep communication with the developers constant. I take an active part in weekly refinement: I walk through each user story, answer questions and collect technical feedback. I often use user journey maps or prototypes to make the need concrete. During dailies, if a grey area surfaces, I clear it up on the spot. What works is an open dialogue: I take their criticism on whether a spec is viable, and I make sure they understand the end user. If a developer finds a story poorly defined, we take a short pairing session on it. The result: every story pulled into a sprint is clear to both sides, which cuts down on rework. I also share the vision and objectives at kick-off, then restate them at sprint planning and review, with a dashboard everyone can see.

In practiceOn a mobile project, some developers could not see the end use of a feature. So I ran an internal demo: I walked through a complete application scenario in a wireframing tool. That context made the goal clear, and the team shipped the feature matching the business need exactly.

I use Jira for the product backlog and user story tracking: I create the tickets, add acceptance criteria and organize the sprints. Confluence serves as central documentation - product vision, user documentation, retrospectives. For sharing ideas and mockups quickly, I use Miro in brainstorming or user story mapping workshops. A dedicated Slack or Teams channel carries the daily exchanges with developers and stakeholders. Each sprint, I also send out a release summary: cross-team communication does not happen by itself.

Before sprint planning, I make sure the user stories are ready - clear and estimated. During the meeting, I present the proposed Sprint Goal along with the matching stories. I let the team estimate and question each story. We decide the sprint capacity together, based on the previous velocity. I do not try to overload it: I trust the team to judge its own workload. If estimates shift during planning, I re-prioritize on the spot to stay consistent with the goal. At the end, the team and I commit to the sprint backlog together.

I draw on Design Thinking, Lean Startup and UX research. I run co-creation workshops with users to surface the key features, and I use low-cost prototypes to test hypotheses fast. I also set up surveys and customer interviews to understand the real needs. Where possible, I measure whether a feature is worth building through an MVP: a beta release to a small group of users, whose feedback then drives prioritization or adjustment before we build at scale.

In practiceOn a fintech project, I used a Lean Canvas to capture the key hypotheses, then built a simple prototype of the payment flow. User testing revealed that the confirmation button was hard to spot. We fixed the prototype before writing a single line of code: several days of development saved on what was a design problem.

I pick KPIs aligned with the product's objectives. Depending on the context: adoption rate (active users), revenue generated, revenue per customer, satisfaction and NPS, conversion rate, or lead time to delivery. On a SaaS product I tracked MRR and churn rate; on an e-commerce site, add-to-cart rate and average basket. I set these metrics at launch, then review how they move at every sprint review. They are what drives my prioritization calls - if conversion is low, the features that improve it move up the backlog.

I build regular feedback loops. After each release, I collect responses through NPS surveys or interviews. I also mine support tickets to spot recurring problems. I then convert that feedback into backlog items: fixes, UX improvements, new requests. At sprint reviews, I sometimes invite real users or key customers so they can see progress and react live. The roadmap evolves with the voice of the customer, not against it.

In practiceOn an e-commerce site, session recordings and user surveys showed the checkout flow was confusing. I added a story to simplify it into a single-page form. Cart abandonment dropped by 25%.

Faced with a disagreement, I listen first to the stakeholder's point of view, to understand what is driving it. Then I look for a way to align that need with the product vision. I often bring hard data - user research, ROI - to back my prioritization choices. If a sponsor demands an urgent feature, I explain the impact on the plan and offer a compromise, such as a simplified MVP. My aim is a win-win outcome: bring the request in early, or schedule it later. I stay transparent and open to discussion, and I uphold the Scrum framework - ultimately, only the Product Owner decides the backlog.

In practiceSituation: a VIP customer wanted a custom module that had not been planned. Task: decide whether to take it in mid-sprint. Action: I brought the team and the customer together, laid out the impact on the running sprint, and proposed a pilot once the sprint closed. Result: the customer agreed to defer the request in exchange for an immediate fix. The team delivered its sprint, and the module shipped in the following release without overload.

On a B2B product, sales were falling and the team wanted to add a large feature requested by a single customer. I had to choose between serving that customer and strengthening a more strategic capability. I ran the numbers: the new request meant three months of development for 5% of potential revenue, whereas improving the customer funnel would lift sales across the board. I went with the second option. To handle the customer, I explained our strategic priority and offered a complementary module on the roadmap. In the end, overall sales grew by 12%, and the customer got an early prototype to test.

I keep communication transparent and regular. I share the product vision and objectives at kick-off, then restate them at sprint planning and review. I use a dashboard visible to everyone so anyone can follow progress. I write a monthly summary of the key achievements, and I run a demo of the delivered increment at every sprint review: that is the team's chance to present its work and the stakeholders' chance to ask questions. Internally, I encourage the team to challenge the vision - that is what keeps it invested.

I present a quantified cost-benefit analysis. On one side I assess the investment - development, marketing. On the other I project the gains: additional sales, retention, time saved. If I am proposing an improved search engine, I estimate the conversion lift and translate it into euros per year. I also show the strategic fit: how it strengthens our position in the market. Where possible, I lean on A/B tests or industry benchmarks. The goal is to translate a feature into concrete impact, not to argue that it would be nice to have.

In practiceAt a roadmap review, I made the case for a personalized product recommendation engine, estimating at least €100k in additional quarterly revenue, backed by industry benchmarks. The analysis convinced the investment committee; six months later, we measured +15% in sales on the targeted segment.

Eight years at GTT, on a suite of five engineering web applications interconnected by API, built around ship and LNG tank data. A team of eight: four developers, two QA, one business analyst. What makes a product like that hard is not any one feature, it is the coupling: five applications read the same reference data, so a decision taken in one is paid for in the other four. Most of my work there was holding an order - which application moves, which one waits, and what we refuse to duplicate for the sake of speed. One particularity of that ground: the users were engineers, not anonymous customers. They knew exactly what they wanted, which makes framing faster and trade-offs far harder.

A change to the ship-data reference store. I had framed it with the team that asked for it, and validated it with them alone: the change was right, and it was small. It broke reads in two of the four other applications, one of them in use that same day. What I had missed was not the decision, it was the scope of the conversation: on a shared foundation, your counterpart is never the team making the request, it is every team that reads. Two rules since: any story touching the reference store carries the list of applications that consume it, and it does not ship without a pilot group of one person per application - not a committee, just someone who will say "this breaks on my side"; and I watch the consumers' usage metrics after the switchover, not just the story's test.