We’ve been researching the rise of product-centricity for some time now at Forrester. In my view, it’s emerged as the primary integrated operating model response encompassing agile, DevOps, and cloud.

In the past two years, I have worked on operating model approaches with digital and IT organizations in all sectors — retail, manufacturing, government, healthcare, finance, media, insurance, and more. All are feeling the pressure to update their ways of working and to better support innovation and nimble adaptation in an increasingly volatile and uncertain world. One way to view current trends is as a convergence of traditional IT practices with the discipline of product management:

This transformation has been going on for a long time now. On the IT side, the legacy is well known:

  • Project management
  • IT service management
  • Enterprise architecture
  • IT governance approaches

On the product side, a number of influences have converged:

  • The Agile method Scrum , with its advocacy of “product owners”
  • The influence of FAANG (Facebook, Amazon, Apple, Netflix, Google)
  • Silicon valley startup culture
  • Authors like Marty Cagan, Melissa Perri, Teresa Torres, and Steve Blank

The product-centric promise of greater team autonomy and empowerment leading to faster value discovery resonates with many organizations I talk to. However, the convergence and transformation are by no means complete for most large, traditional IT organizations. A well-known, leading case is Target, where the transformation to a largely product-centric model was first initiated around 2012 and was accelerated by a new CIO around 2016 — who affirmed it as “the way we will do things”1 — yet the transformation nevertheless took at least until 2018 to (more or less) complete (some at Target would say “we aren’t done yet”).

Most organizations are far behind Target and its lightly regulated retail vertical. The larger IT shops I talk to are now under considerable executive pressure to pivot toward something resembling product-centricity (it may be labeled any combination of digital/agile/DevOps transformation). External consultants, coaches, and trainers may play an important role, yet at the end of the day, these large IT organizations are the ones that have to lead their own change. More than one leader has likened it to “changing the aircraft engine while in flight.”

There are many current struggles, debates, and experiments being undertaken and lots of questions where I often say, “welcome to the bleeding edge”:

  • What is the definition of a “product,” and how does it relate to earlier, hard-won portfolios such as applications and services? How abstract is a “product”?
  • What is the definition of “value stream,” and how does it relate to “product”? What about “capability” versus “product”?
  • What is the optimal cardinality of teams and products (how many “products” for each “team”?) One-to-one may be a default response, but much hinges on definition and legacy issues.
  • How is the matrix structured? There is a general acceptance (akin to Spotify) that line reporting should still be via specialty, while “products” are essentially a matrix overlay with more continuity (as opposed to projects) and better governed demand. But people are trying other models, including line reporting via product teams (ironically, the “Spotify model” is sometimes misinterpreted as line reporting via product teams due to a notoriously imprecise graphic).
  • Autonomy is great, but alignment is still necessary. The concept of “command and control” is viewed increasingly negatively, but this leaves open the question of how to keep teams from lapsing into local optimization at the expense of broader goals.
  • The idea that product managers and engineers have different line reporting is encountering immediate problems with the popular Team Topologies-driven concept of platform teams. We wind up with platform teams being led by product managers who may not have engineering depth. But engineering-led platform teams too often lapse back into ticket-taking, functional silo behavior. This is a hard problem.
  • What is the correct scope and size of product teams? People are well aware of the “two-pizza” model, but there are important trade-offs that I cover in this blog.
  • Where do we get people with the right mentality? (This is probably the biggest concern the higher in the organization you go.) In terms of workforce development, educating “product managers” currently is handled by boutique consultancies. Traditional educational institutions don’t cover it, and I’m not sure when or if they will start. Note: We provide this service at Forrester as well, via our colleagues coming from the Sirius Decisions legacy – a well known product advisory firm themselves. 

One trap some have fallen into is scoping “products” too broadly in the interest of having a team that is accountable for and capable of producing a single “outcome” (e.g., provisioning a server). This is one of the most vexing problems I have heard lately and probably puzzles some folks with a background in faster-moving environments. But the controls and processes associated with delivering most true outcomes in large, regulated environments are unbelievable. Grouping all the involved parties under one “product manager” leads to a set of responsibilities that at best requires a hard to come by, highly seasoned product owner (and at worst is completely unmanageable by one person). Yet partitioning the problem for a better span of control results in undesirable dependencies.

As near as I can tell, there is no silver bullet or yellow brick road to a product-centric nirvana. Like most transformational impulses, it’s a North Star; by definition, you head in that direction but never quite get there.

Acknowledgements to Sam Somashekar for assistance.


  1. Paraphrased from remarks by Mike McNamara at the Minnesota High Tech Association Techtalent conference in 2019.