Product teams really do outperform: bringing the receipts

Researchers at DORA, McKinsey and Google have spent a decade proving what good engineers already know. It’s time to put that knowledge into practice.

Photo by Albert Stoynov on Unsplash

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 a product oriented 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.

If you’re new, welcome to Customer Obsessed Engineering! I publish about one article each week. Free subscribers can read about half of every article, plus all of my free articles.

Anytime you’d like to read more, you can upgrade to a paid subscription.

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 a product oriented 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.

This newsletter grows by word of mouth… I’d really, truly appreciate it if you could refer a friend. Your referrals make it worthwhile.

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.