Your Product Owner Is An Imaginary Friend (And That’s Okay)
The Product Owner always seemed like the perfect scam in the Agile community. The basic idea was to take all the things that seemed boring and tough, and make one guy do them. Prioritize stories? Not us, it’s the Product Owner. Explain how stuff works? That Product Owner guy again. Coordinate with users or the rest of the organization? What do we look like, communicators? We’re here to sling code, dang it. The Product Owner can handle all of the touchy-feely suit stuff.
It’s not that there shouldn’t be a product owner; it’s that his job is wrapped in fuzz. It’s like there’s some sort of Heisenberg’s Uncertainty Principle associated with the role. The more we pin down exactly what the role means, the less likely we are to find somebody who can actually do the job. To fix this problem, we just ignore it. So sure, we have classes on who the Product Owner is and what he does, but the classes are all about the mechanics of the job. How to write a story, how to read a burn-down, how to have a conversation (!) with developers. Who does what on a Scrum team. Heck, you can even get certified at this stuff.
But the real crux of the job, being a businessperson? Somebody able to make decisions and be accountable? No training for that. Dude, thems just the breaks. We’re here to help you with post-its and line charts, not making value decisions.
Over the years, I’ve caught a lot of flak from developers. Whenever people ask me about why Agile or Scrum ideas don’t seem to work, I always say the same thing “You know, most of this grew out of typical small programming teams. The model doesn’t work exactly in every situation. It’s an ideal. Let’s try and learn it, then we can adapt as needed.”
Fortunately, this has gotten me off the hook most times. But the more I think about the Product Owner role, the more I’m concerned that the model doesn’t just exactly match with reality. The model exists in its own completely separate reality. Let’s take a look why.
You basically have two decisions to make about your team. First, is the team in a startup or writing commercial code? Second, are you in a small or large organization? Let’s take each of the four cases.
If you’re in a startup in a really small organization, having a Product Owner is easy, right? He’s just “The Decider”. Pick somebody out and let them make choices.
The problem is this: decisions need to be made on economic value, and most startups will never generate economic value. So there is no value. In fact, the entire focus of a small startup is not cranking out code; it’s creating some economic engine that can pay the bills. So there is no user. There is no business. There is no guarantee that you have anything more than a hobby. Worse yet, anybody that gets between you and somebody who might have money is an additional risk. Get rid of him. Product Owners don’t belong in small startups.
If you’re working as a startup as part of some large effort, then you could have a PO, right? He can tell you what to do and then report back to the VCs or whoever else is sponsoring your startup. But as we said before, these people are not your customer, they’re just the guys paying the bills for a while. If you can’t create an economic engine you don’t have a job, no matter how many stories you complete or how much funding you get. So what’s the PO in that case? A proxy for investors? Get rid of him.
How about a commercial product for a small company? Say you’ve got an office with 50 people in it doing some kind of work. You’re part of a team of 4 or 5 brought in to write some kind of code. Surely that is a case for a PO.
And yep, out of all of these, this scenario, where you’re in a small team helping out a small company to get something done, that a PO makes the most sense. But even then, you have to ask yourself: what is the PO really doing? Can’t the team just talk to the business users and figure out what they want, then deliver it? Isn’t the PO role here much more of a “we don’t trust each other, so we’ll create a role to blame if things go south” than anything else? You’re in a small company. Everybody is close-by. Just what does the PO bring to the table that you don’t already have? Couldn’t the team just send out an email saying “Here’s the stuff we’re doing, and here’s the order we’re doing it in” and be done with it? (Along with demos, of course) If you can talk to your users, get rid of him.
Finally, there’s the case of working in a commercial software team working in a large corporation. Many times large organizations will “re-purpose” BAs to play the role of Product Owner. The job roles don’t match up, though, because understanding a business problem and making business decisions are two different things. And aside from the team, who does the PO talk to, anyway? In this case, the Product Owner has to find out and communicate back to hundreds, maybe thousands of people, just what the team is going to be doing. This is truly a Brobdingnagian task. It gets worse, though, because in most cases the team needs to make decisions based on a technical understanding and comparison of the changes to be made that nobody else in the organization is capable of making. News alert: it’s not unusual at all for Agile teams to do business decision support work, and that’s a good sign that they’re actually providing real value (instead of just cranking out value items on a little conveyor belt called the backlog)
And I’m not even getting into all the problems we have with product owners no matter the situation. Many times more than one person wants to be the PO. Sometimes there’s a tension between technical value and business value — and no easy way to decide which is which. The best Product Owners are valued by the business, which means they should be busy doing other stuff, not hanging out in a room talking to the team. Delivering technology solutions is just one part of the job of understanding and managing a working business model. (I would argue a small part)
I spoke to some lean experts last year on the blog. Towards the end of the interview they were pretty clear: the role of Product Owner is an obstacle and bottleneck in a truly lean organization. It’s somebody designed to be between the team and the people getting value from the team’s work. Get rid of him.
But I’m not ready to go that far. I’m not saying you shouldn’t have a Product Owner. Like the title says, it’s fine if the role doesn’t exactly work out. I think it’s still important to have somebody who is clearly responsible for the order and quality of the value the team is delivering to the organization. Just don’t expect it to work like it does in the book. It never does
November 7, 2013