Fostering collaborative relationships from the outset of project work is vital but sometimes difficult. With big budgets, tight deadlines, and many moving parts, projects are ripe environments for conflict. This is especially true for two key stakeholders: the product manager and the program manager.
Together, these roles ensure that software delivery conforms to rigorous technical standards that support organizational strategy. But in practice, separate and competing approaches often create tension between product and program managers, which can impact products, teams, and even the bottom line.
One of my program management roles was for a company embarking on an enhancement of its legacy cybersecurity system. After kicking off the program, the product manager and I quickly ran into challenges, clashing over decisions made when each of us felt our views or priorities had not been considered. This is not an unusual experience.
By coming together to better understand each other’s roles and needs, we were able to develop a new model for communication by identifying three central points where the relationship between program managers and product managers can go awry if not handled with care and a little foresight.
This conflict resolution strategy alleviated tension and resulted in a more positive project environment, as well as a smooth program delivery. What we learned can help program managers develop their professional relationships and create real, sustainable synergies with their product managers.
Roles and Responsibilities
Program managers have an organizationwide view. They are responsible for planning and ensuring that the delivery of the program’s output is aligned with the overarching business strategy. With that high-level perspective, program managers coordinate with stakeholders across teams to eliminate barriers, help them meet key milestones, and monitor progress continually. They are in charge of budgeting, scheduling, and resource allocation for the program as a whole.
In contrast, product managers lead the product team. They oversee the problem-solution space: verifying customer needs, gathering requirements, building a product vision and strategy, creating a roadmap, prioritizing features, and collecting user feedback.
Program Manager vs. Product Manager
The execution of numerous interrelated projects
The development of a product or products
Return on investment
While a program manager concentrates on how and when a product is built, a product manager’s remit is the what and why. Despite—or perhaps because of—their different areas of focus, both roles are crucial to the delivery of high-quality, timely, and cost-effective projects. Both roles also work toward the same outcome: creating products that succeed in the market. Improving communication between the program manager and the product manager is, therefore, undeniably valuable.
The benefits of more frequent and effective communication between product and program managers are best realized at three places along the project journey: product vision and strategy, release planning, and product architecture. These junctures represent high stakes for both roles, and yet they are also touch points where communication is most likely to be deficient.
Product Vision and Strategy
Modern product management recognizes vision and strategy as important artifacts that bring people together in the pursuit of a shared goal. Developers and other team members need them to avoid drifting aimlessly from sprint to sprint with a never-ending product backlog and no context for the features they are asked to build.
The product manager establishes the product’s vision and strategy, but if the program manager doesn’t share an understanding of the project’s overriding purpose and journey, it can be difficult for them to anticipate changes, keep the program on track, and articulate progress to senior leaders. In previous roles, scant communication around the vision and strategy meant I was often blindsided by changes the product manager made to the project’s scope and priorities, making it difficult for me to plan. This, in turn, caused frustration for the product manager.
Knowledge of the product vision and strategy also enables program managers to identify potential blockers and work toward mitigating them. The product strategy often evolves as new information, competitors, and technologies arise in the market, so maintaining transparency throughout the process is key.
At the outset of a project, program managers should be clear about when and how they would like the product manager to communicate the initial vision and strategy, and should plan regularly scheduled opportunities to connect in case anything changes. To get buy-in for these touch points, emphasize how the product manager can benefit from consistent communication too, in terms of delivering on their resource needs and managing stakeholder expectations.
Another stage of the Agile development journey where ineffective communication can jeopardize project success is release planning. By working in releases, the most salient features can be delivered first. Without proper planning, businesses might expend valuable resources building features that users may not need.
While this task is traditionally the product manager’s responsibility, the program manager’s perspective is important and can offer valuable insight. Program managers should take a proactive approach by initiating high-level discussions about release cadence. The product manager will work with their team on the details, but a program manager can provide input on capacity or commitments in the wider context of the program, which can influence and even enhance the product manager’s approach to release planning.
I’ve found that the final sprints leading up to a release are a good time to check in with the product manager and weigh in on reprioritization or descoping where needed. There’s always room for change in Agile, so collaboration should be ongoing.
There are many reasons why a product’s architecture may need to change: to allow more frequent and reliable deployment, more flexible scaling, or greater freedom of tool selection. Architectural changes are often big undertakings. The associated costs and time will vary depending on scope, but the program manager will likely need to alter budgets or schedules as a result.
Changes to product architecture that are not factored into planning can lead to barriers or delays further down the line. During the third year of one program, for example, the business opted to move to a cloud-based system, and leveraging those benefits meant changing the product from a monolithic to a microservices architecture. This resulted in delays and higher costs, as well as a re-estimation of the entire backlog.
While architectural decisions are owned by engineers, product managers will have knowledge of the associated benefits, trade-offs, and risks. When possible, program managers should use this knowledge to get an overview of the architecture, how and when it might evolve, and the impact this might have on the product roadmap. An in-depth understanding is unnecessary; insight into the model and potential changes are all that’s required to provide clarity and better prepare for what’s to come. Gaining visibility into the architectural choices at the start of a project will allow a program manager to more accurately assess risks and reduce the chance of major scope changes derailing the program.
Lean Into Your Differences
Project outcomes are not achieved using technical skills alone; the ability to develop good working relationships is an equally powerful and necessary skill. Regardless of industry, effective communication between the program manager and product manager is a crucial factor in successful outcomes.
There are similarities in the way the roles operate, but be mindful that a program manager will typically be more of an executor, while a product manager is likely a creative thinker—so their approaches to solving problems will fundamentally differ. Lean into these differences: The product manager can use the perspective of the program manager to great effect and vice versa. Both should be generous with their insights and concerns.
As teams become increasingly distributed, managers should strive to be more deliberate, transparent, and proactive in the ways they communicate. Knowing where to bridge potential communication gaps, then, is less of a conflict resolution strategy and more of a conflict dissolution strategy.
Product vision and strategy, release planning, and product architecture are just some of the touch points where clearer or more frequent communication can foster a positive, collaborative environment. Start there and other opportunities for improvement will undoubtedly come to light as you progress. Remember that each role is influential and relies on the success of the other.