The Lean/Agile way to Manage Cross-Team Product Initiatives
Are you part of a company that has grown through mergers or acquisitions? Does your company have a portfolio of products they’ve built? If there is a horizontal strategy at play, then the executive leadership probably has intentions of integrating the different products to create a competitive advantage with a “best in suite” angle. The vision of seamless integration across the portfolio sounds lovely right? Though it’s a great strategy for growth, it’s up to the product and tech teams to execute and make it a reality.
When there are multiple product teams contributing to a single product feature, there will be responsibilities that cross over individual product managers. How can both teams have a sense of accountability for the single outcome of the integration? For cross-team initiatives, there are two philosophical strategies for how to decrease risk and increase probability of success. The best part is that neither interfere with Lean or Agile practices.
Strategy 1: Dual Responsibility
One strategy is to have two separate projects for each side of those integrations. Product Manager X has an integration with Product Y as the scope of their initiative. In turn, Product Manager Y must account for the integration with Product X as a separate project. On each team has a clear deliverable on their roadmap to ensure compatible interfacing.
If the effort amounts are unbalanced across the two teams or one team must finish their work before the other team begins, that can complicate things. If the work team X is doing requires less effort, they may do their portion of the work and wait months for the team Y to be ready for testing. By the time the both sides of the integration are ready to test, the code from team X may no longer be compatible and fixing it will require context-switching. A Gantt chart or something similar could illustrate the dependencies so that timing aligns better.
It’s important for each product manager to understand where this integration falls in priority against the team’s other initiatives. They must zoom out to see the full picture and choose which initiatives are most valuable for the company. If there are higher value projects, the PM should surface that early and explain why their team will be delayed with their side of the integration.
If the stars aren’t aligning, don’t worry, that’s normal. Shifting resources from the one team to the other team that doesn’t have bandwidth can assist with completing the integration. Alternatively, the PMs can scale down the scope to the key integration fields which might allow for the project to be completed on time. There may also be ways to make the development parallel rather than sequential. Either way, the two teams and their leaders need to frequently communicate with each other and stakeholders so that everyone knows what progress has been made and when there are roadblocks. (This has of course never resulted in finger pointing…)
Strategy 2: Single Responsibility
The other strategy is to assign and single person the responsibility of overseeing the integration project. This is the way to go if there are multiple teams working on various parts of the same larger integration initiative. If there are multiple product teams all involved in a large project, having joint responsibility for success may result in what I like to call an everybody/nobody situation. By placing one team member in charge of the project, they become the single point of contact for stakeholders.
By having someone looking at the entire project, it becomes clear what could happen in parallel and what needs to be sequential. They’ll be able to see the true cost of delay for certain parts of the initiative and decide what is most valuable for the customers and company’s strategic growth. The manager should send out regular status reports to stakeholders which will become the source of truth for what has been accomplished and what’s next. They can also raise a red flag if it looks like the deadline will be missed and be able to explain why without bias towards protecting a single team.
Is there a market event that we know we need a demo ready for? If so, which key pieces do we really need to prioritize, and what can be delayed? Or do we need certain pieces completed, but a lightweight version of them will suffice? Figuring that out allows for better prioritization for those larger projects. When there is someone who knows which phases are crucial and time-bound, they can align the teams towards the goal of completing those pieces ASAP.
Dedicating someone to the tasks of coordination and communication provides an excellent opportunity for someone looking to become a manager. By owning the larger initiative, they can demonstrate their leadership skills and get exposure to other teams and key stakeholders across the organization.
Does either strategy lock a project into parallel or sequential work?
Nope, either can involve parallel work across teams or sequential work, or even some combination of both. Each initiative and company has factors that mean one option is better than the other.
For parallel work, I think it’s best when each individual product team has three phases for their own contribution to the project. The first phase is all teams creating the simplest API endpoints and data feeds based on the agreed upon specifications. Phase two would be connecting the interface across the products to ensure the APIs and feeds work. Phase three would be expanding the integrations to be more robust. When there is a separate phase in which the end deliverable is the completed working integration, all teams know they are not successful until the interface works.
If that doesn’t seem like the right fit for the current initiative, try something more sequential. Each phase of the project can be dedicated to a single integration between two products. For example, phase one when product X + Y integration and phase two is when Y + Z connect. When each integration is it’s own phase, it is possible to prioritize which of these integrations provides the greatest value to customers. Ensure alignment to company objectives by evaluating which phases contribute most to key outcomes such as logo retention or increased profitability.
It’s also important to note that each phase of the project doesn't necessarily involve development work. A phase could be a pause for beta testing or gathering feedback. Breaks in the work are excellent opportunities for learning and implementing Lean practices.
Do these large projects conflict with being Agile?
The short answer is NO. Simply because there is a plan for what the business wants to achieve does not mean that how it gets accomplished cannot be Agile. The plan is a high-level overview of the phases and pieces needed to consider the integration complete. It’s a skeleton for how the products will interact. That skeleton will then be broken up projects into smaller pieces. There will be plenty of opportunities to learn and adjust as the team advances.
In fact, good project management enables successful implementation of Agile practices. It provides a clear understanding of who is involved with each phase and what the end state of that phase is. It outlines dependencies, allowing faster reaction and pivots. It may even enable proactive consideration of how a single change impacts another team or phase before a problem even occurs.
How does a team choose which option is better for the initiative?
First, it’s important to understand how big the project is, what the current resources are, and how many teams are involved. If the project is large or involves key strategic initiatives, it’s better to assign someone the responsibility of seeing the project through. When there are multiple teams collaborating, it is ideal to have someone supervise the process, provide streamlined communication, and ensure an optimal outcome.
If the project is smaller and doesn’t require executive updates every few weeks, the involved teams can probably self manage the initiative. In this case, all teams should have a clear deliverable on their roadmap for interfacing with the other product. A product executive can look at all of the roadmaps to know when to expect the completed integration.
Can this really make a difference?
Absolutely. I worked with a company that grew by M&A. With the goal of integrating over 50 products from different companies, they had to elect someone to shepherd the process. They identified a product manager eager to have an opportunity to stretch across the organization in a greater capacity, and dedicated him to this role.
He started by meeting with every product manager to understand their visions, backlogs, short-term plans, and long-term strategies. From there, he started to outline a strategic project across the portfolio. He put together templates around what a roadmap across the organization would look like and defined the different phases and the visual representations needed for an impact-effort matrix for product integration.
Through identifying the types of integrations across teams, he began seeing immediate traction. He aligned products and product teams across the organization, providing both internal and external value. He sent out regular communication to the executive team so that they were well informed and trusted that ample progress was made.
-------
Does your team have a big integration they’re working on? What do you think would work best in your organization to minimize the risks and ensure the desired outcomes? What have you seen work in the past? What do you never want to do again? We love hearing stories from the trenches!
Tami Reiss is the SVP of Product Strategy at ProduxLabs and the CPO in Residence at Insight Partners. She writes about how Product Leaders can do more to focus on what’s important for a company’s growth and streamline internal processes to yield results. You can follow her on Medium or @tamireiss on Twitter.
