When Worlds Collide: IT & Product Management

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 approach with digital and IT organizations in all sectors — retail, manufacturing, government, healthcare, finance, media, insurance, and more.

Source: When Worlds Collide: IT & Product Management

All are feeling the pressure to update their ways of working, to better support innovation and nimble adaptation to 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:

• Scrum , with its advocacy of “product owners”
• The influence of the FAANGS (Facebook, Apple, Amazon, Netflix, Google)
• Silicon valley startup culture
• Authors like Marty Cagan, Melissa Perry, Theresa 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, was accelerated by a new CIO around 2016 who affirmed it as “the way we will do things,” yet nevertheless took at least until 2018 to (more or less) complete (some at Target would say “we aren’t done yet”).

And most organizations are far behind Target, in its lightly regulated retail vertical. Most larger IT shops I talk to are now under considerable executive pressure to pivot towards 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 who 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 “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” vs “product”?
• What is the optimal cardinality of teams and products (how many “products” for each “team”?) 1:1 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, but 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 mis-interpreted 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 tradeofffs that I cover in Original Postroduct-teams-the-new-iron-triangle/" target="_blank" rel="noreferrer noopener">this blog.
• Where do we get people with the right mentality? (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.

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 no one individual can handle; 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 get there.

Acknowledgements to Sam Somashekar for assistance.