Introducing the Professional Product Owner

About this podcast episode

Successful product delivery starts with Evidence-Based Management

Today, Ralph Jocham will introduce the Product Owner role in Scrum teams. Ralph shares the importance of delivering products based on Vision, Value, and Validation. Ralph and Bill also compare project and product-based delivery for complex work.

In this podcast, you will learn the following:

✅ The role of the Product Owner

✅ The importance of the Product Owner’s focus on value

✅ A primer on Evidence-based Management (EBM)

✅ How to scale the Product Owner role

✅ How leaders can support the Product Owner role

Transcript

(transcripts are auto-generated, so please excuse the brevity)

Introduction

Bill Raymond: Hi, and welcome to the podcast. Today, I’m joined by Ralph Jocham, speaker, author, and change agent. Hi Ralph, how are you today?

Ralph Jocham: I’m good. Thank you. How are you doing?

Bill Raymond: I’m doing great, thank you. I’m looking forward to the conversation. We’re going to be talking about Introducing the Professional Product Owner, but before we get started, can you share a little bit about yourself?

Ralph Jocham: Well, my background is originally I was trained as a programmer, started off about 25 years ago as that, and I came to agile through extreme programming, and then I later on discovered SCRUM in the context of that and that’s been my journey, which took me a little bit around the globe from Germany to the UK to the US, and now I’m living in Switzerland.

Ralph Jocham: And now thinking back about agile, those 20 years, I always have to think about the quote of Mahatma Gandhi, First they ignore you, then they’ll laugh at you, then they fight you, and then you win.

Ralph Jocham: And it’s really kind of the phases I saw agile going through. I’m now living in Bern, close to the Swiss Capital and even the Swiss Government, I work with them here and there and do something agile with them.

The Professional Product Owner, Leveraging SCRUM as a Competitive Advantage - The Book

Bill Raymond: You are the author of a book, The Professional Product Owner, Leveraging _SCRUM as a Competitive Advantage_. And that’s actually how we found out about you. It’s a great book and we’ll talk a little bit more about that, but I really appreciate the work that you’re doing for the community, too.

Ralph Jocham: Thanks. This book it’s been out there for two years, maybe even more. And I’m still getting here and there on email or someone on LinkedIn reaches out to me just saying, "Thank you for this book. It’s really helpful, it really is for me the reference manual for product owners or even product managers".

The purpose of having a product owner role

Bill Raymond: Let’s talk a little bit about the purpose of having a product owner role. I suppose we should probably define what the product owner is before we get started. And it’s a very specific role that’s typically defined fairly clearly, but I’d love to hear your perspective on what that role is.

Ralph Jocham: If you go into an organization to start to work for them, you always get assigned to a project. Projects have the tendency, they have a beginning, they have an end, they have a scope, and this is how much it will cost. And then we are kind of in this project management triangle scope, schedule and and budget.

Ralph Jocham: And the important thing here is that, as a person, you don’t purchase a project, you purchase a product. You go to Starbucks to get a coffee, the coffee is the product. Maybe you buy a car, it’s a product. You read the news, it’s all a product. You listen to the radio. Essentially, product is the connection to the customer, to the users, and it’s really about understanding what are the needs, what problem can we solve for our users. And if you do this well, you launch good products and well, you make revenue with that.

Bill Raymond: That’s a good starting point for us. So the idea here is that we’re going into less fully-scoped out work and a more iterative approach to designing our products. So as we talked about with the project-based work, usually there’d be a project manager that’s kind of doing that work and they’re leading the effort, but they’re not necessarily defining scope, they’re managing scope with a number of stakeholders.

The role of the Product Owner

Bill Raymond: They’re not necessarily saying, do this work, they’re getting the list of things that people say they can do and putting that into a project plan. But if we move into the agile world where we’re talking about a product owner, can you talk a little bit about what that role looks like?

Ralph Jocham: So essentially, just going back to this project, often an underlying problem is that we estimate the effort of a project without even knowing who is going to do the work. And that’s often when we then get in a time pressure and then we still have to rush it and the quality of the product reallyquickly degrades.

Ralph Jocham: So if you really take this user, what are the problems of users and how can we help that, and you bring in this product mindset, it’s really about how can we understand what they really need? And I always talk not about the role product owner, the accountability, I talk more about product ownership as an activity. Because for me, a really good product ownership is the right mindset in that field. As a product owner, you really would try to understand what is the problem for whom and how could we help those people solve that problem? And essentially, going through the sequence. Why are having those people these problems, who is it actually and how can we help them? The answer to that is the what. So we don’t start up with what people want or what we believe what they want, and then we put it into a project plan. It’s more like, we engage with the users and through this conversation, we discover really the underlying needs. And often the solution could be something totally different than what was originally anticipated.

Ralph Jocham: And through that, as you also mentioned, instead of having this lengthy plan where we plan everything in the beginning and then we analyze everything and then we design it, implement it, test it, release it, we turn this whole thing at by 90 degrees and we do a little bit every sprint. And that allows us to have something which works at the end. We have, we call it the increment in SCRUM, which we can show and we’ll potentially use and say, "This is what we have, we talked about this, this is how it would look like. Will this work for you?" And based on that feedback, we know, yes, we were right or we make adjustments, iterative and incremental.

Defining the incremets of work

Bill Raymond: Right. And so how do we define what those increments of work are? I’m guessing that the product owner plays a specific role in that.

Ralph Jocham: Well, the interesting thing is if you look into the SCRUM guide, there’s a sentence in there that states that essentially, the product backlog plays a really important role in that because everything we will be doing for the product is basically stated in the product backlog. All the work, the SCRUM team, or the SCRUM teams for a large product that are working on is coming out of this one product backlog.

Ralph Jocham: There’s the sentence in this SCRUM guide. The product owner may do the work or may delegate the work or delegate the responsibility but the product owner remains accountable. So essentially, you could do this as a product owner on your own, you could go out, talk to your stakeholders, talk to your users, do all of these things.

Ralph Jocham: Maybe you can also take some developers along, and just say, you know what, let’s go to this customer, let’s figure out really what they need. And by doing this, you would really kind of make the developers more engaged And especially, since often it’s understood that a developer is by first off the product, by definition a programmer, which isn’t true, a developer could be any skill we need to build the product.

Ralph Jocham: So what I usually like to have is while programmers for sure,business analysts are great, somebody who knows about testing yes, maybe UX and so on. So you might take a couple of those developers with you and go with them to a customer. You might even go so far and just say, hey guys, I found a new user. They have really good ideas and specific needs. Would you go and talk to them and find out what’s important? Then tell me about it.

Bill Raymond: So the role of the product owner is to communicate with the customer, either personally or with the team or with the right people, and they’re starting to get a handle on what the vision for the product is and get a sense of what the backlog is of work that needs to be done in order to meet that vision.

Bill Raymond: So how does that product owner sit back and say, Okay, we received all of these requests, I’ve been listening to customers and have figured out some of the important things that they need. They may not have maybe stated it the way the product owner has thought about it, but there’s some sort of a backlog now that has this work that needs to get done.

Identifying the right work to do

Bill Raymond: Is there some way that the product owner and the team need to look at this work? Because I can imagine if you’re doing iterations every, let’s just say every two weeks, these sprints that you referred to, I can imagine that the number of things that people want is always going to be much higher than what can be delivered.

Bill Raymond: So how does the product owner sort through all of that and identify the right work to do?

Ralph Jocham: For me, I think here also the good product ownership for product owner specifically, is really stakeholder management of which the users are one type. And **sure, I like to have everything and a little bit more. However, if you really go into this engagement and you just tell them, okay, because in classic project management, going back, you often categorize your requirements as must have, should have, could have, want to have, and usually everything tends to be must have. **

Ralph Jocham: But probably from all of the things which is a must have, there’s probably one which is a little bit more must than the other ones. And that’s what we should do first.

Ralph Jocham: Now as a product owner, you talk to your users here. From all the things we just talked about, what’s the most important one or what would help you the most?

Ralph Jocham: Well, everything. Oh yeah. But now you have to, you can only choose one. What would it be? Well, if you, well this one here. Well, I say, okay, fair enough. So how about we come back at the end of this sprint and we show that in the way we have understood it, implemented working for you. And then at the end of the sprint, they will see it and maybe they’ll tell you, Oh, that’s great.

Ralph Jocham: Or maybe they’ll tell you, Oh, well yeah, that’s kind of how I explained it, but not how I really wanted it. And then, well, it’s a good conversation starter. Okay, now how should it be? Let’s just look at that and point with your fingers on that and figure out. And that’s lots of learning.

Ralph Jocham: And that’s again, in contrast to the project mindset where you do the whole planning in the beginning when you have the least knowledge, we just say no, we get smarter as we work on it. Lessons learned, often after project, we have lessons learning. So whatever we have learned in this first sprint, we can leverage in the second sprint because we can have meaningful conversations with our users. We understand them better and I like to call this, cognitive alignment and the product owner and the whole SCRUM team, they get a good understanding, how are those people thinking? What’s important for them? And then we can much better address it for them.

Bill Raymond: It sounds like the customer is always in control, but does the product owner have some responsibility to rank these to a different level? I mean, we’ve all been here, right? Whether we are the customer of some product being developed and we really want this feature, or on the other side of the fence, you’re the product owner and you’re hearing all of this, we need this feature, we need this feature. And sure, I could understand asking people, okay, so what’s a top one or two that we can accomplish and working through that?

Bill Raymond: But sometimes what we learn is that the features that we really want aren’t necessarily the features that we get. I’ll actually use an example of this podcast right now.

Bill Raymond: Before we got started, before we recorded, you know, we’re using Macs, I have an iPhone and a Watch and all that, right? I went onto my computer to silence it. Well, I think I probably would’ve asked Apple to just give me a little silence option on my Mac, so that noise didn’t come out of it. But really, what I have now is this whole Focus Mode, _this Do not disturb mode._

Bill Raymond: And when I turned that ON, it not only prevents all these notifications from popping up and it turns OFF the sound, but does it on all my other devices too. That’s something that to me, probably I wouldn’t have ever thought of as a user, but the value there is so much higher.

Bill Raymond: So I’m curious if the product owner has to put some level of focus on that value, to measure the importance of these, and not just, if you will, be taking in a laundry list of requests from the customers. How does that interaction work?

Ralph Jocham: Okay. You are really addressing an important point here. It’s not really just going to the customers and there’s this nice quote of Henry Ford, If I would’ve asked people what they want, they would’ve answered faster horses.

Ralph Jocham: And the answer was something totally different. It was the car. In that regard, it’s really about bringing the right connection, asking the right questions.

Ralph Jocham: So how does it show? How does it manifest? Yeah. You just explain it well, I want to have a silent mode. And then maybe, and often it’s like it’s also a discovery process, because product development is not a mathematical equation which we solve, and there’s one answer. It’s a discovery process. And that’s ambiguous by design or by the way it is.

Ralph Jocham: So essentially, maybe somebody just said, well, now we have this Focus Mode on the Mac. That’s really nice. But you know what? My phone just rang, and that was kind of annoying.

Ralph Jocham: Huh?! I think I have an idea. How about you turn it ON to one of the Apple devices and all of the ones that have the same account, make it silence as well? And suddenly, you have a feature on a feature. And this is kind of why I think SCRUM is so powerful in my opinion, because it allows for this discovery process to actually happen.

Ralph Jocham: But the discovery process can only happen once you have a device in your hand you can play around with. You wouldn’t discover that if you read requirements or specifications or something like that. So this goes back to the agile manifesto, the working product over comprehensive documentation.

Bill Raymond: This makes sense and I appreciate that thought there, because it is one of those things where if you get a number of requirements, people can say, oh put this thing in the product, add this extra feature. But sometimes you need to think outside the box.

The three Vs

Bill Raymond: And I think that what you’re talking about here is a very important topic, and I think you cover this really well with what you refer to as the product management vacuum or the three Vs, which are Vision, Value, and Validation. Is that correct?

Ralph Jocham: That’s correct. And the way you can think about that, for me it’s like a little bit like, I like to call it the product management onion, where you have different layers. And at the top, usually companies that have a vision where they want to see themselves, which direction they, they want to move towards.

Ralph Jocham: And based on that, the next layer underneath would be, what would be the business strategy that derived from there? So that’s really important. And then at the two bottom tiers, you have solution and value discovery, and delivering validation. But you have two layers in between, which often, kind of the way I teach about it and talk about it in my trainings, is they’re empty.

Ralph Jocham: And usually, that’s where the project management comes in as a wrench saying, in here we’ve put our reports, our milestones, our chapters, charters, whatever we have.

Ralph Jocham: And this brings us back into the problem of following a project is more important than customer value. Because as a project manager, you do a good job if you deliver on time, on scope, and on budget. Whether you deliver the right thing, that’s not your problem anymore. Somebody else thought about that. But now as a product owner, you are the single wringable neck for this product, for delivering value to your user. And it also means you probably have some budget you can work with in any way you see fit the best.

Ralph Jocham: And the important thing here is that as a product owner, you should have really understood what is the thinking, what they want to achieve on the business side. This doesn’t mean you can tell them what to do, but you have at least a chance to ask questions. Because if you haven’t really understood what the business is trying to achieve, what are their goals, objectives, and other things, you can think about it and then you can come up with a product idea, product vision.

Ralph Jocham: **And otherwise you just get something put into your hands. But now you can really, through this conversation you would have, you just say, I think I have an idea handle on that. And once you have that, you can come up with a strategy for this product. **

Ralph Jocham: Now we have the two layers in the middle.

Ralph Jocham: So we have a company vision, business strategy, derived product vision, product strategy, value solution, discovery and delivery, and validation at the bottom. And this is how this product ownership really connects the strategy to the tactics.

Ralph Jocham: Because the problem is also is strategically, so many things are easy.

Ralph Jocham: When we had the high peak of Corona, I think everybody found somehow an answer on the kitchen table talking to some friends and neighbors. But how do you make people behave accordingly? All this goes back to this mental alignment is this that we all understand, this is why we do that. So as a product owner, you get this alignment with the business through having the conversation.

Ralph Jocham: Then you think about that, and then you have the same conversation with the developers out of your SCRUM team. And by doing that, you make them understand what you have understood by having talked to the business. And this is how you really can map out the value stream in a much more cohesive way without having so many handovers.

Ralph Jocham: So for me, the product owner is delivering representation of the value stream for the product.

Bill Raymond: That’s a really good way of thinking about it. And I guess one question I’d have is, so the product owner sets this vision and they’re defining the value of the work that’s being defined. They’re taking in ideas from the customer, maybe the team even has ideas, and all of that kind of gets fed into a product backlog.

Bill Raymond: And that product owner is responsible for delivering value. So there’s no one else to go and complain to, it’s them. And so they’re making sure that whatever they get into the product is going to be valuable to the customer, or it could be measured as valuable in some way. And the way you measure that is through the validation. Is that correct?

Ralph Jocham: That’s correct. I think there’s two things, what we measure. First of all is, if we really have our customers, the users coming to the sprint review and they give us a thumbs up, that’s great. But it’s still just a representative of maybe you have millions of users and you try to get a good sample of who represents your users and they give you a thumbs up, but it’s still not really in the market.

Ralph Jocham: So the other thing which is really important for us, which I say the really the most important or the only really thumbs up, which is counting at the very end, is that once you have it released, once it’s in the hands of the users, and once the market gives it this feedback, you did a really good job.

Ralph Jocham: So in order to do that, there are certain things which become important. It means, if you sit on your product for really long until you make a release, you have for really long inventory you build up, that’s bond capital. But if you manage to release more frequently, you get more frequently feedback.

Ralph Jocham: And that means you can deliver value more frequently, and because we have vision, you have some ideas, you try to deliver value more frequently, and then you learn from that, and if the learning is good, perfect. If the learning is like, well, no, that’s not right, at least you have the value of learning.

Ralph Jocham: That’s then again, where the validation comes into the picture. And at https://scrum.org, we also have something developed, which we call EBM. It stands for Evidence Based Management. It’s essentially, the idea is that in management, we have to make many decisions, and it’s not about making only good decisions. Because if all of our decisions have to be right, we probably would play it far too safe and not take any risks anymore.

Ralph Jocham: And I think we have to take risks as a business to be successful in the long run, but it’d have to be good educated risks we are going into. With EBM it’s really about how can we, let’s say we make this decision, let’s put this feature into place or let’s remove that feature and change this one over there.

Ralph Jocham: How should specific measurements change once that feature is in the hands of our users? And once numbers come back and they’re right, we know it. Great. We thought about this as this has happened. If it doesn’t, at least we would know we are wrong. So the numbers are telling us what’s right. Then we can think about, do we want to get rid totally of it or do we want to make some changes here and there?

Ralph Jocham: And that’s kind of the idea about really closing the empirical feedback loop based on hard numbers, facts, which cannot bedisputed.

Bill Raymond: Right, thank you. And so far, what we’ve been talking about is the product owner on a product team. What would the size of a typical team be?

The size of the SCRUM team

Ralph Jocham: Well, the SCRUM guide, I’m going back to that, says usually less than 10. That means you would have a product owner, you would’ve a SCRUM master then about seven developers or something like that. For me personally, a good number is six developers. But I had more than 10 already once, and it worked.

Ralph Jocham: It doesn’t really nail you down a specific number you have to have, but it’s a small unit which is skilled enough, cross-functional enough to really deliver vertical slices of functionality, but still small enough to be quick and nimble and navigate the problems and the complexity we run into.

Ralph Jocham: Let me just build on top of that really quickly, that’s also like the same team size we often see from military special units. So probably there’s something about this as well.

Bill Raymond: That’s a good point. It seems like small teams can get a lot done if they’re comfortable working with each other and they understand what their dynamics are and they’re coming from a place of psychological safety. It sounds like those are some pretty strong things that suggest that these smaller teams can be more effective than larger teams.

Bill Raymond: However, we know that the bigger a company gets, the more teams there are and the more cross-functional elements there are. So I guess my question would be, okay, so we have this team that’s doing the work and now we are scaling, the company’s growing, we’re doing great work. And now there is more teams to do more things.

Bill Raymond: How do we scale that product owner role so that we make sure we have consistency across our product?

Ralph Jocham: The idea in SCRUM is about we build a product. If your product starts to become larger and larger, and you have reached, let’s say, the maximum of what works in this one SCRUM team you’re having, you have to add additional SCRUM teams to the same product.

Ralph Jocham: So essentially, in SCRUM you wouldn’t scale the number of teams just randomly, you would really say kind of what are our products? And that’s probably the very first and most important question for every organization. What are our products?

Ralph Jocham: often in organizations we get something to do and then we break it apart and make it fit into our organizational structure.

Ralph Jocham: And by doing that, we have so many silos which need to be coordinated. And that’s basically when you get all this dependency management, those huge charts and things like that. Now we would do it the other way around, we just say, this is our value stream. How as an organization, can we wrap ourselves around this value stream with the skills, technologies, and other things we need in order to turn this into a product?

Ralph Jocham: So you would put the product in the center. And then organize the organization around that.

Ralph Jocham: And once you have, then you suddenly realize, well, we need 30 people to do that, while that’s more than one SCRUM team can possibly handle in a good way. Now you would have several SCRUM teams. However, and SCRUM tells you, every SCRUM team has a product owner, but you can be a product owner for several SCRUM teams. So essentially, you would have one product backlog, one product owner, and let’s say, I don’t know, let’s say five SCRUM teams, sharing this one product owner. And then in a scaled product development environment, the important thing here still is that you have only one sprint review, because all those teams, they still work together on this one vertical slice per sprint, which is put together through this one sprint goal they want to achieve.

Ralph Jocham: And this will be shown in a sprint review again, to the customer, user and some other stakeholders.

Bill Raymond: Yeah. Does that get to a point where it’s overwhelming for a single product owner to, to run maybe three or four teams?

Ralph Jocham: And this goes back to the sentence I said already out of the SCRUM guide. The product owner may do the above work or may delegate the responsibility to others, however, she remains accountable.

Ralph Jocham: Now, in this point, because if you are what we like to call, a scribe product owner, you couldn’t write all those product back log items for all those teams anymore.

Ralph Jocham: You would just do this and, but you couldn’t talk to your stakeholders, you couldn’t talk to the users, you couldn’t do all the other things which are important. And that’s basically, when you then would go to the teams, Hey, there’s something I need over there. Let me, can we sit down? Can we talk about that? And then as a product owner, you would give them the insight, your understanding, and then they would take that and do the work for you and then run it back by you, think this is what we came up with, does this work for you?

Ralph Jocham: If the answer is yes, all is good, or maybe give them some feedback, and by doing that, you make the developers in every single SCRUM team, small product owners themselves, so they step up to the occasion.

Ralph Jocham: So they can’t say anymore, but this is what’s written here. That’s your fault. Because I would even go a step further. You know, let’s say you do a refinement session with the developers on something and you have a good conversation, and at some point you just ask them, Hey, isn’t this important the information?

Ralph Jocham: Yes. Yes, absolutely. So why don’t you write it down? Have the developers create their own product backlogs. They’re going to work on the next, or maybe the sprint after that. And if they don’t understand their notes anymore, they have a real problem. But on the other hand, you as a product owner, you always remain accountable for the value of the product which is being created.

Ralph Jocham: So that’s kind of, could be a really hot seat occasionally, and that’s again, when the picture of a good SCRUM master becomes important. Because you would then really want to have a good SCRUM master in each one of those teams to make sure that they do their things correctly and they’re educated about what’s important, they understand SCRUM well.

Bill Raymond: Yeah, that’s an excellent point. We’re not going to get into the SCRUM master role here, but we actually have some excellent podcasts that we’ve already produced. For example, if you want to go back into our library, Michele Magnardini, if I got the name right, actually introduces that role for the first time on the podcast.

Bill Raymond: And then we have a number of additional podcasts where we do some deep dives into the role and understand what this SCRUM master’s daily role is and how they fit into the picture. And it is a very important role. I think very often we think of the product owner as just picking out valuable things that they think are good, and then the SCRUM master’s job is to to kind of act as a project manager and inform the team as to what to do. And that’s not the case at all. And I think you’re making it very clear here, one of the words that you keep using throughout this conversation is accountability.

Bill Raymond: Even though the product owner might be accountable for delivering value and managing the product backlog, each team member is also accountable for delivering that value as well.

Ralph Jocham: Absolutely. Yes.

Trust and clarity

Bill Raymond: So, as we come to the end of this podcast, I guess one of the things that I’d like to ask you, if I’m a leader and I’m thinking that this is an important role for my organization, what are some of the ideas you might share?

Ralph Jocham: So for me if you really want to become an agile business, you have to create the environment in which agility can really emerge. And for me, agile, it’s not a bunch of tools or processes, it’s a mindset. And if you have the right mindset, everything you do, the tools you choose, the way you work just happens to be the way we want it to be.

Ralph Jocham: Now, as a good leader, you create and you harness this environment and you make sure kind of it stays there, so essentially, you need to have a clear understanding what this entails for you to do. And often, that’s a challenge for people who are more like project managers or managers in general, because they want to be in control, but you want to be exactly the opposite. You want to get not being in control anymore, because you want to leverage emergent behaviors and structures kind of in this environment, in this, let’s call it even a garden. So you wouldn’t make sure what is growing where, you just would say, this is the patch of land we have, and let’s see what we can make out of that, what happens over time, what works well.

Ralph Jocham: And for this you need to create clarity. Clarity in regards to where do we want to go as an organization, what’s important, what are the next intermittent goals we need to reach and to trust. Because if there’s no clarity, people would just wander off and do whatever they think is important, whatever somebody gave them to work on and just say, but I did what was written there, so it’s not my fault.

Ralph Jocham: Now, but then trust has a lot to do with, are the people mentally, and you mentioned before,safe working environment. How can you create that environment? And it’s really about once people feel safe at work, feel safe that they can do something and might be wrong once in a while. There are failure cultures is what, which comes to their mind. I think we have achieved something of something really worthwhile because, and I’d like to think back aboutthere’s this AQAL model from Ken Wilber, he’s a philosopher and he has really clear thinking around that. And he says, usually, what organizations measure are the external aspects. What’s our revenue? How long is the lead time? How many bucks? What’s the quality, customer happiness? And that’s what EBM is there for a strong part, and that’s important.

Ralph Jocham: But in order for this to happen, you have to also focus on the internals. How do people feel when they go to work? Do they say, yeah, it’s Monday, it’s going to be a challenging work, but I have great colleagues and we are going to make some nice product.

Ralph Jocham: Or do they say, oh, Monday, I’ll get through that, it’s Friday soon, I’ll manage to, to go through. And if you really manage to create this internal value kind of system where people feel safe based on principles and values, you have good people doing good work, and then basically, your external factors, your external measurements you’re looking for will happen. And this is what leadership is all about. Trust and clarity.

Bill Raymond: I guess there’s one thing, I probably like to just converse with you on for just a moment while we’re on the topic of leadership and product development. We’ve been mentioning project management a lot and we’re saying, Well, this is how it’s different than project management.

Bill Raymond: But I do want to point out that despite the fact that we’re called "Agile in Action", and despite the fact that we are talking about product ownership here, we’re not suggesting that project management is not a valuable thing to have in an organization. I think that sometimes we forget that there are lots of projects that can be scoped out, delivered, and completed with project management roles and teams that kind of come together and then disperse after it’s done.

Long-term product mentalities

Bill Raymond: But what we’re talking about here is long-term product mentalities, thinking about how teams are going to continually focus on the building and improvement of a product.

Bill Raymond: Do you have any other thoughts on that as well?

Ralph Jocham: Absolutely, what you were just saying, it is right. It’s not that everything has to be done that way, and that has something to do with complexity because we operate in the, we have the unknown unknowns. We can’t know everything. We can’t polish our crystal ball really hard and have all the answers in place.

Ralph Jocham: So that’s where this discovery process comes into place. That’s why we have to work in those verticals, short iterations.

Ralph Jocham: But there’s other type of work, there’s complicated work and simple work. And for these ones, I probably, you wouldn’t use an empirical process control, which SCRUM is one of.

Ralph Jocham: Because these are the things where we can, through the right practices, through using the right tools and processes, create a plan and then basically follow the plan. And this is where I would probably not use SCRUM at all. Yeah.

Bill Raymond: Ralph Jocham, this has been a great conversation. If anyone wants to reach out to you, might they be able to?

Ralph Jocham: You can find me on LinkedIn, so it’s LinkedIn/in/RalphJocham, my first name and my last name. Otherwise, just look me up there. I think you will find me there.

Bill Raymond: Great. And also you have the book, The Professional Product Owner, Leveraging SCRUM as a Competitive Advantage. This is a podcast, but we are also recording the video, so I don’t, I think you might have the book that you could just hold up there, don’t you?

Ralph Jocham: Yeah. Here’s the book and I just said this before, I have a green screen behind me and having a green book with a green screen doesn’t work so well. But, think about this as a clear green, but that’s the book. It’s, wow, I just realized it’s about 320 pages, lots ofproduct owner and SCRUM information.

Bill Raymond: That’s great, and it’s a great book and I appreciate you spending the time with us today. Of course, the links to Ralph’s LinkedIn and the book will be available on the agileinaction.com website. If you’re in a podcast app or on YouTube, just go down to the description in the show notes and you’ll see the links there.

Bill Raymond: Ralph, this is a great conversation, thank you so much for your time today.

Ralph Jocham: Thanks, Bill. Thanks for having me.

Bill Raymond: