Certified Product Owner - interview with Mike Cohn

March 19, 2008 by Artem Marchenko

Last week while taking the Certified Scrum Product Owner course in Oslo I had a pleasure to have an interview with our trainer Mike Cohn, an author of Agile Estimating and Planning and User Stories Applied. Mike shared his point of view on the value of yet another certified Scrum Alliance course and provided advices for those going to become Scrum Product Owners.

Artem: Certified Scrum Product Owner class is brand new Scrum Alliance offering. What's different from the Certified ScrumMaster class and who needs to go to the Product Owner class?

Mike: The Certified Scrum Product Owner class is for anybody who seems to be more in the business side of a project. Product Owners, analysts, people who might be working on what XP would call a customer team - those are the target audiences for the Product Owner class. I see the biggest differences in that ScrumMaster class is really oriented at both ScrumMasters and teams. The Product Owner class is aimed more at the customer side of things, meaning less focus on solving team problems, overcoming impediments, and doing those kinds of things. In the Product Owner classes I teach a lot the focus is on user stories, managing the product backlog, using the backlog as a scoping tool. It's about prioritization, optimizing value delivery, things like that.

Artem: Why would anybody want to go to the Certified Scrum Product Owner class?

Mike: I hope that somebody would want to go to the Product Owner class so that they could learn how to those things. There are a lot of Scrum teams these days that are doing well, but just being good at Scrum doesn't mean you are headed at the right target. So a Product Owner class is going to help somebody learn how to aim his or her team at the right goal. If you are going fast but not at the right goal, you are not going to get where you want to be.

Artem: What is it that is "certified" about this class? What the certification is about? Am I going to be the better product owner after this class?

Mike: Well, I hope you'll be a better product owner from this class, but I think that's independent of whether it's called "certified" or not. There are a lot of people who like the word "certified", want to use it as a distinguisher. I think all that the certification really means is that the class is the Certified Scrum Product Owner class. You know that it's being taught by a Scrum Trainer who has been approved by the Scrum Alliance. I think that's the main part of the certification. At least you know you are getting quality training. I don't know that if somebody goes to a class but barely pays attention (which can be hard for the trainer to know) is going to be a whole lot better. But somebody who engages in the class and participates in exercises and discussion will be a better product owner.

Artem: Do you mean that the word "certified" is actually more about the quality of the class, than about the skills of an alumni?

Mike: Yes, right now I think it's more about the quality of the class, than about "you have attended a class and I as a trainer certify you as being a wonderful product owner". I can't do that in a two-day class. All I can do is to try making somebody better.

Artem: About your personal product ownership experience. What's the biggest product you product owned or helped to product own?

Mike: The biggest one was a health care application for which I was the product owner, did essentially the entire product owner responsibility for that. That was probably the largest one.

Artem: Something life critical?

Mike: Oh, it wasn't life critical. Well, sometimes. It was a triaging application - people would call and speak to nurses and get medical advice. It wasn't something like running an ambulance or heart monitor, or something like that - it was about giving a critical advice for people.

Artem: How big was it? Twenty people, one year?

Mike: That one grew to, I think, about fifty people at the most on that project. I was involved for six years but it continued after I moved on.

Artem: What was the most difficult product to product own an why?

Mike: The most difficult product that I was a product owner for was one in a bioinformatics domain, where we had a chief scientist, but he couldn't really speak to developers. So I had to take the requirements from him and act essentially as the product owner. He in all senses should have been the product owner, but he was in another city and couldn't relate to the developers, so I had to kind of fill that role. It was very difficult - I am not sure how well I did it, because of the challenges of the remoteness of the chief scientist and the domain. It was just incredibly complicated - I am not a scientist, so working in a bioinformatics, where I didn't understand most of the vocabulary even, was very difficult to me.

Artem: You were telling couple of times that whenever there are a lot of interests in the organization, a product owner should better be a single person and that a team should concentrate on a single product, but what will you do if team just has to support several projects with sudden bursts of maintenance needs for the previously silent projects? Do you think that a common backlog and single product owner still make a lot of sense if the team just has to support several projects?

Mike: A team can support multiple projects, but they really need to be getting their guidance from one person. They can't go to three people and say "what do you want us to work on next?" There has to be one person who is setting the relative priorities of those three products. So I can be a team member and work on a number of different things as long as somebody is setting those priorities for me and telling me "this one is the most important. If you have time, work on this other one." Some one person has to do that. It is unfair to put a team in a position of having to balance its projects against each other.

Artem: In my own history I had a situation once, when there was a single team, single product owner, but then they had to support several projects. They tried putting everything into a single backlog, but then it became a huge mess, when items from really different projects came into a single list and then they just had to split it into several smaller backlogs that were dynamically assembled into a single list by the moment of sprint planning.

Mike: There has to be a one product backlog. I don't really care about the mechanism as long as there is one person who can adjust the priorities for the team whatever mechanism they use for it. I've seen that done with one backlog, I've seen that done with multiple. I like falling back into kind of programing concept of Model-View-Controller. I'd like to have one backlog, but I'd like to have multiple views into that backlog. Sometimes you need to see it as a one backlog, other time it's too confusing to see that - then I'd like to see just my part of the backlog.

Artem: What are your top three tips for the new product owners?

Mike: A product owner has to prioritize. I want product owners to take it very seriously, but I want them to listen to other opinions. I want them to talk to architects who may have opinions about technical risk and programmers about why it's easier or better to do something. So I would tell product owners to:
1. Take prioritization very seriously
2. Make sure you don't do it on your own. It's not all just business value. There are other things: technical risk, the amount and significance or what we'll learn by doing a feature and so on.
3. Not to disengage from the process. It's very frustrating for the team to be trying to go as fast as possible and not have access to their product owner.

Artem: Where the new product owners should start?

Mike: I think product owners should start by figuring out a backlog for the product. That's normally where I would start. I like user stories, so I would start up by writing the user stories that describe the product. Typically I would try getting my own head around the product. I'd involve the team, we'd get our heads with what the product is going to be and then very likely do something like creating a vision box describing what we think this product is going to be. Writing an elevator statement or designing a vision box is what that helps us glue the vision in everybody's heads. Then I would write stories.

Permalink