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.
This person also needs to be able to operate within the context of the larger project and the bigger business objectives that the project is supposed to achieve. When the needle on an executive dashboard moves downward because of application issues, someone needs to respond urgently.
What makes a product manager different from other roles that combine business and technical domains, such as business analyst and project manager? Product managers have a wholly different to-do list:
● Define the product. The title “product manager” implies that there is a product to be managed. In many situations, the first job of a product manager is to separate applications from the projects in which they are used. As a product, an application has a specific mission that transcends any single project.
● Shepherd the product. Where other roles, such as business analyst and project manager, move from project to project, a product manager stays with the product throughout its lifetime.
● Set a product road map. The lifetime of a product (its road map) identifies a set of capabilities that the product needs at each clearly defined stage in its development. The road map may intersect the timeline of a project, but it remains distinct from it.
● Manage product-specific requirements. Both business analysts and product managers are responsible for requirements. However, the product manager looks at the list of requirements from a different perspective. Not only must the product satisfy the current customer (within organizations, projects and the users who benefit from them; outside organizations, actual customers), but it must also address the needs of future customers. Therefore, when confronted with a project lead’s requirements list, product managers may push back harder than business analysts because they are responsible for the product as a long-term technology investment.
● Ensure the economic success of a product. For a product manager, the word “investment” has very real meaning. Unlike a business analyst, a product manager is responsible for the long-term economic performance of a technology component. Unlike a project manager, the product manager measures investments at the component level, not the project level.
● Fit the technology into the larger portfolio. This investment-mindedness turns product managers and portfolio managers into natural allies. Where a business analyst or project manager might have little interest in the organization’s larger portfolio of IT investments, the product manager makes the case for the importance of a product within that portfolio.
● Accelerate business outcomes. Product managers develop a keen sense of how their products can contribute to business outcomes. For example, the product manager in charge of a collaboration tool has seen how, in earlier projects, users have made good use of the technology. The product manager carries this knowledge forward into future projects, in which team members may welcome any help making the collaboration tool successful.
● Define metrics. Product managers can help a great deal in developing metrics, as they already know how earlier users have measured the technology’s value.
● Market the product. If no one owns a product, then no one is responsible for marketing it. Product marketing skills are important for both internal systems—to ensure user adoption—and external systems when fitting the application into marketing activities.
Perhaps the greatest difference between product managers and other roles lies in the realm of productization. While it might seem strange to have a product manager before you have a product, in practice product managers can be the vanguard for product-centric development. Converting development projects into actual products has many benefits, such as creating a real partnership between business and IT, and creating greater agility in adapting technology to address a rapidly changing business environment.
But productization does not descend from the skies. Here, once again, we see where high-level objectives, such as “Go forth and productize,” are no substitute for the lower-level work needed to define and maintain products. Someone needs to recast the backlog in product terms, define the road map for the product, track the economic performance of the product as an investment, and market the product internally and perhaps externally. None of these tasks will happen without a product manager.
Tom Grant, Ph.D., is a senior analyst at Forrester Research, where he serves Application Development & Delivery Professionals. Join Forrester’s free webinar on Customer Empowerment on July 27.
