The product operating model: budget, teams and metrics

In many IT organizations, work arrives as a project. Someone approves a budget, a team is assembled, a scope is delivered by a date and the team disbands. What was built is handed over to "operations", which receives it with incomplete documentation and no budget to improve it. The following year, the next enhancement to the same system is another project, with another team that relearns what the previous one already knew.

The product operating model starts from a different question. Instead of "which project do we fund this year?", it asks "which services does the business need, and what stable capacity is required for them to improve continuously?". The unit of work is no longer the temporary initiative but the product or service, with a team that builds and runs it throughout its life.

This article explains what changes on three fronts (budget, teams and metrics) and how the model fits with practices you already have, such as ITIL and the PMO. It is not a renaming exercise: if budgets and metrics stay project-based, teams will too.

From projects to products: what changes

A product, in this context, is not necessarily something you sell. It can be mobile banking, the loan origination engine, the internal payments platform or the identity service other applications rely on. What defines it is that it has identifiable users, value that can be measured and a long life that does not end with the first release.

The diagram summarizes the four differences that matter most in practice.

To be clear: projects do not go away. A data center migration, a regulatory change with a fixed date or the rollout of a new system still have a start and an end. What changes is that they stop being the default way to organize all IT work.

Budget: fund capacity, not initiatives

In the project model, each initiative competes for funds with a business case that promises a scope. The budget is approved once a year, scope is frozen so it can be estimated, and anything learned later becomes a change request that must be approved again. The incentive is to ask for everything up front, because getting more later will be hard.

In the product model, you fund the persistent capacity of a team, or a group of teams, assigned to a product or value stream. The governance question shifts from "was the promised scope delivered?" to "is this investment moving the outcomes we expected?".

This is not a blank check. A reasonable scheme includes:

• Periodic reviews, for example quarterly, where each product shows outcomes, the plan for the next cycle and risks. Capacity can be increased, reduced or shifted between products.
• Agreed outcome targets with the business owner: fewer drop-offs in a customer journey, shorter response time in a process, fewer incidents in a critical service.
• A separate reserve for one-off initiatives that really are projects, each with its own business case.
• Visibility of the product's total cost: team, infrastructure, licenses and support, not just development.

One point to settle early with Finance is accounting treatment. Many organizations capitalize software development by project, while a stable team mixes new work, enhancements and operations. How each type of effort is recorded depends on the applicable accounting standard and internal policy; do not decide it from IT alone.

Teams: stream-aligned, platform and enabling

A product team is stable, cross-functional and accountable for its service end to end: building, deploying, running and improving it. Stability is not a detail. A team that stays together accumulates knowledge of the domain, the code and the users, and that knowledge is what allows it to change things quickly without breaking them.

The Team Topologies approach offers a useful vocabulary for designing the structure. It proposes four team types:

• Stream-aligned: works on a flow of value for a group of users. It is the primary type; the others exist so this one can move with less friction.
• Platform: provides internal services (environments, deployment, observability, databases) that stream-aligned teams consume through self-service.
• Enabling: temporarily helps other teams acquire a capability, such as test automation or security practices, and then steps back.
• Complicated subsystem: owns a component that requires highly specialized knowledge, such as a risk calculation engine.

The same approach defines three interaction modes between teams: collaboration, X-as-a-Service and facilitation. Making the mode explicit avoids a common problem: teams that should be consuming a service end up in permanent coordination meetings.

The GOV.UK Service Manual adds another perspective: it organizes work around services and a team that manages them through phases (discovery, alpha, beta and live). The live phase is not the end of the team; it is when the service keeps improving with real usage data.

For infrastructure and operations, this model changes the role. Instead of a central queue that takes requests from everyone, part of that team becomes a platform and part joins product teams with reliability practices. We cover this in from administrators to SRE.

Metrics: outcomes and flow instead of scope and date

"On time, on scope and on budget" measures whether a plan was followed. It does not measure whether the plan was good or whether the service improved. In a product model it pays to combine two families of metrics.

The first is outcome metrics, specific to each product and agreed with the business: completion rate of a digital journey, loan approval time, internal user satisfaction, compliance with the service levels that matter. To choose the latter well, see SLAs that measure what the business cares about.

The second is flow and stability metrics. The Accelerate State of DevOps Report 2019, from DORA, uses four measures of software delivery performance: deployment frequency, lead time for changes, time to restore service and change failure rate. Its central finding, sustained across several editions, is that speed and stability are not a trade-off: the best performing teams achieve both.

Two practical warnings. First, these metrics are for teams to improve, not to compare teams or evaluate individuals; used that way, they get distorted quickly. Second, flow without outcomes is just activity: deploying more often only makes sense if it improves something users notice.

The table summarizes how each dimension changes.

Dimension	Project model	Product model
Funding unit	Initiative with a business case	Team capacity assigned to a product
Horizon	Project close date	Life of the service, with periodic reviews
Team	Temporary, assembled per initiative	Stable, cross-functional
Accountability	Deliver and hand over to operations	Build, run and improve
Main metric	Scope, schedule and cost	Business outcomes and delivery flow
Handling scope changes	Formal change request	Backlog reprioritization each cycle
Knowledge	Scatters at closure	Accumulates in the team

How it coexists with ITIL and the PMO

A common fear is that the product model requires dismantling service management or the project office. It does not, but both change their role.

ITIL

ITIL 4 already speaks in terms of value streams and co-creating value with the user, which fits well with teams organized by product. The practices are still needed; what changes is who carries them out and at what level of granularity:

• Incident and problem management: the product team takes part in resolution and owns the underlying fixes, instead of receiving tickets from a third party.
• Change enablement: routine changes from a team with a good track record can move to pre-approved standard change models; high-risk changes keep their review.
• Service level management: each product has its own service level objectives, tied to its outcomes.

If you are getting started with ITIL, the five ITIL 4 practices to start with explains where to begin.

PMO

The PMO moves from controlling projects to managing the product portfolio and capacity. Its new tasks include maintaining the map of products and their owners, preparing periodic investment reviews, tracking outcome metrics, spotting dependencies between teams and continuing to govern the work that really is a project. It also keeps a key role with vendors: when part of the capacity is external, the contract should reflect stable teams and outcomes, not just deliverables. We cover this in PMO and VMO as a service.

Where to start

The change is organizational and takes time. We recommend moving in stages:

1. Pick one or two pilot products with clear users, a committed business owner and frequent change. Avoid starting with the most critical system or the most isolated one.
2. Define the product and its owner: what it includes, whom it serves, which outcomes it pursues and who sets priorities.
3. Form a stable team with the skills needed to build and run it, even if some roles are shared at first.
4. Agree the funding scheme with Finance for the pilot, including its accounting treatment.
5. Measure from day one the four delivery metrics and two or three outcome metrics, to establish a baseline.
6. Adjust ITIL and the PMO for the pilot: standard change models, product-specific service objectives and a quarterly review.
7. Review and expand after two or three cycles, with evidence of what worked.

A common mistake is renaming project teams as "product teams" without touching budgets or metrics. The result is the same model with new vocabulary. Another is creating stable teams without a product owner with real authority to prioritize; the team ends up serving requests from everyone.

Because the model affects team structure, roles and the way IT is funded, validate the design with Human Resources and Finance before expanding it.