_Talk about bridging the gap between business and IT is all well and good, but it’s just hot air unless someone owns the bridge. Or asks whether building the bridge is a good idea in the first place.

On paper, traditional IT roles like business analyst and project manager have responsibility for both business and IT issues. Unfortunately, neither of these roles really own the IT/business bridge. Who’s responsible for it? Who’s in authority to make decisions about it? Who makes sure that the groups on both sides are happy with the results?

Fortunately, a role that straddles business goals and technological means already exists: product manager. The people acting in this role may not have business cards containing the title “product manager,” but product management is their essential job. The increased urgency of building a stronger partnership between business and IT is driving both productization and, by extension, a growing need for product managers.

Imagine three people sitting in a conference room, discussing the status of a project. The first is a development manager responsible for customizing and deploying a packaged application. The second is a business analyst who, through the medium of requirements, is advocating what the business users need. The third is a product manager representing the tech vendor from whom this customer purchased the packaged application.

The agenda for this meeting isn’t a happy one: After hitting many business and technical obstacles, the project is at an impasse, with business users and IT professionals blaming each other for many of the problems. After several hours of trying to sort through these issues, the business analyst and development manager turn to the product manager and ask an uncomfortable but understandable question: Who’s more to blame for the failure of this project, business or IT?

Unfortunately, with this cast of characters, no one is. It’s frustrating to be the product manager (which I was in this actual scenario) on the outside, because within a tech vendor, you have responsibility and authority over both the business and technical sides of the software. If there’s no reason to add a feature to the product, it’s your job to keep it out. If there’s a strong business argument to push Feature A aside to make way for Feature B, it’s your job to make that happen.

At the same time, you need to understand the realities of software development, such as scope, architecture, security, technical debt and other considerations. Consider for a moment how complex a single application can be, with functional elements, user experience considerations, integrations, underlying architecture, and other components. Applications do not exist in a vacuum but are themselves components of projects, with their own additional layers of complexity (timelines, process changes, change management, etc.).

#!
Product manager defined
Product managers don’t need to be outside of IT. In fact, a growing number of IT organizations are adding product managers to the org chart to resolve this conundrum. This person needs to be on top of the issues within the application development team, such as the prioritization of the backlog.