How do you align multiple product teams around a common goal and set of outcomes?
This was the challenge our VMware Tanzu Labs (formerly Pivotal Labs) team faced during a recent engagement with a client that was building software for a large-scale workflow that spanned multiple use cases with various end users and stakeholders. The solution required a number of applications working together in a system of systems.
How we did it
So, where did we start? We first needed to document the workflow in its current state. We used event storming and Boris exercises to provide a reference for the current workflow and to model possible flows for a new system. Event storming is a great way to quickly gain context on a new domain, allowing you to map out the current state and identify pain points and problem areas. The Boris process allows you to model the relationships between capabilities in the system and then move toward a new, notional architecture.
Illustrative example of event storm mapping
We then focused on creating a team to lead this effort, a portfolio team dedicated to delivering the desired outcomes for the client.
Creating a portfolio team
We put together a balanced team to lead the portfolio initiative. By “balanced team,” we mean, in this case, bringing together the practices and representation of lean product management, user centered design, engineering, and client leadership onto one team. Each member of the team provided a specific perspective and focus. For example, mission value, user experience, user value, technical architecture, complexity and scalability, and stakeholder and personnel management. The mission of the portfolio team was to create and drive the product strategy, aligning teams to deliver on a cohesive set of objectives.
The balanced team model is the same structure we had on each individual software development team, but at the portfolio leadership level. This also gave us the ability to build software ourselves and explore proof-of-concept solutions that we could learn from and use to inform portfolio-level decisions.
This team of four people was small enough to move quickly and was fully dedicated to the project. This allowed us to focus on strategy development and implementation and to be highly available for the teams and stakeholders. Each member of the portfolio team worked very closely with the individual product team members to provide guidance in their area of focus but also to facilitate the flow of information between teams and leadership. Without this, we have found that even teams working within a closely related space end up not communicating as often or as well as they could.
Defining the problem: What do we need to solve?
Now that we had an understanding of the current system, workflow, users, and the associated pain points, we needed to begin the process of homing in on the specific problem or problems that we would solve, and how we might approach this.
We used the initial research findings, supplemented with interviews with key stakeholders and user groups, to form a portfolio problem statement. This was an articulation of the current problems that we saw, a hypothesis as to how we might solve these problems, and a statement that outlined how we would know if we were being successful. We purposefully limited this to a one-page document comprising three single sentences, including bullet points for more detail or clarification where needed.
Creating a portfolio product strategy
With a clear sense of the problems to be addressed, we set to work defining how we might go about solving them. We created a set of high-level outcomes we aimed to achieve for the client. Importantly, we reached these in close collaboration with a group of user representatives at the right level with whom we had made a concerted effort to build close relationships early on. These goals represented outcomes for specific users and stakeholders that would make a substantial and meaningful difference to their overall mission. From there, we developed a cascading set of objectives and key results (OKRs), with each product team taking ownership of a section of objectives that would inform their quarterly priorities.
Implementing the plan
Before teams took ownership of these objectives, we took the time to discuss with each team which problem or set of problems within the portfolio they would be best positioned to tackle. A key principle we followed was the concept of co-creation. This meant close collaboration with teams in order to solicit their input, suggestions, and concerns with the plan. Ultimately, the portfolio leadership team owned responsibility for assigning problem areas and high-level objectives, but these decisions were formed through frank discussions with each team.
Assigning objectives, rather than solutions, to teams empowered them to self-organize and proactively collaborate with each other around solution overlap and integration points. Working in this way gave teams a strong sense of ownership over their respective products, and it helped them understand their place in the overall solution. This allowed them to make more effective decisions when coordinating and prioritizing their work. Our approach was founded on the principle that product teams, rather than leadership teams, are closest to the user and are therefore best placed to conceive and develop successful solutions. For these teams, frequent user research with an adherence to lean design principles was key to forming and validating the solution.
To build a unified sense of purpose and to provide situational awareness across different teams, we began the work with an internal kickoff. We shared the overall vision and goal outcomes that the portfolio was working toward and talked about the role each team would play in this ecosystem. There was also discussion around a notional architecture and integration patterns that we would explore. This was an opportunity for everyone to align on the overall vision, plan, and their role in that plan. The goal was for teams to be loosely coupled but strongly aligned.
Abstracted workflow cycle showing products 1–5 and their connections
Charting internal progress
Every month, we worked with each team to update the individual road maps and a portfolio-level road map we had created to keep track of important milestones and integration points. Sharing context and research and exploring the trade-offs of different approaches maintained the spirit of co-creation and, most importantly, ensured that the success of each team was tightly paired with the success of the portfolio. We wanted it to be impossible for a team to be successful without bringing the portfolio along with them. Everyone involved in building the product needed to have a level of autonomy that was motivating. And they needed to be engendered with the confidence to advocate for and pursue the solutions they knew to have the best chance of success. Being the closest to the end users, the individual team’s designers, product managers, and developers were able to make these decisions with confidence, surface feedback up to the portfolio team, and manage strategic decisions where needed.
We created and revised quarterly OKRs together. The teams provided the key results they wanted to measure, and the portfolio team worked with them to ensure that these OKRs continued to align with the overall portfolio strategy.
Challenges and takeaways
Is this actually important?
One of the most important factors to consider when undertaking this kind of project is to validate the assumption that your goals are important. It sounds straightforward, but all too often, initial misplaced assumptions about what is important to stakeholders and users can carry forward unchecked throughout the lifecycle of a project, leading to disappointment at best and a redundant and useless collection of products at worst. So, how do we mitigate this risk? Test those assumptions early and often! Express goals in the form of outcomes, informed by the responses to questions like these: What changes in behavior are desired and how will they occur? Who will benefit from this? Why are these outcomes meaningful to you? These should be discussed with stakeholders and users early on. Often, the idea that a stakeholder has in their head, their beautiful picture of a successful outcome, hasn’t been articulated sufficiently or received in the way they think it has. Make sure everyone has a shared vision of what success actually looks like and you can reduce the chance of problematic divergence as the project progresses.
Find a way to measure progress toward these goal outcomes. This can be tricky, and there is always the risk of defaulting to vanity metrics or a percentage of “completeness” but what you really want to know is: Are we changing the right behaviors with the product we’re shipping? Can we measure that improvement in some quantifiable, demonstrable way?
There are different ways to do this and different frameworks to use. We chose to use objectives and key results, but OGSMs and other constructs may be equally or better suited to your use case. In our situation, many of our team members were familiar with OKRs already and the framework worked well when applied to the different levels of our system.
Share and discuss these key results and demonstrate progress to stakeholders on a regular basis. Tight feedback loops help to minimize the risk of unhealthy disconnect between those building the product, those invested in its success, and the end users. We preferred to demo working software and seek feedback from these groups as often as we could. Demonstrating your ability to course correct if needed and acting promptly on feedback can help maintain trust. In our case, this usually equated to a bi-weekly sync with our key stakeholders and more frequent research sessions with the user groups. If they feel invested and closely involved from the start, it’s more likely that they will prioritize making themselves available.
What about the “system”?
When working within this kind of portfolio construct, there can be challenges maintaining a coherent overall approach to building the system. This is where technical guidance and structure is needed from the portfolio leadership team. In this case, we needed a lightweight way for teams to integrate their products as components of the larger system. We went with a self-service API model and provided a set of standards the teams needed to meet in order for this to work. This part of the process was more prescriptive but was necessary to get to the level of standardization needed to make a smooth connection between the individual products. This also allowed us to avoid the costly overhead of one-off integrations between applications, especially as we scaled the number of products. To get to this point, we met with teams to discuss the pros and cons of the proposed approach. It was important for engineers to be able to give their input and important for us to receive that with an open mind. We had to make a definitive call on the implementation pattern that would be used while still ensuring that everyone’s ideas and concerns were heard. Once teams had implemented the integration patterns, other consumers of their data were able to pull what was needed without having to wait for custom solutions. We also avoided lengthy security reviews that would otherwise be necessary with unique integrations.
How did we do?
We were able to meet our customer’s desired outcomes, delivering the first iteration of a system of systems that improved the users’ workflow experience and also surfaced critical data, which gave the customer the ability to analyze and monitor the process and plan further improvements. We were able to deliver on this in a much faster timeframe than the customer was used to. We attribute this to using a combination of factors, such as lean product development methods and keeping tight and responsive feedback loops between both the teams and the customer. The portfolio approach ultimately served as a crucial enabling function for the project. By combining a servant leadership style driven by a clear strategic vision, we were able to remove barriers to the teams’ ability to concentrate on building great software. With minimal process overhead, they could focus on solving the problems in front of them and use the architectural guidelines and vision to be proactive in integrating with other teams and products where needed.
