@johncutlefish's blog

Check out Iterate.fm, my podcast with friend and coworker Tareq

PM “Responsibilities” ?

Published: December 22, 2016

There are a bunch of ways to unpack this question.

In this post I look at the front-line team’s perspective, and share real world results from a team exercise. In short, I don’t have the answer. You and your team has the “answer”, and your context will change next week and you’ll need to recalibrate. I explained this point of view recently in the Product HQ Slack group when asked about the differentiation between PO/PM duties, but I think it applies equally here:

Get in a room. Make it safe for people to speak their mind. Make the invisible work visible. Do a value stream mapping exercises. Make temporary working agreements visible, but always subject to negotiation. And then find a way to regularly inspect and adapt. In any rapidly changing context, roles and responsibilities will be in constant flux. How you work will be in flux. If they aren’t, you are probably over-optimizing on efficiency (unless you are in a very, very stable domain). We often address the symptom … “if only we had clearer roles and responsibilities”. And then a consultant comes in a writes a bunch of bullet points. And the problems persist. Why? R/R wasn’t the problem. Having the trust/safety to adapt and converse was the problem. Strict “contract negotiations” on bullet points broke in a matter of days.Here’s the messiness from the real world.

In this exercise, the team brainstormed areas of responsibility for the product manager. As a team member, the product manager participated. Together they removed perfect duplicates, but opted to keep items that overlapped but had some unique characteristics (e.g. coaching and facilitation). I was blown away by how many items they brainstormed in the ten minutes provided.

Independently, the engineers and product manager looked at each item and indicated who was responsible for the task/skill on a sliding scale. A score “in the middle” meant that the responsibility was shared 50/50, whereas a score on the left or right extreme meant that the PM/Engineers assumed full responsibility for that item. Importantly the group was asked to take a broad view of responsibility … “these are hats that we can all wear, and are not written in stone”.

What do you notice? Where does this team need more shared understanding? Where is there agreement and disagreement? How might you go about addressing those deltas? Is some disagreement healthy?