Gartner reports that 85% of organisations have adopted, or plan to adopt, a product-centric application delivery model (Gartner, 2019). Most of them have changed how they talk about the work. Very few have changed how they fund it, how they hold teams accountable for it, or how they decide what belongs on the backlog, so the vocabulary has shifted while the model behind it has not.
In Brief
- Gartner reports that 85% of organisations have adopted or plan to adopt a product-centric application delivery model.
- The declaration changes nothing unless funding, team accountability, and backlog ownership are redesigned together.
- Annual project budgets treat products as finite work parcels; persistent team funding is the first structural shift.
- Team accountability moves from delivering scope to owning outcomes across the life of the product.
- Backlog ownership belongs to one product manager with the authority to say no, not a steering group.
That gap is where the value quietly leaks out. An executive can restructure the delivery organisation into product teams, rename portfolio committees as product councils, and issue new titles across the technology function, and eighteen months later find that release cycles have not shortened, cost per outcome has not improved, and the same escalations arrive on the same desks. The reason is structural. Product-centric delivery is not a naming convention; it is a funding decision, an accountability decision, and an ownership decision made simultaneously, or not made at all.
Three decisions carry product-centric delivery
Every operating model is held up by a small number of load-bearing decisions. For product-centric delivery, three of them do most of the work: how the organisation funds the teams, what the teams are accountable for, and who decides what the teams work on. Change any one of these in isolation and the rest of the system will pull the change back. Change all three, and the model actually shifts.
The reason this pattern is easy to miss from the inside is that each decision belongs to a different governance conversation. Funding sits with the CFO and the investment committee. Accountability is the operating executive’s remit alongside HR. Backlog ownership lives inside the product function and delivery leadership. Three separate forums, on three separate calendars, answering to three separate authorities. The declaration to move to product-centric delivery lands in each of them at a different velocity, and the two that move slowest determine what the organisation actually becomes.
Persistent funding replaces project envelopes
Most organisations still fund the technology function the way they fund construction: as a portfolio of projects, each with a business case, an approved envelope, and a defined end. That funding model rewards estimation, scope management, and closure. It punishes iteration, discovery, and the disciplined choice to abandon work that is no longer worth doing. When the funding model treats every stream of work as a finite parcel with a fixed budget and a defined end date, the teams that receive that money have to behave like projects, whatever their new title says.
Product-centric delivery requires persistent funding of the team, not periodic funding of the work. The unit that gets funded is the standing team attached to the product; the review is quarterly against outcomes, not annual against scope. BCG’s platform operating model analysis frames this shift plainly: persistent, outcome-linked funding is what allows a team to invest in the boring, unglamorous work that produces durable value, including reducing technical debt, improving reliability, and retiring capabilities that no longer earn their keep (BCG, 2023). None of that work has a business case in the classical sense, and all of it is essential. BCG’s data makes the point plainly: most of the next technology dollar funds coordination rather than build. Persistent funding is what buys the coherence that project envelopes cannot.
The CFO is not the obstacle here. The obstacle is that no one has offered the CFO a governance mechanism strong enough to replace the annual capital cycle. Persistent funding without outcome accountability is a blank cheque. Persistent funding paired with a quarterly business review, an outcome scorecard, and a clear rule for reallocating funds away from teams that are not producing value is a control the CFO can defend.
Outcome ownership replaces scope ownership
The second structural shift changes what the team is on the hook for. Under the project model, the team is accountable for delivering an approved scope on time and within budget. Under a product model, the team is accountable for the outcomes that the product exists to produce: activation rates for a public- or customer-facing platform, cost-to-serve for an operational one, throughput for an internal one. The distinction matters because it changes what the team is allowed to decide.
A team accountable for scope has to protect scope; the definition of success is fixed at the start and defended through delivery. A team accountable for outcome has to interrogate scope continuously; the definition of success is the outcome, and everything else, including features, sequencing, and effort, is negotiable in service of it. Thoughtworks describes this as cross-functional, self-organising teams responsible for the flow of work from idea to value, not for the completion of a scope document (Birds, 2023). What the team is producing is a result, not a plan.
This shift changes what the operating executive receives at review: not a percentage-complete against a Gantt chart, but a movement in the outcome metric and an argument about what will move it next. Executives who have run programs know this rhythm from the delivery side; the shift required is that the same rhythm becomes the accountability contract rather than a side conversation beside the contract itself. Where AI programs are involved, this shift is the difference between running an AI initiative as a project and running it as a product.
One product manager owns the backlog
The third structural feature is the least glamorous and the most often skipped. Under a project model, the backlog is a shared artefact, a wish list negotiated between the sponsor, the steering committee, and the delivery lead, with priority set by whoever has the loudest voice in any given month. Under a product model, the backlog belongs to one person: the product manager accountable for whether the product succeeds in the world. That person decides what goes in, what comes out, and what order the team works on things. Every other stakeholder can request, argue, and escalate, but the decision is the product manager’s.
This is where the organisation feels most of the pain of the transition. Committees do not enjoy losing decisions, and sponsors do not enjoy hearing no from someone junior to them. The structural point is that the backlog is not a stakeholder-management artefact; it is the mechanism by which the team stays focused on the outcomes it is accountable for. Alvarez and Marsal make the same argument about product and platform models more broadly: value is generated when a single accountable owner decides what the standing team does with its persistent funding, and when that decision is protected from routine reversal by executive committees (Bombardi et al., 2026).
If accountability sits with a committee, the committee will change the priorities, and the team’s outcome accountability becomes rhetorical. If it sits with a role that cannot say no, such as a delivery lead who reports into a portfolio governance board, the backlog is not owned; it is administered. Genuine backlog ownership is the structural signature that the model has actually changed.
The three decisions reinforce one another
The three decisions are load-bearing individually and reinforcing collectively. Persistent funding gives the team the horizon it needs to invest in outcome-shaping work. Outcome accountability sets the standard against which the team’s choices are measured. Single-owner backlog authority is how those choices actually get made. Remove any one and the other two stop working. Outcome accountability sitting on top of annual project funding will run out of runway before it has anything to show. Persistent funding with a committee-run backlog will drift, because the committee will not defend the outcome against its own preferences. A strong owner with no outcome accountability will optimise for whatever is easiest to ship.
The Gartner statistic is not evidence that most organisations have made the transition; it is evidence that most organisations have declared it. The executive who has told the board that the organisation is moving to product-centric delivery is in a strong position, because the intent is right, the direction is defensible, and the underlying evidence base is sound. The next conversation the executive can put to their own leadership team is narrower and more actionable than the strategic question that got them here: which of the three structural features have we actually changed, and which are we still running on the project model. The executive who names which of the three has not yet changed is further along than the one who decided the declaration was enough.
References
- Birds, A. (2023, December 12). How to create a product operating model to support product organization transformation. Thoughtworks.
- Bombardi, M., Crowe, J., Vera, R., and Teixeira, F. (2026, February 18). Product and platform models: The operating model enterprises need to scale technology and generate recurring business value. Alvarez and Marsal.
- Boston Consulting Group. (2023, September). How a platform operating model can drive agility and resilience. BCG.
- Gartner. (2019, February 19). Gartner survey finds 85 percent of organizations favor a product-centric application delivery model [Press release]. Gartner.
