Lindsay Velecina: 0:00

Steve, 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.

Dave West: 0:20

Hello and welcome to the scrum.org community podcast. I'm your host, Dave West CEO, here@scrum.org today's podcast, we're going to talk about project to product. And actually, there was a conference that that you may have heard about a few weeks ago in New York City. And I'm very fortunate to have the author of project to product, Dr Mick, Kirsten CTO at Plan View join me today to talk about this conference and to really talk about what he took away and what I took away, share that those insights and see where that goes. So welcome to the podcast. Mick,

Mik Kersten: 0:57

thank you, Dave, great to be here. So glad you could join us at the event as well. And yeah, really enjoyed your talk. So I hope we dig into that some we

Dave West: 1:05

might do. Yes, this is, I think this might be your third podcast with us, so I'm you're an old timer, so I'm excited to have you here. Have you here again. All right, so for the listeners, just a quick recap. Project to product is the idea to really perform in the digital age, you need to look at your capabilities that you deliver to your users in a different way, a product lens, and you need to discard projects as the primary vehicle of doing work the that has a huge impact on your organization. And the purpose of the event was to really talk about that, share learning, share experiences and and and the like, and that, as I said, it was in New York City a few weeks ago. So let's begin at the beginning. What was your biggest takeaway from the from the event? Mick,

Mik Kersten: 1:59

it was actually a bit of a surprise to me. My biggest takeaway, and it was it really came when I realized the nature of some of the presentations, and the fact that the some of the organizations as well, is that we've definitely crossed some kind of threshold in terms of this not being just something for the visionaries, early adopters, but now you've got these very pragmatic organizations. You know, you call them laggards. You can call them pragmatist whatever, whatever the word is, the more conservative organizations who are not necessarily looking for that revolutionary edge over their competition, but are now being told to implement a product operating model and just the way that we saw that framed by some of the very good presentations from the strategic consultancies, McKinsey spoke, Bain spoke, and so on, really helped me realize that. And then also, I think, was a very, very stark realization, realizing these companies actually need a lot more hand holding and guidance than maybe they've been given in the past, and that certainly that they were given in the project the product book. So,

Dave West: 3:02

yeah, I think, I think that that was definitely something I saw as well. Why do you think these organizations are now coming to the realization that agile, DevOps, you know, new technology, isn't enough, and they need some sort of unifying paradigm, or a change to their unifying paradigm of how they invest, align and and think about the work that they're doing. What do you think the Catalyst has been?

Mik Kersten: 3:35

It's a good question, because then just going back to the to the beginning. Dave, I think that same change we thought agile would be that change, right? It's some of the concepts we're talking about around focusing on customer, focusing on outcomes and flow and alignment and mindset, that that was what was being spoken about two decades ago in terms of these, these agile models. And I think part of it is be great to get your thoughts on it as well. Is that that a lot of that kind of played out its course, helped some organizations transform. Certainly helped the way that top performing organizations operate. But I think it was relegated as too much of a change for it, for technology to do right? It was never meant to be that, like we were meant to be agile from a business point of view, company point of view, a customer centric point of view. And so I think what's happened is partly because that hit a ceiling that shouldn't have been there. Those Those Agile transformations. Lots people have agile teams, but but not an agile organization or business. The Product operating model is just that extra layer of the cake that agile should have provided but, but I think, for almost accidental reasons, didn't. So I think we're now at the point where there's enough evidence, and that's actually why it was nice to have McKinsey present some of that evidence, and some of the work that they did, scrum.org has done some great work on this. I plan. Time here we had the project product industry report, but it's all the same thing which, which is it points with various surveys or statistics or data to the fact that organizations with a product operating model, which really is an operating model that supports agile and engineering and and modern ways of working, for for software developers and engineers that those organizations are just that, just vastly outperforming those who haven't. So I think there's now been enough time that leaders Si Boards are saying, No, it's time for you to make a switch. You're the digital transformation as a series of a set of new ceremonies didn't work. It's time to change the operating model, to be agile, and that's the product operating model.

Dave West: 5:46

Yeah, yeah. And I think ultimately digital products are here to stay, right? And digital is a significant component to every business value stream, every business process, every engagement with customers, even if it's just a physical thing, like, I know diapers, you know that there's a, there's a digital element, at the very least in terms of organizations having, you know, supermarkets, having them on the shelves, you know, encouraging them to buy those diapers, rather than somebody else's diapers, integrating with, you know, the coupon in systems and all that kind of stuff. Ultimately, digital is everywhere, though I do I'm not going to be a doom Sayer, because that is not as you well know, my my, my style, however, you know, we heard over and over again, one of the biggest challenges to adopting this, this way of thinking, to transversing the project to product approach, really, is the engagement with the business. And I looked around that room, and yes, there were a few people from business, mostly actually finance, well, enterprise product, project management organizations, which was ironic considering the title of the of the of the group, of the of the event, but the majority of people were still it, people, technology first, people. So I'm a little bit worried that this will just be like agile in regard to it's, oh, well, that's, that's what you software people do, scrums for your software developers and nothing more. Do you think? Did that worry you? Does that worry you or not?

Mik Kersten: 7:38

Absolutely. So I think if we go through you presented some of the evolution, right? There's the agile, there's like this team focused startup things and things start scaling, and then enterprise business agility was meant to have the other people at the table, right, as finance, operations, the executive team, and especially the business and and that didn't quite happen, right? And then I think that's where things went a bit sideways. And if those people are, are not at the table in terms of putting in a new, new operating model, it won't work if the CEO, if the CEO, is not sponsoring it, actually. And this, I guess, was an interesting point on that panel, um, at the end of the event, where I challenge, some people say, like, Will this work? The CEO doesn't sponsor it. Like, because I frankly, there's the anecdotal evidence I've seen. It tends not to, or just doesn't. I should say when there's not, in some cases, of course, it won't be the CEO directly involved, but at least it's sponsored by the CEO, and there's someone on the executive team reporting the CEO, who's directly responsible for the outcomes of putting in place a product operating model. So I think that's the positive thing, is because we're now framing it as a new operating model, I think that's forcing some of the discussion in terms of we actually need the executive team, including the CFO and finance and all those other roles at the table for defining that, understanding how we measure it, understanding that, the roadmap for implementing it, understanding what it changes, right? We no longer maybe need to do software capitalization with timesheets. We're going to do it in a product oriented way, which you know, of course, everyone will rejoice. But you can't do that without involving finance. You can't, you can't make that, that change much as everyone wants to see it happen. The organizations haven't, haven't gotten there yet. So So I think those are also key. And yeah, Dave, that's right. We didn't. There should have been more of them at this event. So I think for all the people who are trying to help with this, I think that the key thing and element factor is bringing in senior leadership to support this change, or we

Dave West: 9:45

accept that the business is never going to properly partner with us, and we just build amazing products. So we sort of assume the knowledge the business. We treat them as stakeholders in the same way as if you're building a firm. Own. You don't get all of your phone users to be part of your organization. You literally treat them as a stakeholder. And you do really good product management, and you do really good stakeholder management, and you do really good and all you need, really is the people that pay for it and the people that tell you which direction. So the mission the executive leadership, but everybody else gets assumed into a product organization. And so that technology kind of eats the, I guess it's sort of taking that well, eats, eats the, what was the New York Times article? Software is going to eat everybody's lunch, right? And, and I guess product could perhaps be part of that. So instead of the business being there as a here, it becomes part of the solution, you know, sort of like, I mean, is, would that be just crazy? Am I just, you know, is it? Yeah, it's

Mik Kersten: 10:57

a really interesting point. So, and I certainly, I know I've heard myself, and I'm talking to, let's say, federal agencies. You gave, kind of the great example, and the slightly scary example of how SpaceX is a product oriented organization and Boeing is not, and the very different outcomes in terms of what's in space right now, what isn't that results from that, and the cost of getting it there the time frames. But that said, when I've been worked and supported those federal agencies, of course, the whole product transformation assumes that the funding model of funding programs that turn the projects won't change. So you still need to innovate within that program umbrella that's got project funding and put in place a highly effective product organization. It's possible, and lots of organizations have done it. So Dave, I guess then I guess it probably is. I think so. I agree, in the sense that organizations whose actual operating model won't change, that's probably the best approach, and just to create within technology with as effective translation layer to how things are funded and and managed and measured on the operation side, to create that product organization and to bring product and engineering and business counterparts together to these value streams and so on, measure outcomes and focus on on those great customer outcomes. So the question then becomes, is, well, what if you've now succeeded at that for the next two years? What are the challenges? And I think some of the challenges, because by the organization not shifting over, will be things like incentive structure, right? People are compensated on going for the biggest budgets, and those budgets are measured, and if the organization's organization structure only considers cost, right? Because if finance is only considering the cost of technology, and that's the only thing is for restructure, not value, not flow, not outcomes, it's just risky, because you'll you have the most senior leaders in the organization having only a view on cost and only viewing everything that's being built as cost centers. You've got these product and technology teams who, of course, want to drive profit and outcomes. And then you've got this mismatch, and that mismatch, I guess, in my experience, it's not as bad when everything is rosy and growing. If their change is being made, it's it's like, for example, if the macro environments challenged, it becomes very problematic, because then you end up, let's say, with organizations doing cuts of the most effective parts of the organization, where they've got the best engineers, because they just don't have a view of value or moving entire teams to different regions, or outsourcing and then having even basically having their economics go completely upside down because they had four times or 10 times the flow on existing nearshore teams or things of that sort I've obviously seen those things play out so and

Dave West: 14:05

actually, and the model that I was sort of prescribing ultimately includes a lot of slack or overhead to enable that sort of duplication of understanding and skill and and all the things around creating a totally separate, self sustained product organization in a business that also is doing that, there's a significant overhead to doing that. So maybe it would be better to get the business at the table and get the business actively involved in this, in this, in this transformation, and that really talks to one of the things that you have said a few times. You said it on the previous podcast around QBRs, and the importance of effectively changing the reporting, the quarterly business reviews, the reporting model, so that product becomes a fundamental part. Of the of the QB, of the QBR process, yeah,

Mik Kersten: 15:05

and Dave, I think it's it is definitely worth just digging into this, I think, a bit further, because a lot of the people who believe a lot of our listeners, either their organizations, either have embraced it at the executive level, or they haven't. And if they haven't, of course, trying to influence, that takes a long time. And so I think we should empower people with changing as much as they can within their within their span of control is key. So you had this on one of your charts. You had this, which to me, was just this really weird split I hadn't seen before, where you had, it's a product model, your strategy, then a product model in the middle, and then a product operating model instead, like was looking as like, why the heck is Dave splitting out a product model and a product operating model? And then, of course, that as another separate part that that's connected is the product portfolio management, understanding that you have a portfolio of products to manage. So I think what's very interesting about that, let's, just take the perspective of an organization whose leadership is stuck. Their eyes are elsewhere, their their, you know, their strategic changes, or other other things, and they're not embracing putting in place a new operating model. I think you're right. I think the the best thing that our listeners can do is actually focus, define your product portfolio management. Define your product model. Start creating your own QBR for that. Start running, start measuring outcomes. And what hopefully happens is that that actually influences because if you invite more and more of the right people, so even though it's not the actual QBR, you're actually running things in an effective way, and hopefully in the process, teaching the organization the elements of a product, operating model and why this is more valuable. And I have Dave, I have seen that work where a portion of the organization starts doing things a new way, and that's how the teaching in the organization happens, not top down, so but again, that it's a path. You need that path to to the, you know, the bigger top down change. You have to get finance involved at some

Dave West: 17:07

point. I know it was funny. I did a webinar today on defining products, and there was a really interesting question. And, you know, where does this change come from? Top down, middle out, bottom up, you know? And, and I had to say exactly what you're saying. It has to be top down. However, if you haven't got that support, then you can build a really quite an interesting approach to managing the work you're doing as a product portfolio and delivering your capabilities to the business and to the organization you serve as products in a different way. However, how they're going to be funding you is still through initiatives and through other other arcane ways, projects, you know, capital expenditure, as opposed to CapEx versus OpEx, etc. And there's going to be some level of translation between that so, so I guess, I guess, I guess you're right. Fake it to you, make it as it were.

Mik Kersten: 18:08

Yeah, I think that's, that's the best shot you've got. And there was a that week I heard it just a fascinating story of chief technology officer who done that, who within a large organization had put in place, reported the CEO had put in place a product operating model with kind of all the right things in terms of planning, road mapping, measuring flow, team structure and culture, all those things. And it was up and running and with but it was without proper sponsorship from finance or the CEO, who were kind of very focused on more of a business transformation around other digital aspects of their business and and what was happening with AI and and it worked. She was able to put in place these highly effective teams. Things were going better. All the metrics were looking good. But then when the organization became challenged in some of the just the pure business model parts of the transformation, it all snapped back. So the CEO basically said, No, every quarter, we're going to define the projects, and then we're going to assign the people, people to the projects, and so very large number of teams, I'm going to review them, and then we'll decide which ones go forward or not. So every quarter like just the worst case scenario, every quarter a reallocation of people. So now, of course, this person is going to go and implement the product operating model elsewhere, because this company has now snapped itself back, and it's going to be more challenged, not less. But I think that the journey will continue. A lot of people learned about that. A lot of people learned that it's a better model. It's a better model. So even though we're seeing this dysfunction that the most senior level of this company, where you've got someone who hasn't sufficiently internalized the benefits, I think that the you know, there'll be some of that DNA there and and then the you know, some of those people will do do great work at other companies that need this. So yeah. But that's the kind of fragility, so where it really that, but that, and that came from a, really a business model change.

Dave West: 20:08

So we, I'm seeing that in across the whole gamut of organizations. I'm seeing, you know, even famous organizations like like Spotify. Recently, I was listening to a podcast, and they were talking about how they're increasing team size, moving autonomy up the hierarchy, and the reason primarily to do that is because they have decided they're not in that massive innovation phase. They've decided that risk is more important than reward, which is bizarre, but anyway, I guess that. And ultimately, they they have felt that they're that for many reasons. They've decided that that their product can't deal with the continuous sort of ebb and flow of innovation across the grounds of it, and instead, they want to manage that and control it and and to some extent, it's about trust as people left, and there's, you know, you don't know the teams as well. You've got your organization's grown to a certain side. You've got quarterly, you know, earnings calls that you need to deliver on. So they're going to a very similar, slightly different, but dissimilar in terms of motivation model. We're seeing that everywhere and and it's really interesting, because that's the other thing that's that I heard a lot about, that everybody's looking for that free lunch and the project model gives you a false sense of security around, you know, getting a nice, shiny feature, you fund it. It's a bit like Shark Tank. You then next month, next quarter, you fund something else. It gives you that sort of like, oh, well, you know, we've, we've, we're managing risk, but we're using this funding model where you only ever give a certain amount. But unfortunately, what that ends up doing is creating, and I heard this a few times at the event technical debt, which then when we try to implement a product model, where that technical debt becomes more transparent and visible as we're trying to integrate a business strategy and a technical strategy. We call that a product strategy, by the way, that integration, that integrated story, and suddenly you're seeing the platform can't sustain the level of change necessary to deliver on the business objectives because of the technical debt that's been accumulated with the years of projects that that that ultimately ends up, you know, sort of undermining your ability to move to a product model, because you know that they liked that they're like, well, they like that false security that projects give you and and the fact that you can say, no, let's not deal with that. Let's just focus on these, these projects and get these new features, on these new capabilities out to market. Did you hear the technical debt thing as much as I did? Yes,

Mik Kersten: 23:04

absolutely. And that's, that's once again, you know? And I think you and I have been hearing that for a very long time, but it's interesting that that is getting more prominent. It's good to hear. I hear it more prominently in the business context as well. Is, is it's been, now at, I think, a decade, of people trying to elevate the technical debt and, and I think it's, it's closely related to what you're talking about, right? The the challenge with the project operating model is the false sense of security, so it's or control, right? Is that you can better control things, but you're overly centralizing. And, you know, it's, it's not to get to just to sidetrack, but centralization works for totalitarian regimes. It doesn't work if you want to empower a whole bunch of a very large organization with some independence of action and decision making. So it completely that that. So it's not necessarily a false sense of control, just a very ineffective sense of control, unless you're dealing with a very simple problem, and it just doesn't scale. And it's, you know, the challenge with technical debt, and is that, if it's not, and this is just one aspect of it, if, if we don't, if you don't expose the economics around you know this, this algorithm, of course, back to product development flow from Don reinerson, but if you don't understand the economics of building software at a business level, you'll make a bunch of very bad decisions. And we're continuing to see companies make those, those bad decisions, because, of course, again, they're viewing things through a blend of projects and control, rather than exposing those dynamics of flow and seeing technical technical that think a lot of that just goes back to the training and education and experience that that oftentimes highly effective business leaders have had around economies of scale. And economies of scale are not the same as these. Economics of flow, that that every every agile team understands where if you get, if you try to overload every single team, you'll get less great product, not more. So I think we're kind of still at that same point. But I think the very, the very positive thing is, for those organizations looking at changing the basic deploying a product operating model. Those things are coming to the surface, these notions of technical debt and of empowerment, of road maps, of decentralization, all those sorts of things, and of cascading outcomes and and all of that the but I do think it's a very good point, as I think we all kind of and I think that was the great thing about the summit, is there's a lot of shared vision on needing to get there. It's a question of how your organization gets there, and if your organization is not ready for a product operating model, putting in place that product model, and managing and reporting on the portfolio of products is, is the best next step? Yeah,

Dave West: 26:01

yeah, definitely the best next step. And the other, obviously, the power of a product paradigm is that you get to contextualize technical debt in terms of its economic impact on the on the things that you're you're delivering, and you get with flow metrics, a way to visualize it. That is, that is awful. I mean, no, is empowering, I should say. But usually it's just awful. You know, cost of change increasing over time. You know, the obviously quality is another, is another factor as well. So it was interesting, though, because I didn't think we'd be talking about technical debt, and obviously it's something that I spent a lot of time talking about when I was when I was a wee lad, and haven't really spoken as much about it over the last five, six years. Now, maybe that's that's worryingly, because people have been so concentrated on these feature factory Scrum teams, and they haven't been thinking about products effectively and value and a holistic view, holistic view of value. They've been concentrate on delivering features in the most effective way possible. That maybe that's the reason, which is, which is really worrying, that I missed that. But it was, it was good to it was good to, good to hear that. The other thing that I heard as well over and over again is there's nothing that technically, that can stop a project to product transformation. It's really just a huge people power, position, status, authority. It's a massive change management problem, not a technology problem, ignoring technical debt for a second in terms of its impact on, oh, my God, we can't actually deliver anything. But it's, really is a change management or people problem, which shouldn't come as a surprise to me, but I guess it's interesting to hear a very different group of people talk about change management than normally talk about change management. Not the consultants, obviously, they do that all the time, but the companies that are in the room, where, how do you manage this continuously? How do you you have to use an agile, incremental approach, you have to obviously raise the the things like flow metrics up to that sort of change level to allow them to influence organizational change, incentive structures, etc. I thought that was really quite interesting as well. The sort of like the role of change management, is that something that you're seeing and that you heard at the event?

Mik Kersten: 28:46

Yes, definitely. And I think, to your point, I think all the technology pieces are there, organizations can already do this effectively. I do think there's this disparity between organizations who have the right kind of visibility and the ones who don't right. We solve for right. We saw from Vanguard, for example, the fact that they show they measured it. Was thrilled to see that they were using plan view vis for this. They measured flow and whip, and showed that the higher whip slow delivery. And created this thing that was my my car, the CTO of Vanguard, who showed this, this ideation cliff, where all this work was happening in ideation, but there wasn't capacity to deliver on it. Of course, even determining what the technical feasibility of some of the work was taking the capacity of the team. So there's just this mismatch that they were then able to address because they had the right visibility. So I think it is important that organizations understand this is something they need to invest in. They can't just invest in. Let's setting up their Scrum teams and then basically not having infrastructure for making that sure that the right work is getting to those teams. So you can keep blaming yourself. Dave, not gonna. I think that Scrum is is in a lot of organizations, has created this feature, factory teams, but I don't think that's where the problem is. The problem truly is upstream of the teams. And if you don't actually look across teams and see, okay, what work are we giving them, they already know which technical debt work they need to do. They know it better than anybody. If not listening to those teams, understanding how much of their capacity, every single increment should go to reducing technical debt, then again, we're missing the picture of not seeing in the back to that Vanguard example, how we're actually overloading the teams, and if we stop overloading them, what the economic benefit of that is, or what, as you said earlier, what the economic impact of reducing tech debt is so so I think all of the pieces are there, and it really is, again, back around, which is why, last time we chatted, I harped on, this is embracing that kind of visibility as part of your elevator as high as possible. So say to the quarterly business review processes so that it's not ignored. And that's, I think, a pattern I've seen in organizations who are doing well in adopting a product operating model, is that they elevate these concepts to their business counterparts as much as possible, as part of their budgeting and strategic planning process as well.

Dave West: 31:18

Yeah, it was, it was just funny, because obviously, you, I don't know how many years ago your book came out, five, six years ago. Six, yeah, six years ago. So I remember that cross country flight where I reviewed it, and invested a significant amount of effort into that review, just just reminding you of that, you know, and and I remember thinking, it's interesting, you know, that obviously the emphasis on flow metrics, the emphasis on on that sort of those, the examples like BMW etc, and the bank and, and it was just so funny that, as I was sitting in the room in New York City that had no windows, so I couldn't look Out of them, had to concentrate on the content, the that it was just like hearing it again, almost the importance of that visibility, the importance of that that the you know, that continuous change management process, the the importance of empowering managers and leaders throughout the organization to take those metrics and actually be able to use them to drive change. And then the Vanguard example is also interesting, because it was also the scope of where they applied. The metrics was much broader than perhaps most IT organizations would would have, would have applied so they because that cliff would have been a complete mystery to most. I mean, you know, they'd have just gone, well, why are we not getting the stuff we want? Well, let's do more. Come on. It must be a throughput issue. Let's increase the whip. And that would have been the exact opposite thing to actually be successful.

Mik Kersten: 32:53

Well, that's exactly it. And that's the challenge where, if all that's being measured and all that the light is shining on is the capacity of the of the Scrum teams, again, you could not have done what they did right. And notice that the problem is actually upstream of those teams. So, but then Dave, how? So, yes, it is a that you can we can frame that out as a change management how, what? What do you think we do? Like, why is for those organizations that are stuck? How do we kind of catalyze the change management that's needed? Because the data is there, the technologies are there. It's kind of all there. So I think kind of back to your point, is this now just a change management

Dave West: 33:33

exercise? Well, I think there's, I think there's three things that's that that stand out for me. Number one, I think that the people that are now in the executive positions that are driving these organizations to the future, they may not be digital native, but they that their children certainly are, you know, whereas you know they we were dealing with leaders that were three degrees away from digital natives and the like. And I do see a change. I do see, even if you know they're bankers or they're consuming packaged goods, people or whatever, I see that that willingness to embrace technology in terms of a business driver and enable that, as opposed to treating it completely separately. I think that will have a change and will have an impact. And I know that's got, you know, it's like, what do they say about science, right? Science progresses One funeral at a time. But obviously, I'm not being quite as negative as that, but certainly in terms of the these leader roles, I think that will have an impact. I think, number two, I think it was really refreshing to see some of the big consulting companies talking a very similar talk that you put in your book, and I've been writing about a lot recently, and it's really exciting because they do have the ears of those boards and and they do. Have the access that, honestly, as much as you know, two good looking, bold gentlemen like us have fabulous access, we don't have that access, and I think that's going to have a huge impact. And I think the you know, and the third thing is the the the delivery capability and the technology, you know, things like DevOps, things like, you know, things like this and the like, having all those things in place, even if they're perhaps working as a feature factory will then instantly be catalog, you know, will be a great catalyst once those leaders and that McKinsey kind of consultant or Bain or BCG or Accenture, or wherever they are, drive the change. It will be like a floodgate opening. And so I think the capability, you know, the fact that we have so many Scrum teams, and even though they aren't necessarily practicing scrummers, I would love it, they at least understand. If you give them product goal, you give them a backlog, you give them a good Scrum Master, you give them a good product owner, they can deliver stuff. So if you point it in the right direction with those other changes, I think so so. So I'm actually pretty optimistic that we've got now everything in place to drive the transformation that you so eloquently described in the book six years ago.

Mik Kersten: 36:30

That's great to hear Dave. And I think, yeah, I think you're right. I think I am. I am we are seeing, the data showing as well that more organizations are embracing this. And I think you there's a one of the points you made there, I think, is definitely worth reflecting on, which is that a lot of these organizations have undergone already their the cloud transformation shift to whatever architectural shift to microservices, but basically they've got the wiring in place for for delivering quickly. And this was actually part of the Vanguard story, right? This done public cloud, microservices, agile, and then they realized their constraint really was at that operating model level and and that ideation clip and these sorts of things, but it was all all anecdotal. So I think the very positive things is because of their agile practices, because of these new engineering practices, whether it's cloud or platform engineering or wherever the organization's on their journey, the infrastructure is in place, and now the bottleneck is actually shifting the organization model, and that's becoming more visible because the teams are saying, Oh, no, we're already delivering quickly. No, we already are able to deploy multiple times a day. So and that that to your point, that was much less the case 510,

Dave West: 37:41

years ago? Yeah, yeah. I mean it. The problem we saw over and over again was, you know, over and over again was, you know, definition of done, the ability to release the the technical constraints were ultimately undermining the ability to deliver. And I have to say that things like copilot are only going to accelerate the team's ability to deliver amazing stuff and also deal with some of the staffing crisis that agile brings on where you need cross functional teams with all the skills you actually don't so much now, or you won't so much. You know, your data scientist for an end develop you'll just be able to take advantage of llms and things like Copilot to help you do that. So, so I'm pretty I left New York City with a feeling of optimism, but a feeling of there's still a lot to do. You know, I think getting the business at events like that, and when I say business, I probably mean operational business. I probably mean the people that are aren't necessarily, you know, brokers or if you're in finance, or people working in the in the branches or on the call centers, but the people that are operating those systems and processes, getting them to sort of take more of an active role in the transformation. I think that that's something I felt responsible for. How do we do that? You know, how do I how do we start building that up? But in general, I felt incredibly positive about the opportunity that that lays ahead?

Mik Kersten: 39:22

Yeah, I, I did as well. And it was not only because we had a chance to debrief about the event over a drink that was really nice, but, but what happened was, I, you know, I came up with my five anti patterns of a product transformation. So I was, as I was going into the event, I was looking at, you know, why isn't this working faster? Why? Why can't these organizations get out of their own way? And then, like you, I think, came up with a very positive view of the progress that's being made. So yes, yes,

Dave West: 39:51

you did. Kicked off the event with a little bit of a negative sort of position. And I was like, oh, hopefully we'll get and then it just got better and better. I particularly. I really liked what Vanguard had to say. I liked there was, there was a lot of really good people talking about their journeys and being very, very open and honest about the challenges and and some really good solutions. So, so I thank you for inviting me to the event and hosting that event. I thought it was awesome. Hopefully we'll do another one next year. And for our listeners, watch out. We'll, you know when it comes, we'll, we'll obviously make sure the or wherever, maybe you can join in this, this, this journey that we're all on. So we have to, I could talk all day with you, Mick, as we have done in the past, usually over a bottle of red wine. Unfortunately, we can't we have other things to do, and our listeners have much more important things to do, probably. So thank you for spending the time, and thank you for sharing your thoughts on project to product the event in New York City, and obviously your thoughts on the whole change that you're seeing with your customers and the market in general.

Mik Kersten: 41:10

My pleasure, Dave, thanks for having me. Always great to chat with you

Dave West: 41:14

and listeners. Thank you for listening today's scrum.org community podcast. I was here with Dr Mick, Kirsten CTO of plan view, talking about project to product. I'm I have a feeling that he'll be on this podcast a few more times over the next year. I got some hard questions that are bubbling in the back of my mind that I'm just going to get ready to to hit him with later in the next 12 months. So thank you for listening to us today. If you liked what you heard, please subscribe, share with friends, and, of course, come back and listen to some more. I'm lucky enough to have a variety of guests talking about everything in the areas, professional Scrum, product thinking, and, of course, agile. Thanks, everybody. Scrum on. You.