Agile community, we need to talk.

I love a good hot take, I do. And I absolutely believe that we are allowed to interrogate our ceremonies, roles, processes, etc., for value, as a way to improve the way that we work. If something feels unnecessary, we should be allowed to at least discuss dropping it. In fact, dropping a part of our process or eliminating a specific role can swiftly reveal what its value is, and help us make better use of it going forward (you don’t know what you’ve got ’til it’s gone and all that).

To that end, this post is not going to be a fiery defense of the PO role, as much as I may feel it deserves one. If you’re not getting value out of having a Product Owner on your team, experiment. Diffuse those responsibilities among the Scrum team, or drop them altogether. Let another team borrow your PO, send them on vacation, or sit them down in front of Visual Studio and tell them to make themselves useful.

I don’t care if you follow the “rules.” I don’t care if what you’re doing matches the Scrum Guide or not.

I do care if you go on the internet and tell lies.

I keep seeing blog posts and podcast episodes that seem to declare the Product Owner role a thing of the past. I say “seem” because the actual content of these galaxy brain think pieces is a lot less controversial than their headlines imply, and the problems they tend to identify are not problems with having a PO on the team. Ergo, clickbait.

What’s In A Name?

I’m trying to do a thing with this blog where I lump all the similar product roles, with all their different titles, under the term “product nerd,” because I think the topics I’ve written about and the ones I have in the drafts all apply pretty broadly. This time, I’m specifying “Product Owner” because it is this title in particular that modern philosophers seem to have a vendetta against.

And I’ll give you that the title is an odd one. Product Owner. I wore it for two and a half years, but whenever friends or family would ask what I did for work, I’d either immediately attach the disclaimer that I didn’t actually “own” anything, or skip straight past the title and explain that I did “software stuff… not programming.” But my title is Product Manager now, and that’s not much clearer, since people who don’t already know what it means tend to assume I’m somebody’s boss, which isn’t the case.

These anti-PO warriors seem to get stuck in that same spot: Right at the title. “Having one person own the product is bad,” they reason. “It should be a team effort.”

And then, crucially, they follow with something along the lines of, “Of course you still need a person who knows the product side of things to represent the interests of the stakeholders and be the person ultimately accountable for prioritization.” Maybe they call them the “product person” instead.

There’s two misunderstandings here:

1. A weirdly narrow definition of “owner.”
2. The troubling idea that Product Owners normally operate in a vacuum and do not involve the rest of the team in discussions of priority or the creation of backlog items. (What are story mappings and refinements for then, I wonder?)

By this logic, “Agile Coach” is kind of a pointless role, isn’t it? “Coach” is a sports thing. I think instead of having that guy with the whistle around his neck who keeps telling people to run laps, we need someone to be an organization’s Agile expert, who provides feedback and guidance to leadership and helps drive process improvements across teams. And I think we should call the role “Agile person” instead.

Like, pal, if your Agile Coach is measuring sprints in yardage, that’s not a problem with the “Agile Coach” role. Similarly, if you have an organization or even a PO who is taking the word “owner” to mean “person who makes decisions alone,” your issue is an incomplete understanding of the role and its purpose, not the fact that Product Owners exist.

So when these would-be visionaries loudly declare it’s time to say goodbye to the Product Owner role, what they actually mean is that they want to rename it. While they’re renaming things, maybe they should rename that Medium dot com article they’re about to publish. Fewer people will click on it, but that’s probably a feature and not a bug.

Strawmen Make For Bad Product Owners

This strawman who doesn’t talk to his teammates except to hand out work, who prioritizes the backlog according to his mood and without input from others, and who holds back the rest of the team from engaging with customers, is easy to blame for various problems your organization might be facing. Although he may look like a PO from some distance away, if we look closer we see that this is a misrepresentation of the role. The reality is that a successful Product Owner does include the rest of the team in prioritization discussions, even if they are the person who is ultimately responsible for making that call. A successful Product Owner enables and encourages the rest of the team to think in terms of solving customer problems.

If we don’t interrogate what we’re reading (or listening to or whatever) for internal validity, we may get tricked into thinking we agree with a headline like “Product Owners are Useless” because the article attached to it was actually about how important good communication is, which seems like a no-brainer. But this is a false dilemma—you don’t have to chose between having a Product Owner and having good communication.

Un-Callout Post

I struggled when writing this post with whether to name the specific pieces I’m responding to (because there are specific pieces I’m responding to, and paraphrasing, and parodying here). I’ve decided not to, partially because my intent really is not to start any fights. More than that, though, I think naming the specific instances I’ve seen of this problem would artificially constrain the discussion to those instances. I highly doubt the ones I’ve seen are the only ones that exist, and I expect that more will be published in the future, whether they’re about Product Owners, or Scrum Masters, or Agile itself.

I don’t mean to say that every article with a spicy title is definitely bogus, or that you can’t disagree with something unless it’s fallacious. (It’s not and you can, respectively.)

The bottom line is that we should engage critically with what we read, or watch, or listen to. I think we’re good at spotting clickbait when it pops up in places we expect it: YouTube videos with excessive question marks in the title, gossip zines that read too much into celebrity Instagram posts, “life hacks” that aren’t useful at all… but when a headline like “15 Unbelievable Reasons You Should Get Rid of Your Product Owners (The Last One is Crazy!!)” or, more realistically, “Agile is Dead” pops up on our LinkedIn feed or #we-love-scrum Slack channel, we do well to recognize the sensationalism in the title and inspect the content for whether it actually supports that claim.

And if it doesn’t, maybe don’t hit the share button.