As Product professionals, we’ve all be faced with change. This is a consistent part of the job and one of the reasons I’ve enjoyed being in the Product space for the last 8+ years. As Product professionals, we understand that there are two types of change:

1. Change with context
2. Change without context

When we experience that has context, there is foundation that experience is built on:

1. Trust
2. Transparency
3. Understanding of how the need to change was arrived at

An example of change with context would be:

Currently, our process of discovery for determining the right problems to solve is slow (taking (x) number of days) and isn't providing us with enough insight to determine if the problem we're trying to solve is the right one at the right time (feature ambiguity which is leading to incomplete outcomes). By re-aligning our teams into smaller, focused teams we can shorten the time of determining we're focused on the right problems and create features which are purposeful and lead to the outcomes we're trying to achieve with our customers.

When we experience change that doesn’t have context, the foundations are different:

1. Mistrust
2. Ambiguity
3. A lack of understanding of how the need to change was arrived at. (ex. no problem statement clearly defined)

An example of change without context would be:

Currently, our process of discovery is long and we're not able to show value to the business against our metrics of features completed. We need to shift to Squads in order to create more features faster.

Why does the difference matter?

The difference starts with the foundations for which a successful (and unsuccessful) product cultures are founded on. Let’s break those down:

Trust

Trust is building block of all relationships. It’s either earned over time or given until reason is shown to retract it. Trust is built by sharing responsibility for successes and failures. In Product, it’s formed by sharing a common mindset that permeates the way people interact with each other. We’ve all see this manifest in different ways; a shared vision or a common ethos that an organization uses to bind its people around the ways we solve product problems.

Successful Product organizations know that a shared vision and mission along with giving teams autonomy to deliver on the outcomes that align to mission and vision is key.

Unsuccessful Product organizations fear trust. This could be because:

1. The mission and vision don’t stand the test of time against change
2. Autonomy means loosing control of the output

Transparency

Transparency is built on the bedrock of trust. It provides a clear and unobstructed view up and down the organization as to what decisions are made and why they were made.

Successful Product organizations know that transparency ensures that the vision and the mission are always aligned to in a constant world of change.

Unsuccessful Product organizations fear transparency and embrace ambiguity. This could be for a variety of reasons:

1. Fear of accountability
2. Fear of change

Understanding of how the need to change was arrived at

Finally, with trust and transparency as the anchors of the Product culture the people within the organization know that when change does occur that there is a clear and shared understanding of why the change was needed.

Successful Product organizations know that a clear and sharable understanding of change shows the product organization and its people that they trust them to make the right decisions to creating the desired outcome regardless of the process.

Unsuccessful Product organizations fear sharing how a need to change was arrived to. Reasons for this could include:

1. Fear of accountability
2. A lack of understanding the problem
3. Responding to the symptoms of a problem and not the root cause

How do I change a culture to embrace change?

That’s the million dollar question. There is no one size fits all approach to changing a culture to embrace change. But there are few key results that can determine if you’re moving in the right direction:

1. Less defects with work delivered
2. More meaningful interactions between product and development layers
3. More celebration around failure as learning
4. Less attrition in product and development teams
5. Customers are delighted

See something missing? Have your own experience to share? Leave a comment!