Force Mapping: A Tool For Fixing Systemic Organizational Issues

Stop Being Distracted By Symptoms and Fix Your Problems With Force Mapping

I frequently get approached by companies that need help with something in the realm of Product Management.

One of the most surprising things I’ve learned over the years, is that usually the best way of helping them is by not giving them what they want.

Sounds surprising and counter-intuitive right?

Allow me to explain.

That something they want help with rarely is the real thing they need help with.

When companies approach me for help, I frequently experience the following internal conflict:

1. Give them what they want. When I give them what they want, they’ll be happy and there’s a good chance they want to work together. But it’s pretty much guaranteed it won’t solve their problems. I can charge money doing something that, at best, offers a surface-level solution that will make things both better and worse in ways I can’t even foresee.

2. Don’t give them what they want. The risk of not giving them what they want, is that they won’t hire you and you won’t have a shot at helping them fix their problems.

What would you do? Do you pick option 1 or option 2?

I prefer option 2, because I want to make a difference. I want to emphasize option 2 is much easier if you don’t have financial problems and don’t have benched employees who must be billable.

Integrity is easy when conditions are easy.

But this is not an article about integrity, let’s answer the following question: Why do companies rarely know the real problems they need help with?

The Symptoms Are NOT The Problem

The main reason why I’m approached by companies is because they have a problem they’re unable to easily solve by themselves. That’s why they are looking for outside help.

The most common reason they’re unable to solve their problem, is because they don’t understand the actual problem they’re having. One of the telltale signs of this problem ignorance is that they come to you with a solution instead of a problem they’re trying to solve

Usually when companies reach out, they come to you with a solution, like:

1. Can you do an Agile maturity scan?

2. Can you assess the level of our Product Management maturity?

3. Can you help roll out the Product Operating model?

I usually then begin to ask questions along the lines of: what problem(s) are you trying to solve for? What challenges are you facing in your daily jobs? The answers you get are usually surface-level symptoms and NOT the real problems they’re having.

The symptoms are the tip of the iceberg, Let’s explain this using a simple example: let’s say you’re overweight and want to lose weight.

Being overweight is both a symptom and a problem. It could be a symptom of not exercising enough, or maybe it’s a symptom of your genetics. It’s also a problem. Maybe your knees hurt when walking, or you can’t walk the stairs without having to catch your breath. Maybe you can no longer fit in an economy class seat and need to buy more expensive tickets every time you travel.

Why does understanding the difference between symptoms and problems matter?

Your body is a complex system. There are no recipes to follow to resolve your problems.

If you make something better, something else will usually become worse. You don’t know exactly how it will pan out before you actually do it. Ozempic is a great example. The medication makes some things better and it will make other things worse. It’s all about making the right trade-offs.

The better you understand all your problems and symptoms, the better you can come up with a solution to fix them. Because your problem and symptoms are a complex web of interdependencies that all relate to each other.

Fix one thing, and you may break something else. This is why losing weight is so difficult, because we need to change our existing system with all its habits and behavior that produce the current status quo. Our habits and status quo are unique and almost flawlessly run on automatic pilot. The better we understand our current automatic pilot, the better we can resolve our current challenges.

The same logic applies for organizations. When you move up on your Agile or Product Management maturity model, you may actually end up making your problems worse. That’s because prickly complex problems can’t be linearized into a simple maturity ladder with a discrete set of levels.

It’s crucial to develop a solid understanding of your symptoms and problems before you can begin thinking about of the best way of improving your situation.

Example of a Force Map

Where do you start? Enter the world of Force Mapping.

Force Mapping: A Tool For Fixing Systemic Organizational Issues

Force Mapping is a tool inspired and influenced by the magnificent work of Michael Lloyd on Dysfunction Mapping for Scrum Teams.

Force Mapping is a framework agnostic version of Dysfunction Mapping that you can use to tackle organizational challenges.

Force Mapping helps you to build a mental model of all the internal forces, problems and challenges you’re facing so that you can figure out the best way of addressing them.

How do you do that? There are 8 steps to producing a Force Map.

Step 1: Formulate a Big Hairy Audacious Problem (BHAP)

Force Mapping begins with a BHAP: Big Hairy Audacious Problem. What’s the single biggest problem your company is currently facing?

This is the lens through which you’re going to view all the challenges, symptoms, problems and dysfunctions that are present in your organization.

The important thing to keep in mind: there are also things are going well. That’s why it’s called Force Mapping. There are good and bad forces at play. You want to discover the positive and negative forces that shape the current status quo.

The reason why it’s important to start with a BHAP is because you can’t fix everything at once. It’s not wise to quit smoking, lose weight and stop your gambling addiction all at the same time.

Force Mapping starts with a BHAP: what’s the single most important problem you’d like to fix?

Some examples of (anonymized) BHAP’s I’ve used in the past:

• Our teams are struggling to deliver. What’s slowing us down or making us less effective as a team?

• We have too much firefighting. What can we do to reduce firefighting and create a less stressful environment?

• We’re shipping lots of features nobody uses. What’s preventing us from delivering features that create value?

• How you frame the BHAP is the lens through which you view your existing organizational system. It has a big impact on the kind of answers the Force Mapping exercise will produce, therefore you should consider it carefully.

Some different flavors you can consider for a Force Mapping exercise:

• Cross-functional Force Mapping Workshop. You produce a Force Map together with leaders and team members.

• Team-level vs. Management-level Force Mapping Workshop Let teams(s) produce a Force Map and let managers produce a separate one. Where is the overlap? Where do both have blind spots? This can be incredibly informative.

• Pure team-level Force Mapping Workshop. Let one or more team(s) produce a Force Map together. Then use this team-level Force Map to engage with leaders.

If you only invite team members, you will get insight into the lower-level team challenges but maybe not the higher-level organizational dynamics that produce those team-level dysfunctions. It’s not necessary to include everyone in one or more teams, simply use delegates that adequately represent the different skillsets and perspectives.

Let’s use this as an example BHAP for now to better explain how a Force Mapping exercise might work:

Congratulations, you’ve completed Step 1. Now let’s go to the next step.

Step 2: List All Your Symptoms and Problems

When you have everyone in a room, list all all the symptoms and problems that are related to your BHAP. What symptoms or problems do we observe that influence our BHAP?

The key thing to stress here, we’re interested in the relationships. It doesn’t matter if it’s a symptom or a problem, or something else.

A problem can be a symptom, a symptom can be a problem. The categories used in Force Mapping are there to make sure we cover all our bases. It’s not about nailing the buckets and make sure everything is in the right category.

Ultimately, drawing all the relationships and interdependencies are what matters the most. Not whether we’ve placed them in the perfect (right) bucket.

Here is a simple example of what the second step might look like:

Make sure you don’t waste your time discussing whether something is a problem or a symptom, unless it results in adding something that’s missing which is not yet on the Force Map.

The point is to discover how all the different factors relate to each other to produce the BHAP. Not whether all the factors are in the right place.

Step 3: List All the Behaviors

We do things and don’t do things that produce the problems and symptoms. What are those things we do and don’t do (Behaviors)?

When everything is always considered urgent, this means we don’t have the time to do things the right way. When we don’t take the time to do things the right way, this will result in tech debt and production issues. Tech debt increases the number of production issues, and the elevated number of production issues ensures we don’t take the time to do things the right way.

Step 4: List All the Forces

Behaviors don’t exist in isolation. What are the Organizational Forces that are at play that shape our current behaviors?

You may decide to move some of the existing Problem or Symptoms to the Forces bucket, if you feel it fits better. But as I said, don’t have huge discussions about it, it doesn’t really matter, as long as the relationships and interactions are accurate.

The key reason why it’s important to think about the Forces is because the things you’re observing may be shaped by something else you’re not taking into account.

We’re going from the tip of the iceberg (symptoms and problems) to the bottom to discover the systemic issues which are more difficult to observe and spot.

Step 5: Explore the Status Quo

Organizational Forces don’t exist in isolation. What in the Status Quo of our organization shapes the forces we’re observing?

These should are the higher level aspects of how we’ve decided to organize ourselves.

Some examples of the status quo as related to our BHAP:

1. There is no clear company strategy or vision. What the company calls the strategy isn’t a real strategy.

2. The business decides the roadmap - resulting in too much work being pushed to the teams and technical debt not getting a priority

Step 6: Unravel the Mental Models

Our current Status Quo is shaped by beliefs and mental models. Unless we talk about the beliefs and mental models that underpin how we’ve chosen to organize ourselves, we can’t talk resolve the issues we’re facing in a systemic way.

The best way of unraveling mental models is by including an outsider or a newcomer who is still an outsider. Here are some limiting beliefs / mental models that affect the kind of solutions we come up to tackle our BHAP:

• Fixing technical debt slows us down.

• Estimates are supposed to be accurate, hence PUSHING work to teams is a sensible approach.

• We’re scared of making tough choices and trade-offs.

Step 7: Draw Relationships and Interactions Together

How do all the different factors on your Force Map affect each other? The most important thing of this whole exercise is to:

1. Create a shared mental model and shared understanding of the current challenges your organization is facing.

2. By drawing the relationships and interactions, you might realize something is missing, or something is redundant. Use this understanding to update the Force Map.

3. The finalized map can be used to decide on actions and experiments.

Step 8: Decide On Concrete Experiments (Actions) together

These are the kind of questions you should be asking and discussing together:

• What are the choke points on our Force Map that have the biggest influence on our BHAP?

• If we fix that one thing, will it potentially make something else worse?

• What elements on our Force Map should we tackle to resolve our BHAP?

• What are the experiments we will try to influence our BHAP?

• How will we know whether the change we’ve implemented has been a success?

Once you have a Force Map, you can repeat the same exercise and revisit it to see if you’ve actually fixed your problems and not made things worse.

Here is an example of what a finalized Force Map can look like together with all the relationships, interactions and action points:

As you can see, you now have a much better idea of what’s going on within the organization instead of potentially being distracted by surface-level symptoms that are impossible to resolve on their own.

Force Mapping: Stop Talking Symptoms and Start Solving Problems

Force Mapping helps organizations and teams to stop talking about symptoms and start talking about the real problems they’re facing.

Once you have a Force Map, then you can use use that understanding to inform the next actions and experiments you will run.

Those actions and experiments will then inform your future understanding and use that information to update the Force Map and come up with future actions and experiments.

Remember, the map is not the territory but without a mental model of what’s really going in your organization you’re flying blind: it will be hard to make changes or run experiments.

Instead of jumping to solutions and conclusions, the next time you run into a prickly problem, try running a Force Mapping exercise to understand what’s really happening and explore different avenues of resolving your problems together.

Feel free to send me a message in case you want to run a Force Mapping workshop. I’m happy to help out!