This is a transcript of episode 241 of the Troubleshooting Agile podcast with Jeffrey Fredrick and Douglas Squirrel.
Responding to a listener’s question, Jeffrey and Squirrel reflect on the difference between a product owner and a process owner, and how IT projects differ from building products for external users. Unsurprisingly, methods for delivering value and saying no feature prominently!
Show links:
Listen to the episode on SoundCloud or Apple Podcasts.
Introduction
Listen to this section at 00:11
Squirrel: Welcome back to Troubleshooting Agile. Hi there, Jeffrey.
Jeffrey: Hi, Squirrel. This week we have a letter from a listener.
Squirrel: My favorite!
Jeffrey: I don’t know if this is your favorite listener, but it’s great to have emails from people asking questions. This one’s from Simon-
Squirrel: He’s one of my favorites for sure. He knows it, he writes us a lot and with lots of good questions.
Jeffrey: So Simon wrote us:
One aspect of Agile that I feel deserves closer attention is the role of product owner. In the case of sellable software, the concept of product is clear. But for internal business applications, this just leads to a baffled look on nearly all business user faces. I feel the PO in an internal systems role is in reality much more of a process owner, working on the process—both people and machine—that deliver a business service of some kind. And as such, I think there are some parallels with the sold software PO role, but there are also some differences. No one wants to use an internal or customer facing IT System per se. They’re using them to achieve some business outcomes.
Squirrel: Well, I can certainly relate to the baffled look because as usual, I have a client story. So let me tell a story and then let’s see how we can apply Simon’s model of product versus process owner to it. Is that all right with you?
Jeffrey: Yeah, absolutely. Love stories, they’re my favorite.
Locked Gears
Listen to this section at 02:05
Squirrel: I figured you might like them. I hope listeners do, too. So this client had an old, old system that they wanted to replace and had wanted to replace for a while, but they were having real trouble actually replacing it. I went in to investigate. I found that they match pretty closely this situation that Simon describes. They have a website and people can order stuff and so on, but that’s a fairly small piece of the software that they’re replacing. What the software mainly does is coordinate a whole bunch of machines, and you have to put the right inputs into the machines to fill the right orders and then make sure you deliver them to the right place and you have to utilize the machines well. So if you set up a machine for A then you want to leave it set up to do B if B is like A, but not if it’s going to be C on Thursday, and if the moon is full you do something completely different. One of those beautiful systems that I imagine a lot of our listeners have worked with or know about or have suffered, and the old system did things badly. The new system was going to do things much better. Why did they have so much trouble getting this done? Well, it turned out that they had an awful lot of process owners. There was a person who owned the process for this type of machine, that type of machine, customer service who created the orders but then had to edit the orders to make sure that they match the requirements of the machines, and all kinds of other things. There were plenty of people who owned those processes. The problem was that no one was making a decision about which one we should do first. So the main action I took was to appoint two people. I called them product owners, I think you could have called them process owners. I don’t care. But they were the veto mechanism. They were two different people from two different parts of the business who between them knew pretty much how everything worked. They went through and found 116 things that the new system didn’t do that they actually needed, fished up from the thousands of other requests that had come from all these different process owners. They vetoed the rest. They just kept saying no, and I trained them how to say no really well, really effectively, and politely but helpfully. After about three months of saying no, we got 116 things done. We went live last week. It was very successful. That’s my story of taking a situation with many people that I think you could easily call process owners and replacing them with some dictators. Now, I don’t know if you want to call them product owners or process owners, but that worked pretty well. What do you think about Simon’s model applied to that story?
Jeffrey: I like the story. The thing that struck me with that story and in Simon’s model is I don’t actually see the roles as that different. Particularly because the last thing that Simon said: no one wants to use an internal customer facing system per se, they’re using them to achieve some business outcomes. I tell this to product owners all the time, “no one wants to use your software, they have something else they’re trying to get done. Your software is how they’re hoping to do it, but if you could get it done without your software, they’d be happier.” That’s sort of getting people in the mindset that you’re trying to get people to business outcomes. The people that you appointed in this role, Squirrel, I assume that was the basis of their vetoes, right? They’re like, “there’s business outcomes we’re trying to achieve.”
Squirrel: One of which was “get rid of this old, old thing.”
Jeffrey: That’s right. So that’s sort of getting the way. I think that view is what’s behind bringing more product mentality into the IT world.
What’s a Business Outcome?
Listen to this section at 05:56
Squirrel: Let me stop you for a second, Jeffrey. There’s something I don’t want to let go there because you’re describing business outcomes, and there are some of our listeners who work in a really retail model. I bet there are some listeners out there who are making games, I know there’s at least one listener who works at Facebook, and I think that they make stuff that does not necessarily lead to a business outcome. It does for their advertisers or in the case of a game, it might lead to a good result for the game publisher. But the user of the software in either case is trying to see pictures of cats or enjoy shooting aliens. But, I would claim that user still isn’t sitting down and saying “I can’t wait to use some software.” The user is saying, “Man, I wish there were more pictures of cats. Where could I find pictures of cats?” And it happens to be that their phone is a really nice place to do that. But what they’re not sitting down to do is saying “I want to use software.” They’re saying, “Where are the cats?”
Jeffrey: That’s right. “Where’s my chess match.” Things they are trying to get to. I completely agree. We might more generically say “the delivery of value,” the value is not always business outcomes, but there’s a delivery of value and the product owners are the people who take the role of end-to-end ensuring there is that delivery of value. We previously interviewed Mike Kersten, the author of Project to Product on our podcast, he’s describing that trend I think. My personal experience is when I first read Simon’s message it reminded me of the first business book I ever read in my whole life. I think I made a references on the show before, but I was in high school and I was reading my father’s bookshelf and I came across a book called Re-engineering the Corporation, and it must have been a long summer, but I decided this would be a great thing to read, and I read it.
Squirrel: You can tell how Jeffrey became Jeffrey because he read that kind of book as a kid for fun.
Jeffrey: Yeah. So I read this book and it talked about understanding the end-to-end process, all the mini processes involved in a corporation and having someone who takes that bigger view, that overall view end-to-end. It was talking about real world examples, like going to the DMV and all the different people you might go through in trying to renew your license or something.
Squirrel: DMV is “Department of Motor Vehicles” for people who haven’t suffered through that particular American institution. We have similar things in Britain.
Jeffrey: That’s right. You can tell from the way that Squirrel described it, it’s not known as a smooth, client-focused operation in most cases. But this book was a manifesto for business revolution to the effect that you can make dramatic increases in value and client satisfaction by rethinking what you’re doing and that you have that overall process owner to let you restructure the way you’re doing things, rethink the whole process, and therefore re-engineer the corporation around your business processes. It really matched in my mind when Simon is talking about having a process owner internally, I’m like, “Yeah, as long as it’s the person owning the process end-to-end, then yes.” The problem is that very often these process owners are owning a small piece, which I think is what you were describing. Then instead of getting clarity, you get local optimizations that work against the overall delivery of value.
Owning the Process vs Owning a Step
Listen to this section at 09:52
Squirrel: That’s precisely what had been happening for a long time to my client, and they were also competing for resources. There was no one to make the decision overall for the whole business about what would help them deliver more value. In many cases rather than do the requested improvements to one person’s machine or another, that would be “turn off both machines and buy a better one.” That would be the sort of decision that you would want this person to make. I would claim that works also in the retail world. You see exactly the same kind of mistake happen that there is somebody who’s in charge of the front end team and they will just create amazing designs for what gets shown to users or they’ll be in charge of a piece of the overall value. And that’s where you get into a lot of trouble with local optimizations and competition for resources. That will happen with a retail environment. I’ve seen it over and over again just as much as wholesale business to business kind of situations like Simon’s thinking of.
Jeffrey: I completely agree. Like you said originally, I don’t really care about the names, but the key thing is that end-to-end view and having the mindset of someone who’s going to go in and not just accept the status quo, but be looking to say, “how can we make this better?”
Squirrel: Not only mindset, but authority. Because what was crucial in my client’s case was giving these people the authority backed by the CEO, who sometimes had to step in and say, “forget it. Turn off machines. See, we don’t need it anymore.” That was much more effective than the endless competition and debate among the many separate process owners.
Jeffrey: That’s a really good point, because no matter what title you give people, eventually you’re going to get to the point where something’s going to have to be solved through escalation if you’re really making significant changes the way things are done internally. Your goal here is to get focus and alignment. Ultimately in most organizations that is going to require when there’s some friction, some process to escalate, to say, “yes, in fact, this is how we make the decision and this is the decision, so let’s move ahead.”
Squirrel: Indeed. So I think the conclusion is, Simon, as sometimes happens we disagree with you. We don’t think there’s a fundamental distinction between product owner and process owner. If see the kind of situation that Simon’s describing the symptom of quite clearly, our recommendation is find someone. It doesn’t have to be a senior person. The two people I described who did this role were relatively junior. Not super experienced, had not got certifications or degrees or anything else in doing this. What they had was a degree in the school of hard knocks, banging their heads against these machines in the factory and the software that they had been working with. So that’s the kind of person that you need, and then you need to imbue them with the right authority. So if you’re interested in addressing this problem, whether you’re Simon or any of our other listeners, that’s what we think you might want to try. Thanks, Jeffrey.
Jeffrey: Thanks, Squirrel.