How product teams outperform

I was chatting with a friend about team dynamics. We’d been talking about restructuring around product teams — the kind of empowered, durable, cross-functional teams I’ve written about before. He’s nodding along, asking sharp questions. Halfway through, he pushed back.

I’m paraphrasing, but the gist was, “Look, I get the theory. But where’s your proof? We’ve all heard the pitch. Cross-functional teams, durable squads, outcome metrics, two-pizza this, empowered that. Show me the data. Show me that any of this actually beats what we already do.”

It was a fair question. A great question, actually. I’d written the case in Building your team and the prequel, Moving away from the Monolith — faster, better with a product mindset. But those pieces argued from reasoning and experience. They didn’t bring the math.

So today I want to bring it. Because the math is there — it’s been there for over a decade — and once you line it up, the conclusion is hard to escape: product teams, the real ones, ship faster, build less waste, deliver higher quality and produce dramatically better business outcomes than the alternatives. The evidence isn’t a single bombshell study. It’s a stack of independent research, all converging on the same answer.

Let me lay out the receipts.

One note before we start. None of the studies I cite below were designed to answer the question “do product teams outperform?” They were designed to answer narrower, related questions — about deployment, about feature usage, about team effectiveness, about developer velocity. What’s below is my synthesis: the act of lining up findings from different research traditions and showing where they converge. The convergence is the argument. Each citation is a thread; the rope is the pattern across them.

A quick refresher on “product team”

Before the data, let’s get precise. “Product team” gets thrown around so loosely it’s often meaningless.

Marty Cagan and the Silicon Valley Product Group draw the cleanest distinction. A product team is a small, durable, cross-functional unit — typically a product manager, a designer and a handful of engineers — that owns a problem and is held accountable for outcomes. They are given problems to solve, not features to ship. The product manager owns value and viability. The designer owns usability. The tech lead owns feasibility. Together they own the result.¹

A feature team looks similar on paper — same disciplines around the table — but is handed a prioritized list of features to build. Outcomes belong to a stakeholder upstream. The team is judged on output: did you ship what was on the roadmap? Velocity, story points, throughput.

A project team is even further from product orientation. It’s pulled together to execute a discrete project, then dissolved. Specialists rotate in and out. There’s no durable home for product knowledge.

The labels matter less than the operating model. As I wrote in Building your team, the real distinction is durability, ownership and empowerment — long-lived teams that own the whole product end-to-end and have the authority to figure out the how.

Now — what the research says.

Receipt #1: they ship dramatically faster

Start with DORA — the DevOps Research and Assessment program, founded by Dr. Nicole Forsgren and now part of Google. Every year since 2014, DORA has surveyed practitioners — more than 3,000 in 2024 alone, and tens of thousands across the decade-long program — and statistically grouped them into performance tiers based on four metrics: deployment frequency, lead time for changes, change failure rate and mean time to restore service. The methodology, the math and the conclusions are documented in Accelerate — the book that emerged from the research and won the Shingo Publication Award.²

The 2024 Accelerate State of DevOps report is the latest. Elite-tier teams deploy 182 times more frequently than low performers, with 127× faster lead time for changes. Elite teams hit lead time under a day, deploy on demand and are roughly 19% of the surveyed population. Low performers measure lead time in months.³

That’s not a marginal advantage. It’s not “20% better.” It’s two orders of magnitude.

You might be tempted to dismiss this as a DevOps story rather than a team-structure story. But every time DORA digs into what differentiates elite teams, the answers are the same attributes that define product teams: small, cross-functional, owning the whole pipeline from code to production, empowered to make their own technical decisions. The opposite — handoffs across functional silos with stage-gate approvals from external groups — correlates strongly with low performance. Accelerate presents one specific finding bluntly: external change advisory boards do not improve stability. They make lead time worse without making anything safer.⁴

McKinsey’s “Beyond Agile” work, which I cited in How waterfall is wrong for software, puts a number on the same effect from a different angle. Across their consulting engagements, McKinsey observed that companies could compress the average time from “code complete” to live production from 89 days to 15 days when they reorganised around DevOps and product-team principles. Same basic architectures, same kind of features. Six times faster, just from changing how the team takes work from “done” to “deployed.”⁵

The simplest summary: product teams own the value stream end-to-end. Feature and project teams hand off across silos. Handoffs cost time. Time turns into distance from the customer. Distance from the customer means everything you ship is stale.

Receipt #2: they get more done — but redefine what “done” means

“More done” is the wrong metric. The right metric is: did anyone use what we shipped?

In 2002, Jim Johnson — chairman of the Standish Group — presented a finding at the XP conference in Sardinia that’s been quoted ever since: across enterprise applications, only 7% of features are “always” used, 13% are “often” used and 16% are used “occasionally.” That leaves 64% of features as either rarely or never used. Standish later extended the analysis to claim that roughly 80% of features deliver low or no value. On large projects, Standish data shows organizations deliver only 42% of the features they originally scoped**.** The Standish numbers have drawn methodology critiques over the years — fair enough — but more recent work points the same direction. Pendo’s 2019 Feature Adoption Report, drawing on telemetry from hundreds of B2B SaaS products, found roughly 80% of features are rarely or never used.⁶

Sit with that for a moment.

Now, “rarely used” isn’t synonymous with “no value.” Some rare features are quietly essential — compliance flags, account recovery, the audit trail your CISO will ask about exactly once. Both Pendo and Standish gloss over that distinction. Even granting it generously, though, the ratios still point at a meaningful misallocation: a lot of effort going into features customers rarely or never engage with. (I’m looking at you, Microsoft Office).

A feature team measured on roadmap output is, by these numbers, building a sizable wedge of low-value work. They look terrific on burndown charts and terrible on customer impact.

I’ve watched this play out enough times to be cynical about it. A feature team gets a quarterly roadmap. They estimate the work in story points, deliver on schedule, demo a sleek end-to-end flow and get applauded. Six months later, telemetry shows the feature gets touched by 3% of users. By then the team has moved on to the next item on the roadmap. Nobody is accountable for the gap between “shipped” and “mattered,” because shipped is the goal.

A product team would have caught that earlier. They wouldn’t have built the full feature on a quarterly roadmap; they’d have built the cheapest possible version that tested the hypothesis — a prototype, an A/B variant, a deliberately ugly first cut — and watched the data. If the data said 3%, they’d have killed the feature in week two and gone after a more promising hypothesis. That’s the discovery discipline Marty Cagan and Teresa Torres write about extensively, and it’s the operational reason product teams build less and deliver more. Not because they’re slower. Because they aim differently. They invest in discovery before commitment. They kill a feature that doesn’t earn its keep. They redefine “done” from “shipped” to “moved the metric.” And the metric they move is customer behavior, not story points. (I’ve made the same argument from a measurement angle in Stop measuring effort.)

There’s a parallel finding in McKinsey’s What makes product teams effective? — a five-year study of more than 1,700 teams across 75 organizations. McKinsey identified two structural conditions that consistently predict throughput and velocity improvements: dedicated team membership (no context switching across projects) and team persistence of three to six months minimum. Teams meeting both conditions develop reliable estimates and sustained throughput. Teams that don’t, can’t.⁷

That finding isn’t surprising if you think about how knowledge accumulates. Product orientation depends on knowledge durability — context that only forms when the same people work on the same problem long enough to internalise it (more on this below). Project teams dissolve before that happens. Feature teams reorganise around the next quarterly priority. Product teams stay put. That’s why their throughput compounds.

Receipt #3: quality is higher, not lower

The most common objection to “deploy faster” is “but quality will suffer.” It’s a reasonable instinct. It’s also wrong, and DORA’s data has been demolishing it for a decade.

DORA’s foundational and most-replicated finding is that speed and stability are correlated, not in tension. Elite-tier teams that deploy on demand also exhibit the lowest change failure rates (around 5%) and the fastest recovery times (under an hour). Low performers, the ones deploying monthly or quarterly with elaborate change-control processes, have higher failure rates and take longer to recover when something breaks. The teams that ship the most carefully break the most often.⁸⁹

A small honest note: in 2024, DORA restructured how it frames throughput and stability. The medium cluster had a lower change failure rate than the high cluster — an anomaly that happened once before, in 2016. The macro pattern across the decade still holds, but the wrinkles are real and worth naming.

Why? Because the practices that enable rapid, reliable deployment are the same practices that produce stable software: small batches, automated testing, fast feedback, ownership of the operational surface. None of those are technical decisions made in isolation. They’re decisions a team can only make if it owns the whole product end-to-end. That’s a product team. A feature team that hands code to a separate QA group, who hands a build to a separate ops group, can’t even attempt these practices. Each handoff resets the feedback loop and makes batches bigger.

Then there’s Google’s Project Aristotle. Google studied 180 of its own teams over two years, using both qualitative and quantitative measures of team effectiveness. The single strongest predictor of high performance — stronger than skill, stronger than tenure, stronger than seniority — was psychological safety: the shared belief that team members can speak up, take risks and admit mistakes without being punished for it. The other four factors that mattered were dependability, structure and clarity, meaning and impact.¹⁰

What that means: psychological safety can’t be retrofitted onto a team that’s about to dissolve. It develops over months. It requires consistent membership. It requires the same humans showing up to the same problem long enough to learn each other’s failure modes and forgive them. It demands that leadership support and respect those boundaries. Product teams, by their durable nature, build psychological safety as a side effect. Project teams never live long enough.

The chain is short and worth pointing out: speed and quality come from the same practices. Those practices require ownership. Ownership requires psychological safety. Psychological safety requires durability. Product teams are durable. That’s why the data lines up the way it does.¹¹

Receipt #4: the business outcome is real

If everything above were true but had no business consequence, none of it would matter. So let’s check.

McKinsey’s Developer Velocity Index (DVI) research, based on a survey of senior executives at 440 large enterprises plus more than 100 expert interviews, ranked organizations by their developer-velocity capabilities and then looked at financial outcomes. The result wasn’t subtle.

Top-quartile DVI organizations delivered revenue growth four to five times faster than bottom-quartile peers (measured 2014-18), along with 60% higher total shareholder returns, 20% higher operating margins and 55% greater innovation as scored by the research team. Those aren’t framework-of-the-month results. Those are board-level numbers.¹²

The DVI research identified four specific drivers: tools, culture, product management and talent management. Notice what’s not on the list: methodology adoption, framework certification, agile coach headcount. The drivers are operating-model conditions — the kind of conditions that exist when teams own products, and that don’t exist when teams execute roadmaps for someone else.

Stitched together with DORA, the picture sharpens further. DORA’s analysis of organizational outcomes finds elite performers are roughly twice as likely to exceed their commercial goals, including profitability targets. So the same teams that deploy 182× more frequently and ship changes 127× faster are also the ones meeting the numbers their CFO cares about.¹³

For an individual case, look at Trainline. Cagan describes their transformation in Transformed as one of the most complete examples on record — a “specs over the wall” engineering organization rebuilt as empowered product squads with outcome-based roadmaps. The company priced its 2019 London IPO at £1.68bn, and first-day trading pushed the market cap past £2bn.¹⁴

A second example — older but well-instrumented — is Etsy. Forsgren, Humble and Kim use Etsy in Accelerate as one of the case studies that motivated DORA in the first place: small autonomous teams, end-to-end ownership and a deployment pipeline that compressed lead time from weeks to minutes. The pattern repeats in the digital natives that grew up with the operating model from day one — Stripe, Netflix, Spotify — and in the older institutions that successfully transformed into it, like Capital One. One transformation isn’t proof. Half a dozen across very different industries makes a pattern.¹⁵

Why it actually works — the mechanisms

If you’ve ever watched an engineer get pulled off a refactor mid-flight to debug a different team’s incident, you’ve seen the cost in real time. Two days lost on the refactor, four hours actually spent on the incident, and a third day re-establishing the headspace they had on Monday. The “busy” looks productive on a dashboard. The throughput is decimated. (I’ve written about the personal version of this problem in Context switching is killing your gains.)

Why does the data show what it shows? The numbers are striking, but they aren’t magic. Three mechanisms get cited in the literature, each well-documented as a phenomenon of knowledge work. Notice as we go through them that they’re really three faces of the same underlying variable.

Cognitive load. Matthew Skelton and Manuel Pais’s Team Topologies makes the case, and the practitioner research backs them up: the throughput of a team is governed by the cognitive load it can carry. Stream-aligned teams, the Team Topologies analogue of product teams, work because their boundaries match a single value stream. They aren’t carrying the cognitive load of cross-team coordination, dependency negotiation or context-switching between unrelated problems. They get to think hard about one thing. Skelton and Pais define platform, enabling and complicated-subsystem teams alongside the stream-aligned one — precisely so the load-bearing teams stay near their cognitive ceiling. Get the structure right and stream-aligned teams operate at the top of their range. Get it wrong and everyone’s trying to think about everything, and nothing actually moves.¹⁶

Context switching. Gloria Mark’s UC Irvine program — alongside corroborating work from Microsoft Research — established that interruptions carry a heavy recovery cost. Mark has summarized her data as showing roughly 23 minutes and 15 seconds to fully recover focus after an interruption. Microsoft’s 2025 Work Trend Index quantifies the volume side: knowledge workers are pinged every two minutes during the core workday, totaling roughly 275 pings across a 24-hour day. A Harvard Business Review analysis of 137 knowledge workers found they burn nearly four hours a week — about 9% of annual work time — just toggling between applications. Teams that share members across multiple products pay this tax twice. The McKinsey product-teams research called out 100% dedicated membership for exactly this reason: split attention is the silent killer of throughput.¹⁷¹⁸

Knowledge durability. Every handoff between teams loses information. Every silo specialises in one slice of the value chain and is structurally blind to the rest. By the time the third or fourth handoff happens — business unit to BA to architect to dev to QA to ops — the original customer intent is barely recognizable. Product teams collapse the chain into one team that holds the whole picture. There is no “telephone game” because there are no phones.

Picture a two-year-old codebase one team has owned the whole time. There are a thousand small decisions baked into it — why this database, why this caching layer, why this feature choice — and the team can articulate every one of them. Now picture the same codebase after three project teams have rotated through on six-month tours. Same code; almost none of the decisions are recoverable. The new teams either rebuild from scratch (wasteful) or accept opaque behavior and route around it (technical debt). Product teams don’t pay the handoff tax. Project teams pay it every six months.

Now look at all three side by side. Cognitive load is what gets protected when a team focuses. Context switching is what erodes focus across time. Knowledge durability is what accumulates when focus persists. Strip the labels and you find the same variable underneath: focus over time, on a single problem domain. That focus protects throughput, lowers waste through better aim, and compounds into quality and business outcomes.

Pull on focus and the rest weakens. Protect it and the rest takes care of itself. Product teams aren’t magical; they’re the operating model that protects focus by default.

What the data does not say

Positioning all of this as unquestionable would be intellectually dishonest.

There is no single controlled experiment titled “product teams beat feature teams by X%.” The evidence I’ve laid out comes from multiple independent studies, with different methodologies, looking at different facets of the same phenomenon. They converge — strongly — but you have to be willing to read across them. A pure skeptic can pick at any one of them in isolation. The strength is in the convergence, not in any one number.

Here’s the honest accounting of the bridges that synthesis requires. DORA measures DevOps capability, not team structure; the bridge from “elite tier” to “product team” is mine, supported by DORA’s qualitative findings on what differentiates elite teams. Pendo measures feature usage at the product level, not at the team-structure level. The bridge from “80% rarely used” to “feature teams produce more waste” is mine too. McKinsey DVI correlates organizational capability with financial outcome; the bridge from correlation to causation is plausible but unproven. Project Aristotle measured within-Google team variation; the bridge from “psychological safety predicts effectiveness” to “durability builds psychological safety” is also mine. I’m laying these out so you can audit them. If any single bridge collapses, the convergence weakens. If they all hold, the case is what I’ve claimed.

The data also says nothing flattering about cosmetic product teams. Cagan is blunt about this in Empowered: rebadging a project manager as a “product owner,” keeping the roadmap-handoff intact and putting “product over project” on a slide doesn’t change anything. None of the research benefits accrue to organizations that adopted the language and skipped the operating-model change. The McKinsey DVI gains are for organizations whose product management actually owns outcomes. The DORA gains are for teams that actually own the deployment pipeline. The McKinsey throughput gains are for teams whose members are actually 100% dedicated. If you keep the old operating model and change only the labels, the data predicts you’ll get exactly what you’d expect: nothing.

The graveyard isn’t empty, and the most instructive failures sharpen the same point. Refinery29 stood up squads and chapters at a snap of the fingers in early 2014, copying Spotify’s published model. By Q1 2016 they’d unwound it and reorganized into three durable verticals. The Refinery29 Agile Coach who lived through it — himself a former Spotify coach — diagnosed the failure plainly: they emulated the structure without redesigning the operating model. Ownership of shared platforms was ambiguous. Chapters were sized wrong. Coordination between squads was assumed rather than designed. The org chart had changed; almost nothing else had.¹⁹

The deeper irony is that Spotify itself had never fully run the model that everyone was copying. Jeremiah Lee — a Spotify product manager from 2017 — gathered the receipts from inside the company, including this from Joakim Sundén, an agile coach there from 2011 to 2017: “Even at the time we wrote it, we weren’t doing it. It was part ambition, part approximation. People have really struggled to copy something that didn’t really exist.” The author of the original whitepaper said the same thing, on the record. The 2014 paper was a sketch of an aspiration, not the operating manual of a working company.²⁰

So the graveyard is real, and the headstones tell a consistent story. The transformations that fail are the ones that change the org chart and call it done. The ones that succeed change funding, authority, ownership and durability — and let the org chart catch up afterwards.

This is the most important thing the research says. Product team performance is about operating model, not org chart.

Where to start

If you’re convinced and wondering what to do on Monday morning, here’s the TL;DR. One framing note before the steps: every action below is fundamentally about organizational change — who funds, who decides, who owns. Treat this as methodology adoption and you’ll do agile theatre while the data refuses to move. Operating model is the variable that matters.

Start with funding and authority. This is the step most transformations skip, and it’s the one that quietly kills the rest. If your projects are still funded by business case and managed by milestone, you cannot have product teams — you have project teams with new vocabulary. Money has to follow durable teams. Allocated to a team or a product, not to a fixed-scope project. Authority over what to build has to sit with the team and its product manager, with business stakeholders setting outcomes rather than dictating features. Cagan calls this out explicitly in Transformed; McKinsey’s What makes product teams effective? names “agile funding” as one of the top capabilities driving outcomes. If you can’t get this far, the rest is decoration.

Then pick one team and make it real. Not the whole org — just one team. Give them a problem to solve, not a roadmap to execute. Make membership 100% dedicated. Commit to a minimum six months of stability. Empower them to own deployment end-to-end. Then defend them — because the single biggest reason these pilots fail isn’t team performance, it’s that the surrounding organization keeps treating the pilot team like a feature team. The CFO asks for project plans. The CIO requires CAB approvals. The director pulls a person off for a “quick” priority. Watch for those patterns and push back every time. The point isn’t that the pilot team needs to be perfect; the point is the operating model around the pilot team has to actually change.

Measure both sides of the equation. Pick the four DORA metrics — deployment frequency, lead time, change failure rate, mean time to restore — and instrument them honestly. But pair them with at least one outcome metric: did users actually use what you shipped? Did the customer behaviour you said you’d move actually move? DORA metrics tell you the team is shipping faster; outcome metrics tell you the team is shipping the right things. A pilot that improves DORA scores while shipping unused features hasn’t proven what you set out to prove. (For the broader argument about measurement intent, see With the right strategy you can be the next Google — but only if you measure the right things.)

Read the source material. Accelerate by Forsgren, Humble and Kim is the empirical foundation. Empowered and Transformed by Cagan are the operating-model handbook. Team Topologies by Skelton and Pais is the structural design language. None of these are methodology books in the agile-coaching sense. They’re books about how authority, accountability and ownership get distributed inside an organization that genuinely builds products.

Finally: when my friend asked for the receipts, this is the article I wished I’d had on my phone. So when someone in your leadership pushes back with “where’s your proof?” — point them here, point them at the original sources and let the receipts do the talking.

The research has been on the desk for a decade. The synthesis — the work of pulling it together into a single, decision-ready argument — was what was missing. Now it isn’t.

For more on the operating model side of this argument, see Building your team and Moving away from the Monolith — faster, better with a product mindset. If a scaling framework is what stands in the way, Can you rely on SAFe to deliver elite-performer gains? takes that apart. For the leading indicators that predict whether your project will succeed regardless of methodology, see I can predict the success or failure of any project. And for the mechanics of compressing feedback loops inside a product team, see How waterfall is wrong for software and The balanced power of TDD.