November 16, 2021

From Project to Product to Problem-Solving: Driving Transparency

By IT Revolution

This post is an excerpt of the From Project to Product to Problem Solving guidance paper by Ross Clanton, Amy Walters, David Silverman, Heather Mickman, Lucas Rettig, Pat Birkeland, Paula Thrasher, Rosalind Radcliffe, and Jeffrey Snover.

As businesses become increasingly digital and product driven, companies are pivoting to product-centric operating models. The backbone of such models is a network of teams aligned to a set of value streams and empowered to set their own objectives and paths to achieving them. Unlike project-driven companies, which are driven by temporary endeavors with predefined scopes, product-centric companies organize people and goals around products that continuously deliver value to customers.

While much more agile than their project-based predecessors, product-based organizations face two common execution challenges. First, maintaining continuous alignment among multiple autonomous product teams is a daunting task. Leaders’ perspectives on what is important is likely to vary based on the products they lead. To their teams, it can be very frustrating when a corporate-level initiative disrupts their local prioritization processes, causing them to pull focus from what is most important for the product to what is most important for the business.

Second, even with the most thoughtfully designed value streams, some dependencies between products typically remain. When dependencies cannot be decoupled, product teams must negotiate whose roadmap will be compromised, which is a challenging exercise in the absence of a larger, global prioritization framework.

How Do We Solve This Problem?

These challenges of initiatives that supersede product teams or require execution across product teams are not insurmountable, but addressing these challenges does require deliberate executive action. First and foremost, organizations must create a common operating picture across their team-of-teams. This operating model can take the form of mapping value streams and mapping a product taxonomy across the enterprise. The strategic priorities of the business should be well understood across product lines, empowering local product leaders to make decisions about their products that are consistent with the goals of the business.

Additionally, businesses must leverage a transparent prioritization process that leaders can anchor to when making prioritization decisions for their own products and while navigating dependencies. Finally, it is important to reduce dependencies across products to the greatest extent possible, but also to have a process in place for negotiating them when they do arise.

Driving Transparency & Creating a Common Operating Picture

As said in the opening pages of Making Work Visible by Dominica DeGrandis, “It should come as no surprise that we can better manage what we can see. When we can’t see our work, our options are obscured. We’re blind to our own capacity and we certainly can’t communicate that capacity to others.”

Creating transparency to enterprise initiatives, the prioritization of those initiatives, and how they map to persistently funded product teams is critical to balancing high-value business objectives with overall team capacity. This mapping activity can be done in a variety of ways. What’s important is that you create a visualization of existing product teams across the enterprise and how they “light up” or are impacted by enterprise OKRs and initiatives.

Example tactics include:

The Business and Technology draft high-level business cases that articulate an executive summary of the problem to be solved, the desired business outcomes and key metrics, and swag estimate of the overall investment.
Map the business cases to enterprise strategic themes. Determine if the business case enables enterprise strategies; if it does not, then consider prioritizing the business case down the list or removing it entirely (maximize work not done).
Map the business cases to the impacted product teams. This mapping activity can be done with stickies on a whiteboard, in a virtual whiteboard tool such as Mural, or even an Excel spreadsheet depicting business cases along the left axis and product portfolios across the top axis. “Light up” impacted products with conditional formatting to create a heat map visual of the demand against existing product teams.
Once the demand against product teams is visible, capacity can be assessed to determine which product portfolios should invest in additional fixed capacity teams, or if lower-demand product teams can be mobilized to higher-demand products.

The principle to consider here is “bring the work to the people” (product model) vs. “bring the people to the work” (project model). Reduce the number of investments by deduplicating development efforts by mapping the work to the existing product teams rather than spinning up new temporary teams repeatedly.

As leaders we often focus on the symptom we see—in this case, why are different parts of the organization not aligned in solving the key strategic business problems? However, a better starting place would be to ask how we might create a shared understanding that captures the problem to be solved as well as our current alignment and execution around that problem.

The military achieves this by creating a common operating picture—a unified visualization of key operational details that captures information across the leadership command structure. It is a hub of key information, providing a shared understanding of the problem and awareness of the current operational state of the organization and environment.

While a core DevOps idea has always been to bringing together Development and Operations through a set of shared tools, we need to go further. The broader business—not just the technology organization— needs to orient around the common problem to be solved, the current state of solutions to address that problem, our customers, and the markets we compete in.

Transparency creates awareness and shared understanding, and it enables alignment, focus, unity, and trust. Once transparency to strategic priorities is established across business lines and technology, then a productive conversation around prioritization can be had. Bringing together business and technology priorities creates a unified pathway forward for teams to discover and deliver the most efficient solutions to complex problems.

The combination of DevOps and shifting from project to product brings intentional ownership, autonomy, and a breakdown of working silos across functional organizations. Often in large, complex organizations the strategic silos remain at the enterprise level, which ultimately will lead to team disruption. In order to drive transparency around how strategies connect to execution, a centralized initiative backlog should be established. Simply put, anchor the organization’s single source of truth to one list of priorities. Then create alignment and unity by aligning strategic initiatives to OKRs and map the initiatives to persistent product teams.

A backlog is a list of items required to support a larger initiative. An initiative backlog is a list of initiatives required to support a business objective. Gathering all initiatives across business lines and technologies is critical to creating transparency across the enterprise. Figures 2, 3, and 4 offer example visualizations of how an organization might map enterprise objectives and initiatives to product team initiatives and OKRs.

Example 1

Example 2

Example 3

Actions You Can Take

To help drive transparency and create a common operating picture within an organization, try these accelerating actions and avoid these decelerating actions:

Accelerating Actions

Create centralized transparency to all “big rock” business priorities.
Map the “big rock” priorities to the product teams.
Leverage tools to outline problems to be solved & outcomes to be achieved—the what and why, not the how.

Decelerating Actions

Polished PowerPoint effect; using formal meetings/approvals & artifacts to create siloed formality with not visibility.
Spinning up temporary project teams that end and lack ownership of the value created.
Prioritizing in silos with no transparency to how priorities impact multiple teams.

To read about how to move from project to product to problem-solving, read the full guidance paper here.

- About The Authors

IT Revolution

Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.

1 Comment

Julian M Gordon Dec 27, 2021 9:53 am
I apologise for this comment without having read the contents of your article, but I feel the need to respond to the actual title of this resource. I like the outcome: "Driving transparency". I am just not sure of the driver: "From Project To Product To Problem-Solving". My concern here, due to the order, is that the focus could center on the problems stemming from the project itself. Should not the process be "from problem to solution", or "from problem to project to product to solution." What I want to question: Is not the product the solution? Or are they different? My concern here is that we have become myopic, and are mistaking the component for the whole. And this might lead us down the rabbit hole.Humbly yours,
Reply

with Dominica DeGrandis

with Matthew Skelton & Manuel Pais

February 26, 2025

June 4, 2025

By Gene Kim

By Dr. André Martin

From Project to Product to Problem-Solving: Driving Transparency

How Do We Solve This Problem?