Navigating the Product Management Vacuum with Ralph Jocham

Join host Dave West in a conversation with Professional Scrum Trainer Ralph Jocham as they chat about the challenges and strategies of Product Ownership. Explore the concept of the "Product Management Vacuum" and discover how to bridge the gap between business strategy and product development. Ralph shares insights on the three V's - vision, value, and validation - and how they drive product success in an agile environment. 

Transcript

Dave West  0:20  
Hello, and welcome to the scrum.org community podcast. I'm your host, Dave ware CEO here@scrum.org. Today's podcast, I'm actually really excited about it because it's a topic that I care deeply about. It's on product ownership antastic. And I'm excited to have Ralph Yocum, one of our PSATs join us for for this podcast. So if you might know Routh from the book, he co authored on product ownership with John McGraw Hill, an awesome book, one of my go to books whenever I'm annoyed with my own ability to do product ownership. And also, he's obviously a bit of a leading light in the area of product ownership. I've known Ralph from his tireless efforts in our community, on improving our product ownership curriculum. In fact, he and done authored our pspo class that maybe you you attended, and have been instrumental in improving professional Scrum. From the moment I've been here over the last nine years, I consider myself to be my friend, confidant, and sometimes counsel. Maybe too often, counsel, welcome to the podcast. Ralph.

Ralph Jocham  1:38  
Welcome. Thanks for having me.

Dave West  1:41  
Welcome. So before we get into the content, because, you know, we could talk for days on this, perhaps tell our listeners where you're speaking to us from?

Ralph Jocham  1:52  
I'm based in Bern, Switzerland, so center of Europe, but it doesn't belong to the European Union. That's a specific thing about Switzerland. I

Dave West  2:01  
know. And also, isn't it like it wasn't Einstein born in Bern, was

Ralph Jocham  2:06  
actually born in Germany. But he used to work for the patent office in Bern. And he came up with the relativity theory, when it when he was living in Berlin. So there's a machine we can visit the house, you can sit at his desk, essentially, where he had this marvelous ideas. Incredible.

Dave West  2:24  
Hopefully, you sit occasionally at that desk to get good ideas around product, product ownership and management. Okay, let's get into the content. And it's a topic that I'm really interested in. So you've been talking a lot recently, and certainly we've spoken about it about this thing called the product management vacuum. Maybe you want to what is this product management vacuum?

Ralph Jocham  2:56  
If you think about it, just basically every organization has a vision where they want to see themselves five years down the road. And then they take this vision and think about what does this mean for us, and they they translate that into a business strategy. So let's just assume organizations are capable of doing that. Now, if we go further down, I think if we would have all the facts, everything exactly what we need to do, we now have the engineering practices and the possibilities to deliver on that. But what happens between we have our business strategy and we know exactly what to do, because we know how to do it. And this is a disconnect. And it's really translating the strategy into the tactics can the operational thinking the doing. And we all know maybe remembering from physics class, that a vacuum has a strong need to fill itself. And if we're not careful, the acid will fill itself but often with artifact things we we all remember, because that's our classical project mindset. So we might have a charter, we will have milestones, then we would have our classical reports on time scope budget. Now, this project mindset is really, really strong, and it develops its own dynamics. And essentially, if you and our project manager delivering on the plan on time and scope and budget is more important than customer outcome. We nailed it. We made the thing that customers really need it, they love it. And this is really what Don and I describe in our book as as the vacuum and this is for me, where product ownership really comes into the picture because product ownership connects the business strategy all the way down to the implementation. And make sure this vacuum doesn't basically exist by essentially as a product owner you would then know about what is really destroyed. Did she have tokenization, if you haven't understood that you couldn't really act on it. Otherwise, you would just get a plan and follow that. And then you wouldn't be a product owner. So you take that idea from the from the organization, you think about it, and you come up with a product vision, this could be a new product, or maybe new version of an existing product. Once you have that vision, that becomes your North Star. That's what we want to achieve, because that's a small part, what we can do overall for the organizational strategy, company vision. And then once you have that VIP product vision in place, you think about how can we achieve that. And that's the product strategy. Now, instead of writing everything down, and then again, throwing it over a wall to the developers, because they know what to do, essentially, from an engineering point of view, it's really that you then connect to them. And you give them the same understanding about why you want to do what you want to do. And once they have that understood, and unnatural, we all know that self organization, self management is an really important aspect. And once they have understood that they can start to act on it on their own, because now they have the, the understanding to do that. So what I often like to call them mental, the cognitive alignment, so that we really kind of on the same same understanding, because the example I often bring is like, close your eyes and think about a tree. Now I see a big oak tree, which basically was growing the street, when I was a child, now everybody sees another tree. And that's the cognitive ballast we bring to our work. And we have to really talk about this and get this understanding lined up correctly. And that's kind of this is what I really think about this is product ownership, all about taking the idea from the organization, thinking about it, translating it from the strategies into operational tactical things, and then working closely with the developers so that they know what they should be doing. But

Dave West  6:55  
hang on a minute, now I just need to so organizations, it classical organizations, organizations, maybe we would say today, the ones that haven't gone through this transformation are product oriented, they take a strategy. And then there's this six months of ridiculous like lots and lots and lots of meetings. fact I was I was in Switzerland, not not unfortunately, when I was in Geneva, and that I was chatting to a guy that runs supply chain for a large consumer packaged goods organization. And, and he says, Well, we're planning our planning process takes nine months, nine to 12 months. And it starts, literally, it doesn't end, the next year is planning. The next horizons planning starts actually why we're still in planning for the previous horizon. And we're in this continuous planning process, etc. And we, you know, horse trade, and it's all about resources. And what can we do? Are you proposing a different? Do we still do that big, like nine months of horse trading? Or is it a little bit simpler now in this product, product to fill this vacuum as it were?

Ralph Jocham  8:07  
Yeah, so that's a totally different different thinking behind the natural. And I think this is where most organizations really struggle, they want to have the benefits of agile, like, yeah, I have this big biceps and my six pack, but I don't work out. And you really need to get there, you need to change the way your organizational is really thinking and acting on that. And essentially, in a classical way, what you just described is the organization is often broken down into functional silos. So we have maybe a strategy department that come up with something and then they pass on some documents to the next department, they work on that and they pass it on to the next one. Now, this is really a lossy process. information gets lost along the way, understanding gets lost along the way. And I think we all remember maybe the telephone game when we were children, like, you know, chess parties, 10 kids, and suddenly, the message is something completely different. So there's information loss. And this is what we really want to change in the way we work in action instead of being driven by activity where essentially the batch size is everything. So we plan everything, and then we analyze everything, and then we design everything and so on. We want to turn this by basically 90 degrees. And just so you know, what is the first most important customer outcome? We should aim for? Maybe even talk to the customer says this right? Would you think that would be not okay for you? And if they give us the thumbs up, then we think about how can we demonstrate that functionality, and we will do a little bit of everything, a little bit of strategy, a little bit of analysis, design, implementation, testing. And then this is where essentially the feedback loop in scrum comes into the picture because then in the sprint review, we could show a working product instead of just oh, this is a document is this good? Looks nice. Yeah. centerline Working product. And this really changes the way also we work with requirements. Now this is my personal opinion, but I think he already wants to get away with stop doing classically requirements engineering, because instead of writing those large documents where everything is codified, essentially, this is what the requirements engineering, in my opinion is about codification of knowledge. So I swapped my understanding onto paper, someone else reads it six months from now. And voila, they have exactly the same understanding again, but it doesn't work like that, for the reasons we just talked about. So instead of doing that, we start to collaborate with each other. And this goes back, if you think about the Agile Manifesto, customer collaboration over contract negotiation, so we would talk to them, then we would get together with the cross functional team. So not just programmers on the team, but also business analysts use experienced designers. What else you need, deliver on that, show it to them, and then they can give us feedback. Now, maybe their feedback is like, wow, this is really nice, but actually not what I was looking for. Anyone can say, okay, great. Let's talk about that. Let's figure out why this is wrong. Get this understanding. And this is where I, I really think the because we operate in the complex, where we have the unknown unknown. So we can't know everything upfront, there will always be surprises. There's this model about the circle of control, circle of influence, and everything else. So even if we would do everything perfectly in our circle of control and influence, there's still the entropy around us. And I think we all have experienced in the last couple of years, what that could mean. So instead of really trying to make the big plan, we work a lot with the the narrative, the understanding, so because something happened in the past, which makes us think we need to change something so that our future is better. And the future is better. planned. That's that's how I think about our strategy. It's like a vector pointing in a specific direction to division we have. But in the end of the day, if you really think about strategy happens today, every day, again, and again, by what you do. So if the people have the understanding, and with people, I mean, the scrum team, and everybody who has something to do on this product, if they understand the past the problems, which has triggered, why we do what we do, and understand what's really anticipated that can deliver on that. And then we really get into this closed feedback loop. Because in the end of the day, we cannot miss prevent mistakes. If we always play it safe, I believe as an organization, you will eventually disappear in the big sea of mediocracy. So we have to take risks, educated risks. And if we minimize if we manage to minimize the time between making a mistake and learning from that, that's brilliant, because it's an instrument. So let's say two weeks now, so we do something two weeks later, we know nice apples, right? Or oops, we get a slap on our wrist, I mean, can figure out what it was improve on that. Maybe adjust our strategy slightly, because we have new insights, new learnings. So

Dave West  13:12  
hang on a minute. So ultimately, we have a company strategy, we then determine the investment that will make an each particular product which will then determine ultimately, or then determine how much effort we're putting in each product as an organization, which then will determine how the strategy will then be used by the person that is in charge of those products, the product owner, we would say, to determine what actually they're going to do in that product. So we seem to simplify the process massively. But tell me that, which is amazing. And then we start working, we started delivering small increments of understanding of learning against that strategic vision in the context of the product that we're that we're that we're investing in. And that tends to work. In our in our class, we talk about the three V's vision, value and validation, right? Yes. So how does how do those three V's really work? Because you've got this vision, and then you still got to decide, you know, which, and then ultimately, we're gonna be delivering stuff and you have to validate it. What, how does it all fit together? If that's something that you talk a lot about? Can you can you share with our listeners?

Ralph Jocham  14:32  
Yes, absolutely. So the three V's is this other it's kind of like the three main sections in the book from Don and myself. So vision is really about what is it what you want to achieve? I always believe and I think this is a nice thought to have because with the work we do, we make someone's lives better. And if it's just five clicks less their lives has improved in that regard. Maybe they can get home earlier and see their children or something. So whatever we do should have a positive outcome for someone. And that's division we want to achieve. And division is then basically, if you work as a product owner, that is division of the product you want to, to implement. Now the value is really kind of where, think back to the product management vacuum. Because this is really where we want to find out what is the most valuable thing we could be doing right now. And this really is like opening up bringing everything in what is the market doing? What is the competition doing? What are our users telling us is there could be anything and then we think about all of that. And then in that context, we try to find out what's the most valuable thing to do for our users, again, by by talking to them. And essentially, then we go ahead and we deliver this small increment of product, I like to think about it of this vertical slices. And now, a little bit of a step back here is that because we work, classical project management has this belief that if we have enough information, we can plan everything 100%. But if this could be true, the moon missions, Mars missions would never have failed. Now, there's always you know, the things which can go wrong because they're outside of our control. So it's just the reality. And because of that a linear approach, a defined approach will never really work in those environments. So that's where we want to work with an empirical approach. And empirical approaches, they work through feedback loops, carried by experimentation, and then learning. And that's just what we need to do to leverage and, and we don't want to go too much into complexity theory right now. But in complexity theory, there's this concept of an enabling constraint. So enabling constraint doesn't prevent accidents or bad things to happen. It's just it's like a rail guard, like a car, you know, if you swim off the road, and that's where you got, you don't hit the tree, you don't die, you just have a wrecked car. And the same thing, I can think about enabling constraints, what can we set up in our organization, that while we take some risks that if something goes wrong, we don't really kind of hit the tree, essentially. And what this means is the vertical slice, the slice of functionality, this increment is really a powerful, enabling constraint, because this thing proves that our engineering process is working, that our integration processes are working, our testing processes are working, our people are able to collaborate with each other. On the other hand, we can also then show it to our end users and ask them, Is this what you have been looking for? And they can give us feedback on that? And if all of this is yes, yes, yes, then we are in a really good position. And if you think back to one of the principles in the Agile Manifesto is working product is the only measure of progress. And guess what we have working product every single sprint?

Dave West  17:56  
The the choice that you mentioned value, right? It's about making choices. The problem I have often is, you know, I have a clear vision for scrum.org. Usually, not always clear, but usually it sort of becomes clearer. And then I have a bunch of things that we can do to deliver against that vision. And how do you how do you understand about value? How do you measure value? How do you identify value? Really, that isn't really a gap. You talked a little bit about, hey, there's it's gonna make somebody's life a little bit better. But, you know, how does that really get? Yeah,

Ralph Jocham  18:39  
I'm with you right now. And you know, when I talked before, I didn't answer that, because that was the three V validation. How do we know? Right? So once we have decided committed and doing something, the next thing is how would we know that we have been successful? How can we measure that? So it's really about bringing in metrics, hard facts. And this is the validation. That's one of the things which which thunder have developed, which, which I really like and it's EBM evidence based management, how can I bring in the evidence that my decisions were right, or maybe wrong? I mean, it's then we could learn again from that end, and take it from that end. EBM has those four key value areas where we have current value that means market share happiness of our users, along those lines and unrealized value where we see maybe opportunities, what could we improve where there's a satisfaction gap, if we could bring something in that it will be really good. So current value on unrealized value have a clear market focus, so kind of customer orientation? And then there are two other ones which I think many organizations don't really value enough. Because it's one is ability to innovate, how innovative can we really be if you spend so much money, how much of this money really ends up in functionality or how much money gets lost along the way. So think about like a big pipe on watering a big field. And there's holes in it because it's old and rusty. Now, how much water do you lose along the way. And this is what I just mentioned, when he talks about, you know, good test automation, good integration system, build pipelines, all of those things, if they prove your engineering, your wiring underneath, internal capabilities is working right. And another one, the fourth key value area is time to market. It say we have the world's best idea since sliced bread, how long would it take until the customer has it in their hand. And this is really, now if you have a classic organization you just mentioned while we worked nine months along those lines, and this is how we do it. And if you have the world's best idea, you will look at nine months, maybe a little bit more. But in an agile environment, just we can pivot and just say, well, this happened, the competition lounge launched that we need to act on that, okay, we sit down, we come up with an idea a couple of days later. And then we start acting on that delivering this other vertical slice of functionality, make sure it's right. And then we can ship it. And that's what my opinion, what business agility is all about.

Dave West  21:09  
Yeah, I mean, ultimately, the very name, right, a business agility, it's about financial respond rapidly to the environment in which you're in. And the the evidence based management the those measures that you describe the KVM KVM, in particular, are really good ways of getting that cycle going. But it unfortunately, requires a level of discipline in the organization to start capturing those things. And talking about those things, which can be really, really hard. One thing that I seen a lot recently is the trend in OKRs. And goals, you know, this is one way of trying to pair goals with measures, which is what OKRs ultimately are about. And there's the you know, so how does goals, you know, how important to goals in terms of setting this journey in motion, and making it actually act act extra executable by the organizations and by the teams.

Ralph Jocham  22:14  
I think they're really important. I'm a big fan of OKRs. Assuming they are done, right. They have been originally this described. Because this is our our orientation. Because if we, if we don't have a clear goal, we just do busy work. And it looks good, because people are running around doing a lot of things, but it's not directed. Now. And this is the thing about having a clear vision about the product, I think that's really important. And then in Scrum, we would have the next smaller goal, a product called let's say, four or five, six months down the road. Now in July, I would like to have this and this in place. And again, that's something we can put our teeth in. And this is what we want to achieve. And along as we go there with regards to our sprint calls. And as we all know, a sprint goal should always describe an outcome never just be a long shopping list. So if we achieve this outcome, then we will know we achieved it yes or no? And if we know Yes, great. Let's look for the next one. And then we do this until we achieve the bigger goal, the product goal. And we keep on doing this from product quality product goal until we reach our vision. And by doing this, we get this measurability and in the pspo a training we talk about something what we call the product wall. It's like this dashboard where all crucial, crucial information from our product we're working on is visible. And you know this is you bring in EBM, you bring in your impact map your users story, kind of all of that together. And then you have this one shop stopping place where it could put anyone in financial say, this is what we're doing right now. And these are the things we're looking for. And this is how we measure. And right now we are here at all and agile is all about creating transparency. And I think this is really beautiful transparency, because then people should hopefully have the impression. Wow, these guys are good. They know what they're doing. I think my money is well invested.

Dave West  24:12  
And maybe they'll have some feedback as well. I do remember i i stopped when I was running product there. We had a product war in Confluence. And we the great thing about it was when I when I willed it out, is I get feedback, particularly from McKesson, Nealon chelski. Some of the key stakeholders never a VC and they never gave feedback. They just said why is there no more sales? But the Yeah, and it was really, really good because sometimes it was a little embarrassing, because the you know, I'm like, Why didn't I ask that before? So having that thing can be incredibly useful for it and I guess all of what we've been talking about. Route is product owner Yep, and product owner, right. So there's this person, that's very, very, I'm a little biased here. So I apologize. But it's a very, very crucial role to navigate this transformation. In this age, where complexity is much higher, and digital provides us with this ability to do things much quicker and much better. So what is the role of the product owner in this?

Ralph Jocham  25:28  
Essentially, everything I've talked about this is this is for me to product ownership. And I like to talk more about ownership like doing instead of having a role, now really being accountable for for those things, bringing the business strategy down onto the ground by doing all of that closing the feedback loops using empirical process controls and sticking out your neck once in a while and taking an educated risk.

Dave West  25:55  
And and I think the key point that you said was, it's, it really isn't a role necessarily in the classical sense, it is a set of accountabilities, it can be played by General Manager, it could be played by project manager, if one program manager could be played by product manager, depending on the organization. And the like, the key thing is that they bring together company vision, business strategy, and make it executable in the context of this product, this this bound set of value that we're that we're delivering to the market. Exactly, yeah. Cool, Ralph. It's an absolute pleasure. I could talk for hours about this, but we try to keep these little short, I've already run over my normal time box topics, but I'm doing my best.

Ralph Jocham  26:50  
We could do another one, if you don't mind.

Dave West  26:53  
Yes, yes, we could. And yes, we should, that and I'd love to lean in, in particular, to the actually what our product owner does on a day to day basis, because I think that is something that we need to explore more, because it is it is an incredibly challenging role. And as I say that, from my own experience, because everybody hates me, you know, the, the developers hate me because I'm setting unrealistic or when that's not what I would do goals, the stakeholders hate me, because I'm trying to manage a balanced portfolio of choices in it, and then the people that are paid for it hate me, because of course, they could just knock this up in PowerPoint, and why would we need anything else? You know, so it is a very challenging role. So maybe, maybe I'll take you up on that now. So, but thank you for spending the time talking to us, hopefully, the listeners got a lot out of it. So my biggest takeaways, were, we continue to see a big disconnect between business strategy and the actual goals, plans and work being done by teams. This is, you know, this is described by Ralph as the as the as the vacuum of Product Management. And I think that really, vacuum is a really interesting word because because it sucks things in which is, which is I think, what tends to happen in filling this vacuum sucks things a lot of work that isn't necessarily as valuable as, as we would want. product ownership sits in this, this this space is intersection between the business and the operator of the solution, the technology, which means that ultimately, they're responsible for making that strategy rail for, for both the customers but also more importantly, perhaps for the organization, the team, you know, because there's these people are the people that will be delivering ultimately, the value. Ralph introduced to us or made us reminded us of the three V's vision, value validation, and how scrum ultimately enables the execution of those V's in these things that we call sprints, and how that process is empirical and drives us to value introduced us some of the ideas of EBM and those those those four areas to use as mechanisms to drive those conversations and highlight those those measures. And of course, we finished with oh my gosh, the product owner that's hard

Ralph Jocham  29:24  
and ending in my opinion with the product owner, never

Dave West  29:30  
wrong when you start and end with the product. Exactly. Well, thanks for joining and for our audience. Thanks for listening today. If you liked what you heard, please subscribe, share with your friends. And of course come back and listen to some more. We're lucky enough to have a variety of guests It was my pleasure to have Ralph Yocum PST from Switzerland. Joining us today and talking to us about product ownership and really this product management vacuum. But there's also many other things that you can hear on the series in the areas of professional Scrum, product thinking and of course agile. Thanks for listening, everybody. Hopefully I'm gonna hear you. You're gonna hear me again in the future, and Scrum on