“-OK, so I get that we’re a product team now, but what am I personally responsible for?”
That question, that single question, hides a complex much bigger story.
The scenario comes from the first time I coach a pilot team shifting to the product model.
What follows are more queries and debate. Words like “mandate” or “RACI” get thrown around.
So what’s going on?
What’s happening underneath the surface?
Why is responsibility such an important aspect to make clear?
It’s all very human.
As individuals we want to understand what we should do and what we own. If we don’t, we feel uneasy.
The root cause: when moving to the product model, team dynamics are shifting. There’s a new playing field. There’s even a new game to play.
You’re moving from being individually responsible for your part to feeling collective ownership of the outcome, the results. It’s a completely new paradigm of doing work.
What’s certain is that there’s great tension between these two worlds. You still need to deliver your part, but you also need to feel ownership of the whole.
And that’s easier said than done.
That tension, if not surfaced and addressed, will compound over time, until it breaks. It’s the crux of why most transformations fail. It’s not just a shift for pilot teams, it’s a cultural shift for the entire organization.
I had a chat with Gabrielle Bufrem a while back discussing this topic and she used the analogy of moving from swimming to football. In swimming, you focus on your own actions. In football, you have to constantly adapt to what your teammates and opponents are doing. The outcome is shared.
So how do we foster this cultural shift? How do we bring to light that there’s a new game to play?
The connection and difference between responsibility and accountability
Before we jump into how to handle the shift, let’s discuss two important words: responsibility and accountability. These terms get thrown around in meetings and workshops every day, usually without much thought.
Here’s the subtle difference:
Responsibility is task-focused. The doing.
Accountability is results-focused. The outcome.
As individuals on a team, we have certain responsibilities. Our teammates rely on us to produce work. Accountability is about what happens when all the pieces are put together and produce results.
Here’s where it gets tricky.
In the project model, every discipline in the team delivers its part in the chain of events to create a feature requested by a stakeholder. The accountability is outside the team.
In the product model, the game’s different. The team owns and collaborates toward an outcome. They feel ownership. They test, learn, and measure to reach a goal.
Take a team focused on improving the checkout flow of an ecommerce experience. Their outcome is to increase the conversion rate.
The product manager, though, is accountable for that conversion rate going up.
Wait.
The product manager is accountable? Shouldn’t the whole team feel ownership of the outcome?
Yes. That’s the whole point, and also a problem.
Feeling ownership of an outcome and being accountable for it are two different things and both can be true at the same time. The whole team can feel the outcome is theirs to win, while one person still has the accountability for it.
Let’s use an analogy.
Think of a football coach. The coach is accountable for winning matches. They get sacked after a long losing streak. But every player on the pitch needs to feel like it’s their game to win, not just the coach’s.
So the question still remains: how do you foster that kind of culture, within the team and across the entire organization?
How to handle the tension
You’re developing a new type of culture, a culture that values teamwork more than individual responsibility. But like I mentioned, there’s tension in between, and there’s a significant risk that things fall between the cracks, leading to confusion, stress and politics.
The key question is: what’s the most straightforward action you can take to bring the tension to light?
As the Finnish saying goes: you put the cat on the table (nostaa kissa pöydälle).
You talk about it.
Spark a debate. Surface questions such as: What do we own? What’s my responsibility? And who’s accountable?
What’s certain: the answers won’t be comfortable.
What will emerge is dissonance, hidden assumptions about who does what, micro-tensions that have been quietly building for months.
But this is exactly what it’s about.
Think of the coach who never talks about roles and responsibilities with the players. What will happen? Most likely a team that falls apart. On the other hand, the coach who’s transparent and fosters debate on who does what builds a team that plays together and wins together.
So that’s the fundament: bring the tension to light by discussion.
But let’s make it even more concrete in terms of what you can do to tackle this in team and leadership contexts.
For teams
Facilitate a role expectation mapping workshop, inspired by Yassal Sundman. It’s a simple facilitated discussion to surface what each person believes to be the responsibilities of every role in the team, and what you own as a team.
Here’s how it works:
First, define what you own as a team: What’s your product? What value do you create for customers or users?
Secondly, define how you measure success as a team: what metric(s) do you use to gauge whether you’re creating value or not.
Thirdly, draw boxes for each role in the team, for instance product designer, engineer, product manager etc, and a box for “all”.
Now ask the question to the room: what do you believe these roles are responsible for? Ask participants to write their assumptions. After, ask each role to review the notes, accept the responsibility, or move it to “Discuss” or “All”.
Lastly, bring to light the classic Venn diagram of the three perspectives of a product team: user, business, technology.
Usability: the responsibility of the designer
Feasibility: the responsibility of the tech lead
Value: the team owns, the product manager is accountable
Viability: the product manager’s responsibility
This visual might spark another healthy debate to adjust the responsibilities.
To close the workshop, assign one person to digitize the results so you can refer back to the mapping in future team contexts.
For leaders
At the leadership level, run a similar workshop but focus on leadership roles. Bring to light the elephants (or cats) in the room of what responsibilities are falling between the cracks. Another powerful question to ask by the end of the session is: “How could we further incentivize teams to own outcomes?”
If the whole working environment is set up to reward individual performance over team performance, you need to leave no stone unturned, from how you set salaries, to how you promote, to how you hire. That topic might be too much to chew on in one workshop, but the idea is that you trigger a bigger discussion across leadership.
Conclusion
Project model organizations value individual work and individual responsibility. Product model organizations value collaboration and a shared sense of ownership to reach the goal. When moving to the product model, there’s great tension between these two worlds, since the whole environment has been set up to value the individual rather than the team. In the product model you still need to do your part as an individual contributor, but you also need to foster a culture where you have a shared sense of ownership as a team.
To bring the tension to light, spark a discussion about who’s responsible, what you own, and how you measure success. That discussion will spark another one, and then another, ultimately leading you on a path to value teamwork rather than just individual effort.
Thank you Martin Jakobsen for the inspiration.