I recently attended the Minnesota Tech Association’s annual Tech Connect Conference and, about halfway through the day, I realized that nearly every session was not, in fact, about the latest in tech: it was about people, and where those people sat inside the organization. This is the perennial question about whether product management in tech-driven organizations should report up through the business or the IT organization. 

Not suprisingly, the sessions overwhelmingly addressed culture, how teams work together, and the convergence of people and technology. Jackpot! I knew immediately I was in the right place. As someone who specializes in Operating Model Transformation, it was so refreshing to see tech leaders thinking as much about the technology as the humans that work on and with the tech every day. 

Naturally, many of these conversations involved product management, and in almost every one, a common question emerged: When you’re evolving to a product-led operating model, should the product function sit with business or technology?  

Heads around the room would nod, and low chuckles would circulate. It’s a common and necessary question for any transforming organization, and I’ve got my own opinions about which is preferred (surprised?).

I can argue both sides because there are pros and cons to each, but before I reveal my pick, here’s a rundown of those considerations.

The Case for Product to Sit Within IT

When Transformation is being led by the IT organization, product roles are often situated inside that org, particularly if you have an experienced tech leader who has navigated the shift before.

The IT leader knows what “good” looks like, and is probably navigating relationships across the organization where it’s unclear how a product-led operating model is going to benefit them. Building a product org within IT can allow the organization to move a little faster, and set a consistent standard as a proof of concept as it’s incubated and scaled. 

However, the downside to growing the product function within IT is that it perpetuates the wall between IT and business, which is what we’re trying to get rid of in the first place. It can be seen as something that IT is doing TO the business, not WITH them. 

As a result, teams tend to operate within their four-walled gardens rather than working collaboratively across silos, which is what a product-led model is trying to combat in the first place.

The Case for Product to Sit in the Business

Obviously, growing a product practice within business units can combat those silos and walls.  This ensures that Product Managers and Owners are close to the business strategy and customer needs that the business is focused on. It also builds a strong bridge to the technical teams that are required to deliver on those needs. 

The result is a greater sense of buy-in and commitment from business on the strategies and plans being executed because they originated within the business org.

The downside? This approach can be very slow and suffer initial consistency issues because it requires product roles to be hired and developed in different parts of the business by people who aren't used to hiring or working with product folks. 

Similarly, the business leaders usually haven't led product work before (especially within legacy organizations), so new skills are necessary to support the new ways of working at every level of the organization. This can – and should -- be done, but it means there are a lot of people working on building the plane as it’s taxiing down the runway.

Orgs that go this route have to be forward thinking and create standardized practices and operations so that product people across the org have a common framework and community of peers to turn to for support and learning (so they aren’t reinventing the wheel every time).

Is There a Hybrid Approach to Product Management?

You may be wondering why we can’t have the best of both worlds. While there is a hybrid approach, it too comes with its own share of issues.

In this model, the strategic function is separated from the execution function, like an organization where product owners and engineers build things together, while strategic roles like product managers and directors sit within the business. 

On paper it sounds nice, but in practice this bifurcation creates a sense of false separation between jobs and allows the wall between IT and business to perpetuate. Even worse, it makes a career path in product roles very difficult because you’re splitting product ownership from product management (which is a missed opportunity to establish a potential talent pipeline).

So, Which One is Better?

With any of these approaches, you’re going to break some eggs. They each have their fair share of cultural and operational challenges and disruptions, but my personal bias is that standing up product within business is the right way to go 99% of the time. As painful and as slow as it can be initially, the short-term pain is worth the long-term gain. 

Here’s why: When you build a product org inside of an IT org, you’re really just delaying the inevitable. Once you achieve a really high-functioning product team, business will eventually want to decentralize it, and that breaks a ton of systems. It might seem more accessible at first, but why would you want to manage the change and pain twice? 

In other words: Don’t be afraid to climb the steeper hill. I promise you, the view is much better from the top.