Measuring IT Team Performance in a Product Operating Model

      Measuring IT Team Performance in a Product Operating Model

      From Technology Delivery to Business Value

      Much of the discussion surrounding Product Operating Models has focused on customer centricity, persistent teams and faster delivery. An equally important—but less frequently recognized—benefit is that a Product Operating Model creates the organizational conditions for credible performance measurement.

      Historically, IT performance has been difficult to measure because project-based delivery lacks a stable unit of work. Every project is different, making it difficult to compare delivery performance across teams or over time. As a result, many commonly used IT metrics have lacked credibility with business leaders and have done little to improve management decision-making.

      A Product Operating Model changes this by replacing temporary projects with persistent products, stable teams and continuous delivery. Although it does not eliminate the need for disciplined delivery practices or reliable operational data, it creates a far more consistent basis for measuring performance.

      This paper proposes a pragmatic performance framework built around three principles.

      §  Performance should be measured where accountability exists. The primary management unit should therefore be the Product or Value Stream, supported by squad-level operational diagnostics and aggregated to provide an enterprise view.

      §  Executive reporting should focus on a small number of balanced delivery measures rather than a large collection of operational metrics.

      §  Measurement capability should mature alongside the Product Operating Model itself. Organizations should first establish consistent delivery behavior, then improve delivery predictability, and ultimately connect delivery performance to product-level business outcomes as Objectives and Key Results (OKRs) become established.

      The objective is not to create another IT dashboard. It is to establish greater confidence in how technology performance is governed and how it contributes to business value.


      Few areas of enterprise management have proven as difficult to measure consistently as technology delivery. Unlike finance, manufacturing or sales, IT has historically lacked a stable operating model from which meaningful organizational performance measures could be derived.

      For many years organizations have relied on proxies such as project milestones, lines of code, function points and, more recently, Agile story points. Each has value within a particular delivery context, yet none has become a broadly accepted measure of organizational performance.

      The underlying problem has not been the quality of the metrics themselves, but the absence of a consistent unit of work. Traditional project delivery is inherently bespoke. Every project differs in scope, duration, complexity and risk. Estimates are unique to each initiative and often to each delivery team. Consequently, the measures built upon those estimates are equally difficult to compare across teams or aggregate over time.

      This has given rise to a second challenge: trust. Business leaders are understandably skeptical of measures that are difficult to interpret or whose underlying assumptions they cannot independently validate. Engineering teams, meanwhile, often view executive reporting as disconnected from the realities of software delivery. The result is that discussions about IT performance frequently rely more on anecdote than objective evidence.

      The challenge, therefore, has been less about identifying better metrics and more about creating an operating environment in which meaningful measurement becomes possible.


      A Product Operating Model should not be viewed simply as a different way of organizing technology teams. It represents a fundamentally different management system for technology delivery.

      Traditional project delivery is characterized by temporary funding, temporary teams and temporary objectives. Once a project is complete, the team is disbanded and the next initiative begins. This constant reformation makes it difficult to distinguish whether changes in performance are due to improvements in capability or simply differences in the work being undertaken.

      A Product Operating Model introduces a different set of characteristics. Products and Value Streams become long-lived organizational constructs. Teams remain largely stable. Funding shifts from individual projects to enduring product investment. Work is delivered continuously through relatively small increments of business value rather than large project releases.

      These characteristics create something that project delivery rarely provides: repeatability. Rather than attempting to compare fundamentally different projects, leaders can observe how stable teams perform while delivering against stable product backlogs over extended periods. Although individual business stories inevitably differ in complexity, they provide a far more consistent basis for observing delivery trends than traditional project milestones.

      This distinction is important. A Product Operating Model does not make performance measurement perfect. Delivery discipline, consistent backlog management and reliable operational data remain essential. What it does provide is the organizational stability necessary for meaningful measurement.

      In other words, it creates the conditions under which performance can be managed rather than simply reported.


      Much of the discussion surrounding Product Operating Models has focused on improving how technology teams deliver software. Equally significant, however, is the opportunity to improve how technology performance itself is governed.

      By replacing temporary projects with persistent products, stable teams and continuous delivery, a Product Operating Model creates the organizational conditions for more credible performance measurement. Performance can be assessed where accountability exists, interpreted in the context of stable delivery patterns and progressively connected to business outcomes as product management matures.

      The framework proposed in this paper is intentionally modest in scope. It recommends a small number of balanced executive measures, supported by focused operational diagnostics and aligned to the natural levels of accountability within the operating model. It also recognizes that measurement capability should evolve over time, beginning with consistent delivery, progressing to reliable forecasting and ultimately connecting delivery performance to business value.

      The objective is not simply to produce better metrics. It is to create greater confidence in how technology performance is managed, how investment decisions are informed and how technology contributes to the organization’s strategic objectives. A Product Operating Model should therefore be viewed not only as a better way to organize delivery, but also as the foundation for a more transparent, more accountable and ultimately more effective system of technology governance.

      Published: 2026-07-17