Lindsay Velecina: 0:00

Music. Welcome to the scrum.org community podcast, a podcast from the home of Scrum. In this podcast, we feature professional scrum trainers and other scrum practitioners sharing their stories and experiences to help learn from the experience of others. We hope you enjoy this episode.

Patricia Kong: 0:20

Hello and welcome to the scrum.org community podcast. My name is Patricia Kong. I am your guest host again, this time because I am interviewing or having a conversation with Mr. Dave West, the CEO of scrum.org Hey, Dave.

Dave West: 0:36

Hey, it's really weird to be on the other side. But Hi,

Patricia Kong: 0:41

yeah, you're gonna get all the hard questions today. So last month, it's November now, and last month, at the end of October, you gave a webinar on scrum.org It is called product definition, how to define instruction and structure your products, that was very popular. How did it feel?

Dave West: 1:05

Yeah, it was very popular. We had, you know, over 1000 people on the Zoom web webinar thing. And then we use a mechanism on YouTube for an overflow. And that had, you know, 1000s of people on it was it was really, really popular. It felt good. But what felt really good? I mean, obviously having lots of people at the at an event always makes you feel awesome, right? It's a bit of a vanity metric. But what felt really awesome was the number of conversations, questions, comments, discussions that happened, both on social media and directly. People emailed me and messaged me, asking stuff, talking about stuff, having an opinion on something. That's what was really, really excited about the webinar. That's

Patricia Kong: 1:54

great, because I think that even though it's great that the participation was high in some way, when you're thinking about, you know, product definition, it almost seems like an old conversation. It's something that's, that's, that's that we're always asking and hasn't been answered maybe very well or concisely so so for you Dave, just in a nutshell, you know what? What is a product? How do you define it?

Dave West: 2:22

Well, and this is the point, right? I think that we spend a lot of time talking about product. Obviously, Scrum is built around product. You know, we've got product backlog, product goal, product owner, product increment. I mean, it's, it is. It's all about, but what is a product? And there's a lot of debate in 2020. We released a scrum guide. It said, basically, it's a vehicle for delivering value. It has clear users, people that you know, gain value from it. It has stakeholders, people that invest in it and and get some sort of return on on that investment. It has a clear boundary. That's how the scrum guide defines it. But ultimately, the thing that came out from the discussions after the webinar was really that it is arbitrary and that, and even if you know, a lot of people say, Oh no, it's very clear, it has to be connected directly to a value stream. It has to be something that somebody pays money for. Otherwise, it's not a problem product. It's a shared service. It's some sort of subsystem, or whatever. It's got to be that and the and the truth is, it isn't because, you know, you say, Oh well, it's going to be discreet, buying, buying a, you know, mortgage, mortgage. That's a product, somebody that you go in and you buy a mortgage, you know, or or take out a mortgage, that's a very clear product has a very clear start, does it? Where's the start? When they come into the bank? Nobody does that anymore, I guess. But log on to the website. Is that when they start, or when they start looking at houses and go to one of those little apps to work out how much they can afford? Is that when it starts? Oh, hang on a minute. Is that, you know? So the point is, it is it is ultimately an arbitrary decision. But what I say to people, if they say, is it a product, and where does the boundary? Ultimately, it's about value. What you described. Do the users have a particular problem? You know something they need, and does your thing and product provide value to solve that problem? Does it have a clear boundary? Do they think that their problem? Where do they think the problem starts, and where do they think the problem ends? And ultimately, that is the definition and the boundary of of a of a product. Now those users could be external users, customers, as it were, people paying for a service, or they could be internal users, people that are taking advantage. Know, working on a call center or providing, you know, brokerage rates or whatever your whatever systems that your business has. And I think that at the end of the day, that the abstraction of product is an incredibly useful tool for teams to rally around, you know, because it provides a boundary. We know when it's this is in our product. This isn't and that will change as we deliver more capabilities and as users become more sophisticated, or change their or their needs, change their context changes. But it has a boundary. It has stakeholders. It has it is there longer than the moment that I'm working on it, meaning that it has longevity, if that's such a word, which is very different from Project models, Project approaches, which think of the work as the unit, whereas we think as the product, as the unit which we're doing work on. So I don't know if that answered your question, but at the end of the day, I guess it's about users, and it's about value, and it's about outcomes.

Patricia Kong: 6:04

I think definitely the outcomes, and I think that that is obviously you kind of hit on, well, some people say, you can't say that, and Bucha, there's no internal products. But I think that the way that you described it is probably helpful, or might frame it a little bit more for people who are in different industries, beyond finance, beyond, you know, just general products you can hold in your hand, like in maritime, oil and gas, all these different real estate so it goes beyond that. So then it's kind of simple, what you said in, in a way that is, you know, I don't want to say beautiful, but it's a simple way to think about it. Why has this been so hard for companies to move from a delivery to product organization over the past couple decades then?

Dave West: 6:53

Oh, so there's so many reasons, I think, ultimately, and predominantly, the most of the questions I got asked afterwards, or most of the comments that I saw, it's about digital products. It's about the fusion of digital technology into some sort of business process that provides some sort of value. So the biggest reason why we've had a real problem moving to this way of thinking is the separation of Business and Technology. So the business group of, you know, see, they need this set of capabilities to, you know, imagine I'm a consumer packaged goods company, and I'm and I'm selling baby food, right? Baby food, nice, simple, physical product. It's they've been the same since even you and I had baby food back at, you know, hundreds of years ago, when we were young, and so, just right, that's so not true anyway. So you got your baby food, right? You're teething. Baby food from from nine months to two and a half years now. And they say, Well, hang on a minute, our customers, we really need to add some value. You know, they're asking us these questions about nutrition value. And, you know, what should, how do I get a balanced diet? They're doing sort of like the, you know, I don't know, Weight Watchers for babies or whatever, and the so they say, oh, we need digital product. So they they describe that as a series of features, and it goes into a project plan and an investment planning process. And then it gets given to a bunch of IT people to build. And they build that. They build it based on those things they may interact closely with both the users and the stakeholders that asked for it and jobs done. And then this team moves on to the next set of projects that they that they have to work on, and your baby food app is sitting there without any real future until some disaster happens. It stops working, or somebody moans about it, or you get sued, and then all of a sudden, there's another set of features coming from the business going into this team and ended it. So my I think that the separation of Business and Technology is, is, is at the root cause of all, all of this, because I think that if you bring technology, if you, if you, if, if you're an organization's Digital First, you know, you're a startup, or, you know, even in the baby food business, but you're a startup now you, Of course you would, you would think of it as a holistic view of what product is, technology and everything working together. And you wouldn't have these distinctions. It's an arbitrary distinction, but a distinction that historically has, you know, has been in place. So I think that undermines the ability of us to work in a product way. And I think the other thing is, there's such amount of complexity in organized, particularly large organizations. We've got systems, we've got apps, we've got capabilities. We've got value streams. We've got, you know, release trains now with things like a safe we've got we've got all the. Stuff, and it's just this very complex world and product seems too simple to solve it, right? Because it is. It's an incredibly simple way of thinking about it. I'm not saying it will replace all of this, but you could think that some of your core capabilities, a significant percentage of them, it could be owned by a team or teams of teams, working with a product vision, having a clear understanding of stakeholders investing based on cost and value, you know, some sort of, you know, optimizing that that return on investment, you know, has a maturity so that has great way of managing how much you invest in it. These products, you could really simplify everything. And I think there's a serious vested interest, and you know about getting too political in the organizational constructs around these value streams, capabilities, applications, departments, special you know, skills, you know, shared services. And because of that, you've got these people that have these fiefdoms, these departments, etc, this complexity. They don't want something to come in and go, Oh, it's actually quite simple. Let's just, we've got these set of users. They use this stuff. Let's group it, let's define it. Let's bound it, let's invest in it. Let's build a team around it, or a set of teams. And job done, because it kind of undermines everything in the organization. So I think, I think those two things, I think ultimately, at the end of the day, the separation of business and technology has created this rift. And then the second thing is the in the current investments and focus and structures that we have in place to support this incredibly complicated mirror, you know, combination of systems, departments, value streams, business processes, etc, etc, and, and if you do product, it kind of simplifies all of that, really. At the end of the day, I

Patricia Kong: 12:04

thought we solved that problem 10 years ago when we said, rename yourselves business technology. So let's try. Let's, let's take two things. So I would assert that in a traditional, let's say larger organization, maybe not even you know, the the way that people prove their status and ego and demonstrate their power is, one, how many people report to them, but secondly, by how much budget you have. So, you know, and that's why it's like, gotta use it, or you won't get as much next year. So how would, how would that? And maybe that's kind of the what we want to hold on to it. Because if we're saying this is moving, then some of the budget is moving and the decision making is moving somewhere else. So, so how does that look differently? And how would you what would you suggest people do as they start to think about changing that structure? Because it's quite easy to say, Okay, here's the year, here's the budget for everybody.

Dave West: 12:59

It was interesting. So in preparation for the webinar, I interviewed and had conversations with a couple of and yes, they were both financial companies, because it's all about access and timing, right? And I talked to these two organizations, actually, I talked to a third one as well, which in consumer packaged goods, but which, which also informed my decisions, but the two financial services companies were very much invested in it, in a in a product model. And so I went in, and we were really simple, like, Hey, this is why is it so hard for you to build your portfolio and structure it? Because it's really simple. Look, you just look at your value stream. And they went, Yeah. I was like, what they said. So they talked a little bit about legacy, you know, the existing systems, the existing people that have specialisms and expertise in certain areas and that and these people were finite resources. Well, finite so they had to work out, would they fit in a product? Would the product be built around the systems, Conway's Law kind of thing. But the other thing that was interesting so and there was some of that, but the thing that was really, really interesting was exactly what you described, some of the initial ways in which they broke systems up and broke value streams up and created products that you wouldn't necessarily want to do, if you started from the fresh was because of the way in which the power structures worked in the organization. You can't suddenly go, you know, this, this incredibly important product that, sorry, this incredibly important person who has, you know, 200 people reporting to them is, is is pivotal because of the core existing system, you know, mainframe system in this financial services company, which is currently nicely bound and is all these projects are using, you know, providing requirements to change this mainframe system, you can't, suddenly, you. Say, well, actually, because it these, these projects actually are more light project products. You know, they're, they're working on customers and outcomes, and they have a clear idea, let's break this department up and, oh, you're gonna, well, I don't know what you're gonna do, Mr. Leader, you can't instantly do that. So there's a sort of transition process that has to be in place around how you think about your capabilities. And from what I got from particularly to financial services companies, the consumer goods company was much earlier on in its journey, what I got from that, from that conversation, was, well, there's a lot of things at play. And politics, position, you know, that authority, you know, current investments, current budgets, etc, did factor into it. So did existing legacy systems, you know, the capabilities there and then, and then, so did but then so did value streams. And it was a bit of a compromise, you know, things that you would think, the great example is a database, right? There was this, like, are we a product? You know, we're used by all these other external and internal products. Should we be a product? And the question was, well, how, how are people using your capabilities? Are they just, you know, creating their own tables, and you're just kind of like a shared service that helps them, or are they actually, you know, or creating their own JSON, etc, on top of it, are you Is there an API? Is there a set of online configuration tools that you're using for your for how you configure the usage, etc. And they said, Oh, yeah, yeah, we've wrapped it completely, and we've encapsulated it completely. It should, you know? And so even though initially I was like, No, a database should never database. Team should never become a product team. They should actually be a shared service and go and help all the product teams, which seems the most natural thing, the reality is, it depends you know, you know, and this particular organization, the database, example, have some challenges around that, because in the past, by not standardizing, by not having a one API to get certain data from the database, they actually got it wrong for Different contexts, and that meant that they got sued because the data they were providing to their ultimate end systems and clients was incorrect. So I guess you know, how do you transition? I think carefully and be be cognizant of the underlying structures in your organization, legacy systems in your organization, skills, power, authority, and that all has to factor into it, right? Because if you you can't suddenly take this person that had 200 people and say, No, you've got one person or four people, or seven or whatever,

Patricia Kong: 17:58

and well, I'm I'm kind of dark, but I like the idea when you're talking about value streams. So this might sound kind of weird, but in a product focused organization, I would want to see that that is a place where a value stream can come and die if the product is no longer valuable, and that should change. And in traditional organizations, they can kind of just, you know, they just kind of live, because you don't know what's connected to what. And you know that the question of value comes to play. So I like the notion of, you know, value streams are great, but as the product kind of evolves, then bye, bye. Yeah. What happens, though, with those people? Oh, go

Dave West: 18:41

on. Yeah. So what happens to those people? Hopefully there's huge opportunity in the organization. You move that. But what you've actually alluding to, and I think it's really interesting, Trish, is this core versus context. So one thing that, when you start looking at your product portfolio, you have the opportunity really, to think about what is differentiating for you as an organization, and what isn't, what is something that might be become a sellable asset that you can take to market separately, maybe like AWS did with with our friends at Amazon, right, which is always the poster child for sort of like having built something incredibly robust for your own systems. And then you're like, Oh, I could offer this to other companies. Maybe there's an ecosystem of partners. It doesn't have to be quite as extreme as the Amazon example, but you can provide it to your partner network or something. So the core versus context conversation is incredibly powerful. During this portfolio analysis. You know, what is valuable to us or what is a commodity? You know, the amount of organizations I see where that has never really been. You've never stood they've never stood back and said, Okay, so we're spending, I don't know, 500 Yeah, 200 million on it, on technology. And it's supporting all of these business processes that have ultimate value, external and internal to the to the organization. But why are we spending so much money there as opposed to there? You know, it's if 70% of your business, you know, of your cost attributes, 30% of your income. That might be right. It might be the right thing to do, but it I'd like it to be an explicit decision, rather than an implicit one. And so I think that this gives you the opportunity to make that core versus context decisions. Organizations like SpaceX, Tesla, I know they're poster childs of you know, this new way of working have done a really good job of deciding what's core to them and what isn't. Hence, the reason why, when you get in Tesla car, you're like, oh, this handle is a bit plastic here, isn't it? Because it's not important. I mean, it is important. You can't get in and out about it, but it's not differentiating and unique and and I think that organizations have to spend a lot of time, a lot of time doing that, and it's because it's very easy to believe that you're so unique and everything has to be special, and you end up in a bit of a mess from a cost perspective. So I think this is a great opportunity to reevaluate that, and you have to do it holistically.

Patricia Kong: 21:23

So in terms of that reevaluation, I'm going to take this a little differently than what I saw, whereas in most of the questions from the webinar, but as we're moving to a product organization, then how do you think that AI would I mean, we know that AI as a co pilot can help product people use wisely with judgment. How does that affect the how does that affect the teams? Agile team, is it still the same structure? Do do as many developers need to work together?

Dave West: 21:53

So, I mean, it's going to be a cliche answer, unfortunately, but I think there's some. It's such a you know, cliches often sort of mask the truth, right? But the the what I've seen, and this is the thing that's really interesting, is some of the things that we we wouldn't ever change because of, say, specialization of skill. Oh, no, we need that skill, right? Therefore, we have to keep it as a separate group, because it's, you know, it has to be kept in one place and etc, suddenly becomes less important. So you get more flexibility around that. With AI, you get more flexibility in terms of being able to build cross functional teams, because you augment them, and that sounds awful, or something really scary, but you augment them with with artificial intelligence, things like copilot, etc, and what, what, what? Well, the other thing that allows us to do and what, ultimately, and this is probably the long game, is AI. That the future programming of AI isn't going to be programming of AI, it's going to be defining clearly problems. Problems have owners. Owners have you know. So it's the ability to contextualize a problem. That's what a you know, that's what products provide us with. And it will allow AI to say, Okay, this and actually produce the solution. So imagine a world where that product boundary, that value proposition, those that roadmap, that business technology roadmap, that that financial model, all of those things the AI is aware of in some way, shape or form, and you've got this def defined product, and the systems that support it are clearly there, and then ultimately their users and the product people are defining problems that, you know, like we need, we need to, you know, increase the price of this, or we need to add this new feat, You know, sort of whatever that we need to solve this problem. We need to go in the mortgage thing. We need to provide something that we need to be able to take our mortgage product to a different market. And this is what the problem of that market is. This is the way it's defined. We give that to the AI, and it basically produces a solution because it has a bound domain to work in. So it could be really, really crazy what AI does to the product world in the short term, though, I think that, as you said, the impact of copilot and the less of the need for specialism is going to be the biggest reality, and it allows us to move to this product model a little bit easier. So

Patricia Kong: 24:43

then, what would your advice be for you know, our project managers who have been thinking about product ownership, or our product owners who are thinking about product management skills, what? What's, what's some advice you would have for them in terms of career guidance? Skills they should develop, what, what they should be thinking about? Oh,

Dave West: 25:03

I mean, that's a really hard question. I mean, the I think so, will all project managers become product owners in the future? And I think the answer is, I don't know. I'm afraid it depends. However it really does. However, I do think that this product mindset immaterial, as if your organization is on the journey to a product or not, is an incredibly valuable skill for project managers that are currently working in their very complex product domain, Project domains. And the reason why is because it gives us a series of skills. So Product Management gives us a series of tools and skills around understanding problem, understanding the needs of customers, of users and of customers, of stakeholders, manage them in an effective way, helping reframe work to be more hypothesis driven and outcome centric, and ultimately, you know, measure the impact more effectively with things like EBM, etc. So I think that if you're a project manager, and you're working in a project organization, and you spend all your time basically just managing meetings and managing if you have a little bit of downtime, if you have the opportunity to learn some stuff, I would look at product ownership and product management as the place to go and start augmenting your skills. There. There's always going to be some element of project. I'm going to call it management. They should not use project or product in the in the title and manage, managing a schedule, managing dependencies under, you know, being able to organize meetings, appreciate stakeholders. You know, those skills are still going to be relevant with product world or project world, that's still going to be crucial, however, adding to that, the sort of product thinking, of customer outcomes, experiments, the measurement those skills, I think, is Something that we all have to pick up and be able to work of it working in this new world, and hopefully some of the boring stuff, things like chat, G, P, T and and the light will will remove so that we can do that kind of work more effectively.

Patricia Kong: 27:36

Yeah, I think, and I agree, in terms of mindset, what you said, and it's really about, for me, empirical mindset, understanding complexity, and not even just project managers and product owners. You talked about managing. I mean, we used to talk about Scrum Master, Scrum Masters as the accountability that is managing Scrum, facilitating Scrum, and to have that experience and some of that product owner knowledge, or the notion of product ownership, and what that means is important. And so I was going to end it with one last question, but since you brought it up, I'm going to add another one, which was really popular, and you said the word metrics. So I think it's very interesting, because I mean, there's so much information out there about product metrics already, but there are certainly a lot of questions that were around, what type of metrics would people what type of measures would people be looking at in terms of a product based organization that would be different than A traditional one?

Dave West: 28:39

I think that there's less emphasis on task completion and more emphasis on value delivered. Now I'm not saying you don't measure task completion. I'm not saying you don't measure, you know, flow metrics, which obviously task is part of that you do need to however, the things that really are important are the value delivered and, you know, and whether it's actually being consumed as it were. So I think that the when I look at every product metrics going to be different, because every product is living in a different world. However, the you know, tools like EBM, or a framework like EBM, which obviously you're very familiar with, Trish, being one of the authors of a fabulous book on it, provide us with a great frame. Because really, what EBM does, right, does a couple of things, but the sort of core metrics that it says these are things you probably want to think about the most, you know, is unrealized value and value. So what is this product delivering in terms of value today, and what is it missing? What's the opportunity being able to have a handle on that? And obviously, you know, time to market. Or idea to implementation or cycle time, and how much of the stuff that you're delivering is innovate, innovative as well. I think that that those four idea sets, and of course, every situation is going to be different. How you employ them can be really powerful in terms of bringing people together in pursuit of value, whilst considering the mechanisms that deliver that value with cycle time and and innovation rate. I think that and then obviously flow metrics can help provide, you know, provide good insights into how you operate your systems and your factory, as it were, your product factory, and, and obviously, there's lots of things around user behavior and and the like that can help you define value in a more holistic, holistic way.

Patricia Kong: 31:02

I think a lot of people, so I think there's, there's this notion of products metrics, and then there's this notion of, we're running experiment, what are we going to measure? But I agree with sometimes people think, Hey, we're talking about agile and all this other stuff goes out the window. But if, if, I don't know if we can get some how long it takes us to get something done. And through the system, we're jumping the gun on a little bit, on talking talking about value in a different way, and, of course, lead with value. But you know, there's kind of can we get it done? And it's

Dave West: 31:33

interesting, because I was recently a project to product summit in New York City, and Vanguard were presenting, and they were talking about, you know, the their move to a product operating model. And one thing that they said is one of the one of the most powerful things that it provided was a realization that they'd been spending all their time and money trying to get the get the system of delivering features, you know, capabilities, faster and faster and faster. And then deployed DevOps that deployed, you know, agile. They were using Scrum. Obviously they were and then they realized that the business was still was happy that stuff was getting out, but they were long, yeah, we're not quite as happy as we want to be. And so when they looked at it from a product lens, they saw that the time it took from an idea to even get into the product organization was so long that it was just like, that was what the business was like. That's when and so when these ideas were talked about, that's when people's sort of like clock started. But the but the technology group, who were deploying the product, operating model, which I know highlights that separation, didn't know about the idea until it hit there, and that's when their clock, their stopwatch, began. And so they had this big gap, and they were like, Oh, that's weird, isn't it? So they tried to build a bet. They basically moved the the technology organization closer to the business and, and they're working on in improving that and, and it was, yeah, I think it's just funny, yeah, you do how long things get done. Having that key metric is crucial to to be able to effectively manage change and drive value. That's

Patricia Kong: 33:28

fun. That's maybe a day for another day, another podcast about where ideas come from, and how long is an idea good for. But okay, so you talked about, you've been talking about agile product, operating model. You just said at the conference, Vanguard was talking about starting to think about things more through a product lens and their operating model. So our online friends, there's a lot of online friends, and that all this talk about product models are the as the next, quote, unquote, big thing is really a reaction to the notion that capital A Agile is dead and that Scrum is irrelevant. I personally think that that's missing the point. But what do you think? Dave, wow,

Dave West: 34:11

that's a big question. I think that agile and let's just focus on Scrum. Scrum is a set of tools that can help teams and teams of teams to effectively work together when the environment is complex, those tools are incredibly relevant and useful when you're working in a product world. They can be useful in a project world as well. The problem we've had is that they've become a means to their own end in organizations. It was adopting agile. Well, actually, even product operating model isn't really the end goal. The end goal is delivering products in an effective way. Those products are all. Ultimately, the end goal, the thing that you're doing. So I think to something the last few years, maybe we've lost that, and now we've realized we've lost that. And of course, being good, you know, people in the world, our instant reaction is to do the exact we're going to drop all Scrum. We're not going to do Agile, we're going to fire every Agile coach. Well, hang on a minute. Well, one yes, you should stop doing stuff and fire people if it's adding no value. But, but, but, but, what value do you seek them to add? What is that? What is that ultimate goal that you're trying to achieve, that agile was a means to if you haven't had that conversation before you do anything, you should probably think about that. What you know is it, have you got challenges in cycle time? Is it around quality? Is it around, you know, the business, ultimately, there's an innovation vacuum in your organization. The business can't seem to take advantage of technology. Is it, you know, what is that? And when you come up after that moment of retrospection of or inspection, then I would argue that there's very few ways of delivering value better in a complex environment than something like Scrum. You know, it's funny people like, Oh, we're going to stop doing Scrum. So what are you going to do then? Oh, we're going to, we're going to work in a more traditional way. What? What does that look like? Well, we're going to meet and do some planning. Oh, are you okay? But it's not called Sprint Planning. And we're going to, you're going to review what that that increment of value every we don't call it an increment. So what I worry is we're going to end up sort of replacing the same things with a different set of things, but they're actually exactly the same the end of the day, I think we should do the one thing that's exciting about agile product, operating model and the ideas around it, is that it's let's take advantage of Scrum. Let's take advantage of the ideas of continuous delivery. Let's take advantage of design thinking and lean UX, et cetera, and let's put it to work delivering products. But we've got to decide what those products are, and we've got to decide what value we're trying to get out of them. And that, I think, is the start point, right? And then, yeah, Scrum agile, whatever. Do, whatever you need to do to get to get these products out in an effective way. I would argue with anybody that when they're when they've got their products, that scrum isn't the best way of working for their teams, because I've not seen an alternative that doesn't end up looking incredibly like Scrum,

Patricia Kong: 37:42

beautifully said, I would even take that maybe a step, step further, is that it's really thinking about the interesting problem to solve for the user, customer. And like you said, we've been over arched, maybe not focused on delivering and getting that, getting that to learn something. And I would say that in terms of agile, you were talking about Scrum, but if people don't understand agile leadership, I would argue that they're not great leaders, because that is the style and type of leadership that is sustainable in the future and that will work. So on that note, Dave, do you have some, as we usually ask, do you have some some blogs or some webinars or some talks? Where can people find you? I mean, you

Dave West: 38:27

can always find me. You know, there he is. I'm seem to be on everything all the time at the moment. Obviously, find me on LinkedIn. That's great. Just do the sort of David West scrum.org or Dave West, scrum.org The the so talking about this, I think, is a really interesting topic, definition and and over the next few months, you know, obviously it's the holidays here, so it's going to get in the way a little bit, but we'll be publishing more stuff around it. What I don't have all the answers, but what I do have is the ability to hopefully bring together lots of incredibly smart ideas that often already there in the in the broad world, and hopefully bring them in a way that connects them to to agility and to the Agile product operating model, and to ideas like EBM, etc. So over the next few months, we're going to be continually delivering more and more content around this. So if you're on a product journey, share with us. Tell us how it's going. Tell us what you've learned along the way. Tell us what the challenges are, and hopefully we can galvanize the community to start really talking about this and not arguing about whether it's called a stand up or a daily scrum, which is the silliest thing that we can spend our time doing, because if we can build great products for our users, that. That are valuable for our stakeholders. I think we can change the world, and if we can do it in a more effective way, I think everybody's going to be happier,

Patricia Kong: 40:10

yeah, and I think, I mean, just to plug a little bit we do@scrum.org have a lot of resources that can already support people who are thinking about products and, you know, agile product management, and you'll see that under Resources and for product owners, we have things about product life cycle, financials, how to think about PNL, forecasting, that there's a lot of stuff in there. You just have to take a little journey through the resources on our website. But anyways, thank you everyone for listening. Thank you, Dave, until next time.

Dave West: 40:40

Thanks. Trish, Bye, everybody. You.