The product owner has a title; the decisions sit elsewhere
This retrospective analysis of 2019 was written and published in 2026. It distinguishes a product organisation from a mere change in vocabulary. The narrative, names and amounts are educational, with no reference to a CYTIZEN engagement. A product team is not presented as the mandatory answer to every IT need: some investments remain better managed as programmes with an explicit end.
Hugo becomes product owner of the customer platform. His title changes, but the budget remains allocated to three annual projects. The supplier delivers planned features; support inherits incidents; a new team prepares the following year. Hugo cannot change contractual priorities or correction capacity. He manages a backlog but does not own the decision about the outcome.
The business requests a simple journey for tracking a complaint. The team adds a screen, then an interface. Response time does not fall because approval still depends on a shared mailbox and an absent manager. Moving to a product model should make it possible to sustain that journey over time. Renaming projects preserves their fragmentation while adding a promise the organisation cannot fulfil.
Draw a boundary around a useful service
A product is not defined solely by an application. The customer platform covers a journey, a population and an outcome: enabling customers and agents to track and resolve a complaint. It has boundaries with finance, logistics and identity. These dependencies are negotiated; they do not disappear because a team calls itself autonomous.
Hugo and the sponsor specify users, expected operations, channels and service conditions. They state what the team directly owns and what it obtains from other teams. An objective to reduce response time must include relevant business approvals. Otherwise the product becomes a digital façade in front of an unchanged process.
The boundary can evolve, but every extension has a capacity and responsibility cost. Adding contracts, marketing and billing to the same product because they concern customers would make the mandate unreadable. A well-defined interface between teams is better than a gigantic scope no owner can control.
Give a mandate before demanding results
The sponsor authorises Hugo to prioritise agreed quarterly capacity between journey improvement, correction and service maintenance. Limits are explicit: new commercial commitments, significant exposure, data-policy changes and investment above the ceiling require dedicated decisions. The product owner receives no authority to bypass security, procurement or quality.
Capacity is allocated to a stable team with the skills needed to understand, build and operate the service. Specialists can be shared, but their availability is planned. Stability does not require retaining every individual indefinitely; it requires responsibility and knowledge to survive each budget closure.
Hugo also has an escalation route. A finance dependency blocks a journey change; the sponsor can bring both owners together and choose a common priority. Without that mechanism, autonomy becomes a word that leaves the team alone facing impossible decisions.
A concrete product charter
| Field | Content |
|---|---|
| Population | Active customers and customer-service agents in the two pilot countries. |
| Outcome | A complete complaint, tracked, resolved and explained to the customer. |
| Measure | Time from an admissible case to a validated response; difficult cases retained. |
| Capacity | Six-person team, plus agreed finance and security slots. |
| Delegated decisions | Backlog order within approved capacity and scope. |
| Escalated decisions | New contractual commitment, unaccepted risk or dependency between products. |
| Operations | Named support, procedures, hours and major-incident threshold defined. |
| Review | Monthly for outcomes; quarterly for capacity and investment. |
| Retirement | Case export, retention and transfer of responsibility planned. |
Fund the outcome without erasing commitments
The team receives a funding envelope rather than a blank cheque. The investment case explains the outcome, assumptions, recurring costs and limits. The quarterly review can maintain, reduce or increase capacity. It compares what users actually receive with what was expected; it does not reward only the number of features delivered.
In the scenario, the quarterly budget is €300,000, including €80,000 for maintenance and mandatory corrections. The balance does not automatically represent new value: integrations, data and experiments may be necessary. Hugo describes choices, including an improvement requiring no development that removes a redundant internal approval.
Supplier contracts are examined accordingly. If a provider is committed to fixed scope, changing the backlog may require a change process. Moving to a product model does not invalidate a signed contract. Procurement and the programme organise the commercial transition and delivery responsibilities. Some work packages remain precisely planned and contracted within lasting product responsibility.
The backlog must include what keeps the service working
The backlog, a prioritised work list, includes recurring incidents, technical debt, data, risks, procedures and user requests. The team makes these categories visible so discussion does not focus solely on new screens. A data correction may contribute more to the journey than a new dashboard.
Hugo distinguishes obligations, demonstrated improvements and learning hypotheses. For each hypothesis, he specifies what could invalidate it. In complaint tracking, the team thinks a notification will reduce calls. It measures status-related calls over a defined scope, then tests the notification with users. If calls mainly concern the substance of the decision, notification is not the problem.
Priority criteria include impact, urgency, risk, effort and dependencies. They are not reduced to a formula that mechanically decides on behalf of the business. A necessary security requirement may take precedence even when its immediate commercial benefit is hard to count.
Going live is no longer a parcel handover
The team that builds prepares support and observes usage. It does not simply hand incidents to another structure while declaring the project finished. The service manager and product owner divide operations and evolution: hours, capacity, procedures, detection, recovery and decision-making are known.
A new journey version is tested with future permissions. Launch conditions include monitoring, case reconciliation and the ability to roll back. Support reruns an error without an available developer. User feedback is linked to the backlog with its source and frequency; not every comment automatically becomes a feature request.
Hugo discovers that some responses await finance approval. He cannot solve that constraint alone. The dependency review chooses a rule for simple cases, a substitute contact and an escalation mechanism. Product improvement then combines data, organisation and software. It produces an outcome that work on screens alone lacked the authority to achieve.
Measure an outcome without confusing speed and value
Response time is measured on comparable cases, from admissibility to validated response. The median and longest cases are presented together. The reopening rate counts cases revisited because the answer did not solve the problem, distinguishing new facts. The proportion of agents using the intended journey informs adoption, but cannot alone establish service quality.
Deployment frequency can help the team examine technical capability. It does not prove complaints are handled better. Service cost includes building, maintenance, suppliers and business work. The sponsor may consider a costlier improvement worthwhile if it protects customer relationships or reduces risk, but that choice must be explicit.
In our example, the team revisits priorities if exceptionally long cases remain unchanged despite an improved median. This is not a universal threshold. The review asks which populations or exceptions are being left behind, then decides whether addressing them fits the product’s mandate and capacity.
Do not impose the same model on every context
In pharmaceuticals, software changes may be subject to validation and change-control requirements. A stable team supports knowledge but does not remove those requirements. The backlog and schedule provide for necessary evidence; a high delivery frequency is not an independent objective.
In banking, the mandate includes permissions, risks and dependencies with control functions. A product owner does not become the owner of every risk they influence. In manufacturing, some platforms serve several sites with different windows. Common standards and local needs are arbitrated with site responsibilities rather than solely by arrival order in the backlog.
A carve-out or migration with a contractual date may retain dedicated programme leadership. The product provides lasting responsibility after the event, while the programme organises temporary dependencies and the milestone. Both arrangements can complement each other; opposing them on principle distracts discussion from real responsibilities.
A change of title becomes a change of system
The sponsor begins with a pilot product and verifies three things: someone can genuinely prioritise, a team retains responsibility for the service, and a review can change investment according to results. If any one is missing, Hugo risks owning an objective without the means to achieve it.
Moving to a product model can take time for budgets, contracts and interfaces. It must make those stages visible. The organisation does not need to declare all its IT “product” to improve the complaint journey. It needs an exercised mandate, available skills and an outcome the team can follow beyond the first launch.
Sources and method
Official pages are consulted in their current 2026 version and illuminate governance and service responsibility. The charter, funding envelope and narrative decisions are original. The analysis does not turn British administrative standards into obligations for a private company and does not promise systematic economic improvement from the product model.
- GOV.UK — Governance principles for agile service delivery
- GOV.UK — Have a multidisciplinary team
- GOV.UK — How to set performance metrics for your service
Links verified on 4 October 2026. The scenarios and thresholds proposed in this dossier are educational; they describe neither a client engagement nor a result achieved by CYTIZEN.