What are the detailed steps for building my framework?

Continuation of A Product Director’s Quest for Change and New Capabilities Part 3 of 4. (You can read part 1 and part 2.)

The second part ended with Sara asking Kim: “This looks complicated, please explain”

Read on about how Product Director Sara and Agile Coach Kim created their Agile model. 

Identify Essential Parts of Your Product Group

Okay, I will explain step by step how to come to the Product Group. I will use three critical guidelines that help you avoid common mistakes and show how your product group and larger organization can be built up from scratch.

Our goal is to identify all the essential components of your product group, including teams, individuals, processes, services, and systems, necessary to accomplish its purpose or mission. 

To begin, we define the product, which involves two steps. 

• First, we determine which of these components are required to develop, enhance, or maintain the product. 
• Second, we identify the revenue stream associated with the product, as it is a critical indicator of its viability.

To identify the product, we start with the customer or customer segments and determine their needs or problems that the product aims to solve or satisfy. Then, we select a set of features, that users would use to address their needs or problems. For each feature, we then identify the teams and individuals who need to develop, configure, or update it, as well as the systems, processes, and components that require updating or configuring. This process results in a comprehensive list of organizational elements. The picture below shows the whole idea I just talked about.

Outside in Product Definition

Now, some of these elements will be required more often than others. For example, in the graphic below you can see that the Sales Force team is involved in 4 features while Web team only needs is only involved on a single occasion.

Feature HeatMap. An X means the team is required for the corresponding feature

Also, note that Sales Force, Siebel and ESB teams are required most of the time in developing a feature. This type of information is useful to decide which skills are required in cross-functional teams. Obviously, creating teams with Sales Force, Siebel and ESD skills likely gives you the most adaptability.

So, based on this exercise we created the initial setup of the cross-functional teams. See the graphic below.

In the second step, we analyze whether these elements together create an end-to-end revenue stream and deliver on the mission. If not, we identify and add the missing components.

That brings us to guideline 2. Guideline 2 is about making well-informed decisions regarding the selection of skills for your cross-functional team, as well as determining which functions to incorporate into your product group. To do so, it’s necessary to gather additional information. One effective method is to assess the nature and intensity of the dependencies involved.

Uncertainty and Frequent Two-Way Dependencies

Let’s consider three types of dependencies – pooled, sequential, and reciprocal. Let me explain why. The graph below shows the coordination cost associated with each type of dependency. Reciprocal dependencies have a coordination cost that is approximately twice as high as the other types. 

Reciprocal interdependence occurs when teams depend on each other’s work and need to coordinate regularly. Sequential interdependence occurs when the output of one team is the input of another. Pooled interdependence occurs when teams rely on shared resources.

Therefore, when selecting skills for inclusion in cross-functional teams, it is advisable to prioritize those with reciprocal dependencies first, followed by sequential and pooled dependencies. Units or skills that have sequential or pooled dependencies could potentially be separated into a distinct unit within the product group and not included as part of the cross-functional teams.

Should a skill be in or outside the cross-functional teams?

Using insights into the types of dependencies and their strengths, you can then determine which skills should be in the cross-functional teams and which could be separate units. In the graphic below you can see the reciprocal dependencies contained within each cross-functional team and separate teams with sequential and pooled dependencies.

So, this already starts looking like a product group that can deliver on its purpose, don’t you think?

We’ve been working on identifying the essential parts of our product group and improving the interactions within it. However, we also need to decouple the product group from the larger organization to be adaptable. To achieve this, we need to understand an important aspect of coupling that may seem counterintuitive. 

Let me share the third guideline that we can use for decoupling the product group. 

Coupling With Units Outside Your Product Group

While we want decoupled components in a software system to make changes easily, we need loosely coupled product groups so each can change direction without affecting others. 

In a standard product-based organization, there are various functions, such as product development, sales, marketing, IT, as well as administrative functions such as staffing, planning, and budgeting. The key question from an Agile organizational design standpoint is how to assign these functions to different units within the organization in a manner that best serves adaptability. The simplest approach to organizational design involves assigning each function to a distinct unit. However, this can get us into trouble rather quickly.

Previously we saw a bottom-up study of dependencies to determine the cross-functionality of the teams, now we are looking top-down to identify any coupling of the functions (e.g. KPI’s) of each unit (e.g. department).

The ideal scenario is for each unit to perform its tasks and make decisions that enable them to achieve its goals without hindering the ability of other units to fulfil its own functions and achieve its respective objectives. Nonetheless, when functions are interdependent, it can result in significant issues.

“Coupling between unit functions is associated with increased coordination costs, goal conflicts, ineffective or dysfunctional government, loss of productivity, and, most importantly, lower ability to respond to change. “

—Organization Design, N Worren

So, we need to decouple these unit functions so that your product group can change direction easily.

In general, there are three ways to resolve the coupling:

1. Restructure and transfer responsibilities between units or to a separate unit. 
2. Merge units so that they share measures of success or customer outcomes.
3. Redefine functional goals to remove overlapping and conflicts between units.

A result of decoupling could be that responsibility is added to your product group. For example, imagine that sales are an essential part of your product group to achieve its mission, then it could be that you will need your specific product sales in your product group. Sales skills would not be needed inside the cross-functional teams but these would be placed inside the product group as you can see in the graphic below.

There is much more than we ended to take into consideration, but by following these three guidelines you will minimise your biggest risks. Anything else I can help you with?

I understand that, but it is already getting late and I really need to go home, so let’s leave these topics for another day, okay? Also, maybe you should visit creatingagileorganizations.com, there is a lot of interesting content there about Agile Organization design.

In the last post, we cover decision making, coordination and shared services.