Avoid conflict and confusion: Create a responsibility map

All product organizations have internal conflicts. This is often due to poorly defined roles and responsibilities. You can avoid a lot of pain, stress — and staff turnover — by addressing this. So let’s address it right now!

These poor definitions of responsibilities are especially common in the “pressurized middle” of the product organization. For example, the: 

• Project Managers 

• Development Managers 

• Product Managers 

• Product Owners

Is it a title or a role?

For example, the Agile role of Product Owner (PO) is at the core of many development activities. Sometimes this role is an actual job title, but often the role of PO is included in another established position. 

In both cases, it is important to list and define the actual responsibilities associated with the role. 

Every product organization is unique

Product organizations have unique tasks and responsibilities. It is not possible to have “off-the-shelf” recipes. No ultimate list of responsibilities that maps out exactly what your Product Manager or Product Owner should and shouldn’t do. 

Each team is unique

Each product organization must agree on responsibilities separately. And even that is just the baseline.

Then there are always differences between projects, products and departments. Not every team has the same kind of division of responsibilities, because you also have varying:

• Product complexity

• Market complexity

• Individual experience

• Areas of specialization

• Individual workloads

Say hello to the responsibility map 

In every team, agreeing on responsibilities is much easier if the product organization has a responsibility map as a starting point. Each team can then discuss, agree on, and document their unique situation. 

When you have this in place, you will see: 

• Improved cooperation

• Less conflict

• Better division of workloads

I always recommend my clients to document the roles and responsibilities within the product organization in a map of roles and responsibilities. 

Here is an example of what it could look like: 

Image: Responsibility map of a development organization

The map should be combined with a more detailed list of responsibilities for key roles such as Product Manager, Product Owner, and Development team. And this could look something like this: 

Image: List of responsibilities for key roles

Since a visual map cannot contain as much information, there is a clear benefit in having both a visual overview and a more detailed list of activities. They both add clarity in their own ways. 

Top 5 reasons you should have a responsibility map

1. It makes you think. Simply by creating the map, you will discuss roles and responsibilities. This in itself is useful and will reveal potential gaps, overlaps, and misunderstandings. And by documenting the map, it becomes easier to address each issue that appears. 
2. You can adjust locally. With all responsibilities documented, individual projects and teams can determine if they should follow the blueprint or if their situation requires local adjustments. Maybe in your project, the best person to do something is not the Product Owner, but a developer (due to capacity or expertise). With a concrete map, it is easier to agree on and document this. 
3. Easier onboarding. Onboarding a new member of the product organization becomes simpler. Just give them the map and they will quickly see ”how things are done here”. 
4. Hire the right people. Finding and hiring people is easier. The responsibility map will reveal both the needed type of person and where your needs are the greatest (where a person is overloaded).
5. More understanding. It becomes easier to discuss what works well and what doesn’t. Somebody who asks “Why do I always get such poorly documented requests from you?”, will more easily understand how much the other person has on their plate. You cooperate better and can see more clearly where delegation and help are needed. 

How to build the map

Building the responsibility map can be done in a workshop with a few selected representatives from all the involved roles. The workshop process can look like this:

1. Have people list the responsibilities of their own role on a common whiteboard or a tool such as Miro or Mural.
2. Once the responsibilities are listed: discuss and clarify. 
3. Identify responsibility gaps and overlaps. This can be done by asking the participants of the workshop to list things they would like people in other roles to “do more” and “do less” of. 
4. After discussing the results, write them down into some form of map for further review. (This can be done after the workshop.)

The final map usually takes some weeks to build and agree upon. You can’t achieve it all in the workshop. The workshop is just a quick way to get the work started.

There you have it! It’s worth a try.

My experience has been that the activity of responsibility mapping will help any organization cooperate better, and they will have far fewer conflicts in their work.