Team ownership has become one of the hottest buzzwords in the product world.
It seems like every product thought leader and product management book says things like “let the team own the problem,” “ownership is the key, ” or “focus on building team ownership.”
I get it — the premise is truly captivating. And yet, to a big extent, it’s a myth.
In this article, we’ll unpack the fundamental problem of shared team ownership and what you might actually achieve instead.
If it’s everyone’s, it’s no one’s. And you can’t blame the team for that.
Let’s face it: if there is something you want the team to own, and say you have a 10-person team, what’s the actual incentive and motivation for any individual to truly care about it?
There’s none.
Initially, this flustered me, as it does most inexperienced product managers.
I was doing all I could to support shared team ownership; I tried coaching, giving lessons, sharing inspiring TED Talks, and even having frequent one-on-ones on the topic.
Yet it never stuck.
I was quietly dreaming about the “perfect team.” A team that is mature enough to start collectively on its own problems and drive initiatives. I subconsciously thought it was a people problem — that these people simply weren’t mature enough in the industry to approach it “the right way.”
But then the team’s delivery manager opened my eyes. It started with this simple, yet revealing phrase:
“If it’s everyone’s, it’s no one’s.”
It’s not about finding a team of A-players with a high agency over customer problems, initiatives at hand, or team challenges. It’s an accountability problem. See, we, as product managers, have a wide range of accountabilities when it comes to delivering great products. As much as we might want to fight the system and drive an organizational culture change, the fact is each professional in the team is ultimately judged by their individual accountabilities.
Let’s take an example of your QA engineer. Imagine they have a performance review talk with their domain manager.
Which statement do you think will be more impactful on their career progression?
Whether we like it or not, the first statement would probably lead to a raise, while the latter might put this QA on a performance improvement plan.
At the end of the day, it’s better to take “shared consequences” as a team for not delivering a team-owned initiative than to underperform in the area you are strictly accountable for.
If team ownership doesn’t exist, it doesn’t mean that you must be a one-person army constantly worrying about timelines, problem resolution, each initiative’s progress, next retrospective effectiveness, and so on.
But at the same time, you can’t just “give it to the team” and forget about it just like many product gurus tell you to.
When you need your team to handle something, you need to leave product meetings knowing which individuals will be accountable for driving the results.
I don’t mean a person that’ll solve the problem alone. I mean a designated person whose responsibility will be to ask for help, drive other team members, and escalate if something goes off track.
One person who’ll have mental ownership over a particular topic. Something that’s simply impossible to build collectively since, as I already mentioned twice, if it’s everyone’s, it’s no one’s.
Work with domain managers and team leads to include this in performance reviews. Not to use it as a threat, but to incentivize people to contribute to initiatives outside of their domain work. And if they deliver, do everything you can to ensure these people are praised and rewarded for it.
I’ve been exploring various ways and approaches to build individual accountabilities in recent months.
I didn’t have a choice.
There was simply too much on my plate to have mental ownership over everything and just leaving this with the team never worked.
Here are three approaches that worked best so far:
Repetitive things need to be taken care of every single sprint. Examples include:
I’ve seen many product managers who try to do it all themselves, often resulting in too little time for actual product work and quick burnout.
The solution? Sprint roles!
We’ve mapped every recurring thing that needs to be taken care of and every sprint after the review, we collectively discuss and assign specific accountabilities to specific people.
There’s a set of things that need to be taken care of for every new initiative, such as
Whenever we start a new initiative, we designate a feature owner who will be accountable for all initiative-related activities.
Again, it doesn’t mean it’s a one-man army doing everything. The beauty of having rotating feature owners for different initiatives is that team members help each other because they know they’ll be feature owners at some point and will need the support themselves.
It incentivizes not only the feature owner to think about the initiative and oversee it but also incentivizes other team members to support the feature owner with everything.
Problem owners work on the same principles as feature owners. What’s different is the nature of the owned item.
Say there’s a repetitive problem within the team. For example, you constantly struggle to cooperate with the localization team, often leading to delayed translations and releases.
The feature owner is the person who takes mental ownership of the topic. They proactively work towards solving the issue, engage other people, communicate cross-team, and also keep the product manager accountable for their part.
Yes, problem owners and feature owners often ping me if I slack off. I still have my part to do in these things, but I don’t have to “mentally own” everything. I don’t have this feeling of stress “if we get thing X done on time” because I know there’s someone else already worrying about it.
I’m pretty sure one of the main reasons why burnouts are so common in the product management world is that PMs have to own numerous initiatives, problems, and processes mentally.
It’s practically impossible.
On the other hand, delegating this work to a team also doesn’t work.
Let me be clear. The team should own initiatives, customer problems, processes, and challenges. But, it only works if a specific team member is accountable for driving results.
Don’t leave problems “with the team.” Instead, make sure each issue is taken care of by a specific person who’s aware it’s their job to take care of it.
It’s not that hard, just ask the question, “who is going to take ownership of this one?” If it’s quiet, just wait. It might take ten seconds or two minutes, but someone will pick it up.
Over time, the team will be more courageous to pick up topics. The team can effectively own problems, initiatives, and challenges. But shared ownership doesn’t work.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Subscriber acquisition cost (SAC) refers to the total expense incurred by the business to acquire a new customer or subscriber.
Although we did a good job moving people to the checkout page, we had problems converting checkout visitors to paying customers.
What exactly is founder mode, and is it really better than manager mode? Let’s discuss what this phenomenon could mean for the PM world.
Chaos engineering is the practice of deliberately introducing failures into a system to test its resilience and identify hidden weaknesses.
Learn more →
