As Product Owner, I am accountable for the value the team delivers. My role is to define the product vision, manage the product backlog (items, prioritization) and communicate with every stakeholder. Concretely, I write and order the backlog's user stories, making sure they are clear to the team, and I set the release goals. I represent the voice of the customer, and I make sure decisions are understood and respected across the team.

In practiceSituation: on a previous project, the product was drifting away from the initial strategy. Task: rework the product vision with leadership. Action: I ran a workshop with the steering committee to clarify the roadmap and refocus backlog priorities on business objectives. Result: the team realigned its work, and the refocused product saw customer satisfaction rise by 30%.

The Product Owner owns the what: they define and prioritize the backlog to maximize product value. The Product Manager has a broader remit, often spanning several teams or products; they focus on long-term strategy and the full lifecycle - the market why, competitive watch, marketing. The Scrum Master owns the how: they facilitate Scrum, remove impediments and help the team get more effective. In short: the PO is the link to the business and the customer, the PM carries the overall roadmap, the SM protects how the team works.

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%.

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.

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.

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.

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.

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.

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.

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 PO 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.

I led the development of a personal finance mobile app. I started by running workshops with end users to establish the vision. I then wrote the product backlog and organized the releases by value: expense tracking, budgets, savings guidance. Throughout, I ran the sprint reviews. At launch we recorded an NPS of 70, doubled sign-ups in three months and cut churn by 15%. Stakeholders judged that the roadmap had contributed strongly to business value - +20% in recurring revenue.

On a previous project, we shipped a customer chat feature without validating it first. Users were lukewarm and usage stayed low. I had misjudged the real need and rushed the prototype. In the post-mortem, I identified that I had not done enough user testing before going to production. I took two rules from it: always run a pilot group before any general rollout, and put usage metrics in place from the very next sprint. The features that followed were far better aligned with what customers expected.