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.

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, it's actually going to be focused on answering some questions that came out of a recent webinar. The webinar was around the Agile product operating model and in particular, product portfolio management. How do you manage your portfolio? Products? A big topic, so big, I've enlisted two people to help me with answering these questions that came out the webinar. I'm very lucky to have Yuval you. PST, the reason why I'm excited to have Evan Yuval here. He's an expert in the field. Obviously, we all know Yuval, but he's really good at blending that safe, lean portfolio management Kanban and professional Scrum, which ultimately, I think is the future of portfolio management, maybe of a little bit design thinking and OKRs thrown in for good measure. So I'm really grateful for Yuval being here. And then we have Daryl Fernandez, who's action executive advisor to scrum.org but we're kind of leveraging his old experience. He's the ex CIO and delivery lead for two organizations applying product thinking to their portfolio, Tia and fidelity. The reason why it's great to have Daryl is he's done this in large, complicated, successful organizations, so he's got the battle scars to prove it. Darryl Yuval, welcome to the podcast. Hey, Dave, great. Great to have you. And we've got a load of questions. I don't think we're going to have time, so this might so this might be a two parter. Listeners. Gosh, control yourself. That's really exciting, but we've got some great questions. So let's, let's jump in. Let's start with principles and get it started. There was a lot of questions in the chat and posted in the Q A thing around principles and getting started. Where do you start? Really, was a question that came over and over again. You know, we talked about this process, and I don't, I didn't mean to invent a process, but this, this sort of, how do you fund teams or products. So there was that very distinct process, looking at risk, looking at value, looking at where products were, with their their life cycle, so funding. And then there was this managing cross product initiatives. And it they were, they though they were related. They were distinctly separate. And we got a lot of people saying, My organization is doing none of this. Where do we start? Now, I know Yuval, you're kind of involved in this with a client at the moment. So where do you start? Where did you start with flow?

Yuval Yeret: 3:16

And it relates to the fact that the principles here are the same principles that we apply elsewhere. I think you said turtles all the way. It's it's flow, it's empiricism, it's evidence based, and it's especially at the portfolio level, what I find is it's hard to turn around. You know, this sort of aircraft carrier, you need a dream tab. Flow is that sort of dream tab, that thing that is not that hard to set up, you know, a portfolio Kanban board to look at. You know, what are you managing? Could be too many things could be the way you're currently funding them. Could be things that just focus on specific areas. Could be things that cut across whatever it is. Start to see the mess, start to see the swamp, maybe it is a river already. And then from there, you can start to think about how to improve, whether that's, you know, managing the amount of work in process and hopefully reducing it, whether it's recognizing that you're actually involved in too many things, you're managing too many things, and it might make sense to create, empower teams that can actually run those things, and you just want to fund them, you know, give them a mission, give them a Goal, outcome oriented goal, and let them run ideally, you know, around products, that's where product thinking can help designing your product strategy, and over time, maybe bring in evidence based management and empiricism. What I see in my work with clients that's one of the hardest pieces. Uh, to bring in to convince both leaders and teams to work on so we typically don't, don't start with that, and we don't apply it all across the board. It might make sense to choose a specific strategic initiative that you identify as high risk, high uncertainty and high opportunity, and play with evidence based management and leading indicators over there.

Dave West: 5:24

So the most important thing is visualize it, make it transparent. Understand how many initiatives are in play, understand the impact those initiatives are having on those product teams. Hopefully understand the flow of work across that portfolio, and then sort of use that as an opportunity to reduce WIP, increase value, focus on outcomes, and sort of incrementally move towards something that's a little bit more product centric, more empowered, more outcome oriented, would that sort of summarize what you just said? Yuval, awesome. Gosh, that was that was a mouthful, excellent. Now, Darryl, sorry, I just wanted

Darrell Fernandes: 6:11

to key off one thing that Yuval said, because I think a lot of this has to do with scope of influence. Has to do with where the organization is in their readiness, who's taking on the risk of trying to drive some change here, and those are important variables to consider. And depending on where you are in that the point that you've all made about a single initiative might be a good place to start, whether that single initiative is has a couple products and critical, but not visible, if you will not strategically visible, or whether it's super important to the organization has multiple products, picking one and really testing how this can work, how the approach can fit within the ethos of the organization, and what changes have to happen. Learning through that process, I think, is a really important step. Doing portfolio management on a product oriented organization can get overwhelming if you do too much, too fast, just like anything, if you put too much whip out there, you can get overwhelmed by it, and by starting with a single initiative, by trying things, by learning on a on a manageable scale. I think there's a lot of value in that. Because you want this to be successful, you want to drive this change. Because all the reasons evolved and you said, Dave, it brings transparency, it brings clarity, it brings focus, it brings energy to the outcomes that you're driving. It's also important, and being able to get really good at it as you scale it, I think, is tremendously valuable.

Dave West: 7:49

So just another important point, though, that sort of builds off what both of you were saying is the importance of quarterly business reviews, or quarterly reviews, at least at the minimum, because if you are going to slowly adopt this, and you are going to inspect and adapt, if you are really going to be agile at the portfolio level, you need to have a mechanism that reviews and can potentially make changes at that level. So putting that in place can be incredibly important. Do you Do you agree that, and it's often missed. It's kind of missing. It kind of isn't. Obviously, all big organizations have regular cadences where they where they evaluate investments. However, what tends what I see is it tends to after that initial ridiculous planning exercise happens, it then breaks down into each functional area or whatever, and they review and, you know, like the portfolio managers or the project managers do something, and then the business does something, and then the teams do something, and then the technology people do something, and they don't bring that all together holistically to get that enterprise flow, or Kanban that you're that you're describing your Val Do you think that's also important as you get started? Yes.

Yuval Yeret: 9:05

I also see another siloed behavior, but not, not necessarily across functions. One other pattern I see is the organization has some sort of phase Gate process, former formal process for how they manage initiatives, but they manage each initiative in a silo. So they have a conversation around, should we do this initiative? Should we invest in it? And they decide to invest, but they don't look at the big picture of how the teams are currently flooded with other stuff that they're working on, and can we actually do this? They, you know, they use push mode to drive things into the organization rather than creating pool. And that's one of the key things that, you know, starting to see the the big picture, starting to manage using a kanban system is helpful. The other thing I wanted to. To share is, I've been working on providing some guidance to portfolio leadership teams that are considering this. To answer the question, how do we get started? And it's tempting to provide a roadmap, right? We have a conversation, how do we provide a methodology? And you'll probably appreciate this. Daryl. The current metaphor that I'm using is a trail map or plan the piste, right? Because, depending on where you are in the journey and what's the context, what's the problem, what's your readiness, how are your knees you might want to start with, you know, a green slope of starting a Kanban board and seeing some stuff you might want to try a blue of trying a specific initiative. Or you might, you know, go into the double black diamond of evidence based management across the entire organization switching to product oriented teams from day one. Your mileage may vary, depending on your context and readiness.

Unknown: 11:12

I think it's a absolutely critical that you have that conscious approach Yuval that you just laid out. I think it's really important that you go through that thoughtful process of, what are we ready for? Where are we on this journey, and where can we be successful, and how big a risk do we need to take? What is the marketplace conditions? What is our business condition? Where do we need to go? But to your point, Dave, that regular cadence of reviews quarterly, I think is a great place to start, because you're thinking about these things holistically, not just in a change mode, but also in a run mode. All kinds of things happen in the industry on a regular basis, and those things aren't planable, right? A release may come out that you may have to absorb from a security batch perspective, different things happen. You've got to understand how that is all affecting all of the initiatives that may or may not be hitting a product team, because, because those things, if it's a security patch, candidly, may be more important than some of the business initiatives that you have from a risk management perspective, and having those reviews, the transparency is there to look In, but to have those reviews, to give the platform for those those teams, to to outline what's happening at their level and how it may impact the overall portfolio and the cross, cross product dependencies, I think, is absolutely, absolutely critical for the organization.

Dave West: 12:39

It is interesting. You bring that up because organizations are very ill equipped to deal with change at this magnitude on a frequent basis. You know, the we teach, I mean, you teach it actually, Yuval Darrell and I just, you know, sort of Potter around mentioning it, but you actually teach this about you teach about empiricism and the importance of inspection and adaption through transparency and the fact that you know some of best, best laid plans, best laid assumptions, are actually, you know, missing. You deliver something like, Oh, that wasn't quite what I expected. Now you scale that across initiatives. So, you know, you put, I don't know, 20% of all your money into, I don't know, some personal banking initiative. You realize that actually, you know, crypto is the way to go, which you know many of us might now be thinking about, and you're like, Oh, that's not what I expected now, and having an organization that can absorb that level of change in priority is the it's the Holy Grail when it comes to the pursuit that we're on. I mean, it's this that is business agility, that is ultimately what we would all love to be on. But it's hard to build that resilience into the organization to facilitate that. What so how do you balance that kind of level of need with the ultimate sort of constraints that an organization has? I know, Daryl, you did this for a living, for a while.

Darrell Fernandes: 14:18

Yeah. I think when you look at macro at that level. Dave, there's so many forces that are coming and to evolve earlier. Point about stage gates and about processes, there is some level of insulation that the organization has built to to help adapt in those ways. Because it's, it's when you, when you're at scale, doing these kind of changes, it's, it's overwhelmingly disruptive when one of those things hits you, because everybody wants to adapt, everybody wants to adjust, everybody wants to take on the new thing. But if you have a well constructed portfolio. You understand your capabilities, your products, you can actually be more precise about where the change needs to happen. So I'll just reflect We, obviously, we went through COVID Like everyone else did. A lot of regulations changed real time COVID, and you could spend a lot of energy trying to re orient the entire organization to every one of those reg changes. But because we had some semblance of a product model, because we understood where we could most efficiently and effectively drive the change, we could isolate the impact of pretty macro changes in regulatory environment to the places that it needed to be and adapt and pivot where we needed to without having to disrupt the entire portfolio. There's plenty of that going on anyway, but, but you can, you can use this as an insulation from some of that and really get focused. And I think one of the things that the the combination of portfolio management and product management does is it allows you to be really clear about who needs to absorb what and who doesn't, and then you can, with that transparency, figure out what the dependency implications are, figure out what the workload implications are, et cetera. But I think this model does allow you to be more nimble when it comes to those things. That's my experience.

Yuval Yeret: 16:24

So there are two threads that I'm thinking of pulling here. So one is that the model allows you to be nimble, but it's up to you to reconfigure your organization to actually be nimble. The fact that you have a portfolio management approach doesn't mean you're nimble, because if your teams, if your groups, aren't organized around products, each change is gonna hate. A lot of them, or a lot of the changes are going to hit a lot of them. One of the important things I find is to use the flow purpose perspective to see that, and not just add more and more coordination mechanisms and more comprehensive portfolio management practices. But to descale to say, Okay, we've noticed there's a type of thing that constantly hits three groups, four products. Are they really products? If that's happening this, you know, crypto thing that keeps hitting these four products in our world? Does it make sense for us at this point to organize a product around crypto so that we can let that area focus on it work on a mission, on bringing us to the age of crypto. That's a portfolio management decision to reconfigure, to reorganize around products. If you don't do that, I think you're missing the point on being a product oriented portfolio management approach. For me, that's the essence of it. Another essence is, if you talk about, what does it mean to be an agile portfolio management approach and that resilience, it's both the ability to change where you're heading, and that's coming from limiting the amount of work in process and providing more intake opportunities. And not just plan the entire year, plan more frequently, but an even harder transformation or transition for the organizations I see is, once you start something, once you commit to actually working on an initiative, how often do you look at whether it's tracking towards outcomes? We talk about evidence based management, applying evidence based management for these strategic initiatives. What does that look like? How do we know that our investments in crypto, let's say or Gen AI for improving the developer experience, or for helping our tellers, you know, you know, achieve more in their day. How do we know that it's working effectively, that it's achieving. You know what we intended to achieve there? And do we, are we even open? We talk about the scrum values of openness, it's very hard for portfolio leaders that I've seen to be open to the possibility that we were missing the mark, that we were wrong with our assumption that we need to do crypto. Go tell any sales person that sold. You know, a big deal based on if we have that feature this customer will buy. Go tell them, you know, that there's a chance that the cost. Customer won't buy even if we build that feature and it worked.

Dave West: 20:05

Yes, having been the product manager that was forced to introduce stuff that actually never got product market fit, even after we introduced it, I've definitely felt that that and so you just to pull on that thread for a second, the thing that we tend to fund? Well, one, we need to fund outcomes. Yes, totally. Initiative needs to have a clearly identified objective and a set of results associated with it, whether using OKRs, EBM, whatever. So we get that. And that resonated really well from the webinar. The other thing that was important is that that what's you don't have to discovery is an explicit you need to have discovery and then make a decision. Now that doesn't mean that you can't align to it. It doesn't mean does it, and it certainly doesn't mean that that should be done by a separate team that isn't part of your standard delivery organization, which is often the case in these large organizations, you go off and do a POC proof of concept, separate group of people build up something, prove some assumptions, which basically means aligning to your executive, say the things that they want to hear, and then They give you the money. But you need to basically drive that into those teams in a discovery fashion, and then build that learning outcome out to make the decisions. And I think that that that's hard to do, but I think it's crucial, because otherwise you invest in things that that that ultimately don't give you the value that you seek. I think

Yuval Yeret: 21:46

I want to be careful with how we talk about funding. I think a key role of the I Agree, a key role of the portfolio is to to manage funding, but we manage that funding in two distinct ways. In in my experience, one is we fund products, and we empower teams, products, managers, owners that own that product, to go, achieve a mission. To go, achieve a strategic goal. We fund an outcome that we trust them to go and deliver. And they'll do discovery, they'll do delivery, whatever. There's a certain transparency we want to that from the portfolio level, but we we're not going to manage that hands on. Yeah, there are some initiatives, typically those that are cutting across that are the most strategic, biggest opportunity, biggest risk, biggest interest for the portfolio, leadership team, whatever. Hopefully that's 20% of our funding or or of the work, not more than that. But it depends, and for those we want to to to introduce and use that discovery process that you're talking about more explicitly, those would be the initiative that we will manage on the portfolio Kanban board, for example. And on that Kanban board, yes, there should be some discovery phase that gives us an opportunity to after we decided we want to invest a little bit a seed round, if you want to call it that, for that initiative, see that we want to invest more the whether that work is done by the same teams or other teams, you know, is a Separate concern. In my experience, I like the fact that the same teams do the discovery for the work, but I don't want to prescribe it necessarily. There are very good reasons to work that way. But, you know, that's a prescription that's not necessarily part of, you know, educational principles and practices.

Dave West: 24:03

Yeah, I don't know. I don't want to spend too much on this, but my experience is when discovery is done outside of the delivery organization, not only do you only consider you don't have a big enough understanding of the risks and challenges to delivering that capability into the thing that we already have in in market. But also there's a certain level of ownership that is missed, which then requires significant amount of work to gain that you know, engineers in particular, and obviously my experience is software products, right? Are very good at saying, well, that's a really good idea, but it wouldn't work here that and, yeah, but I don't want I agree that I'm not sure it should be prescribed however there, if there is a cost, if you don't, and I think that's what I meant, the one

Yuval Yeret: 24:54

thing I'll let's emphasize one thing, the discovery should be. Focused on the main risk with the initiative that we're considering. Yeah, main risk is visibility. It should be, you know, a technical discovery. It should be a technical proof of concept. The engineers should be involved. But a lot of the time, especially these days, the main risks are desirability and viability will will the customers come? Is it something people really want, really need? Are we thinking about the right user experience? And there's this anti pattern of we focus too much on this solution, way too early that we need to we need to help organization around we need to think about the problem, market feed the before we dive into the solution. And

Dave West: 25:54

perhaps I've just been badly burnt though my other learning is that if we teach delivery organizations how to separate those concerns in a more effective way, teach them how to do real discovery, then you get that. You get the benefit, obviously, in all situations, not just the ones you think are discovery situations, because then suddenly they challenge every assumption in a way that is a lot more effective anyway. I didn't, I don't want to get too bogged down in that area. I think, I think there's a lot of opportunity to improve how we do discovery across organizations, and when it starts, and how much it costs and you know, and how you make it transparent, which is that what I do, though, want to a couple of things. There's gone. There's so many things. One thing is about you said, Let's not plan everything for a year, for two years, for three years up front, and accept that we're gonna I think that's what you said. Yuval Darryl, obviously you worked for large organizations that wanted some level of stability in terms of the time frame. So it's impossible to be prescriptive here, however intent wise, what should the cadence be? Even for a large organization of their portfolio planning. We talked I talked about QBRs quarterly reviews. I talked about annual planning cycles in the in the webinar, was that too naive? Should I have made that more precise what? There was a number of questions about that.

Darrell Fernandes: 27:36

Yeah, I think it comes down to confidence levels. Dave, so where we tried to get in multiple organizations was a place where we were managing a rolling 18 month calendar of investments, and the next six month view was more confident than the following six months, which was more confident than the following six months. So do you need an annual planning cycle so you can look at your annual financials as an organization, your annual budgets? Yes, you do that, right? But, but that doesn't have to be a ceremony, a one off ceremony. If you have a rolling 18 month planning cycle, you just take if, if your fiscal year is January to December. You take your whether you're doing it every six months or every quarter, hopefully every quarter, you take your Q for 18 month planning cycle. You look at the the next window of time. You can, you can define and you can, you can summarize your basic annual plan based on what's already in motion, and if something new comes up that you want to do in that following year, that's your opportunity to question what, what trade offs are you willing to make in order to make that happen, whether it's discovery, whether it's execution, but if you have that rolling 18 months, it no longer becomes a a one off ceremony. It becomes the way you run your business, which is the ideal that we were always working toward, towards. I can't say that in any instance, we got all the way to that, but we did reach levels of maturity where we were just continually looking 18 months out, understanding that the fiscal year snapshot was just a picture of the next 12 month cycle and the 18 month planning cycle, and we had a degree of confidence and a degree of commitment to what was going to happen in that 12 month cycle.

Yuval Yeret: 29:36

I listened to Daryl, and what I'm hearing is a product owner. I mean, we're talking about portfolio management here, but essentially, what we're talking about is, you know what we've been talking about in scrum all along. We are planning every sprint. But that doesn't mean we don't look into the product backlog. That doesn't mean we don't have. The roadmap. The Roadmap should provide some balance of predictability and flexibility, depending on how important these two aspects are to us in general, I would say when we're looking at a product oriented portfolio, we should bring with us everything that we know from team level Scrum, from team level agility, it's a lot of the same practices apply. Most of the same practices apply. Flow applies. Of course, we have two audiences. What I see is two audiences that tackle portfolio level agility. One is people that have been doing it in the trenches and are daunted by working with the portfolio level. What they should be maybe daunted by is, you know, working with like, you know, leaders at that level with concerns at that level, they shouldn't be daunted by the practices that we use. They should leverage the practices that they've learned and mastered over the years. The other audience is portfolio level leaders, whether it's pMOS, product people at the portfolio level, product leaders, CIOs, that don't have that expertise in agility, what we need is, you know, to use the language. What I found useful is to use the language from team level agility and work with these people. And the advantage is, once you manage to get that language across, the power of actually enabling agility elsewhere in the organization is multiplied. You start to have people at the right level of the organization talking about focus and flow and steering using evidence and discovery, and suddenly all of the practices that the teams in the trenches are using start to make more sense, and you have people that are actually on board for helping these teams work in a product oriented fashion, because they know the language.

Dave West: 32:19

And the other thing that you end up doing is removing all that translation that reforming i I've worked with a number of organizations where basically Scrum Masters and product owners and delivery leaders spend a lot of time reframing the Work into a different context for the purposes of red, green, orange, Amber, and these corporate dashboards that that that make a lot of sense if it's about out, if it's about work, you know, sort of like outputs delivering to plans, but make very little sense when you're actually trying to determine the value that each product's providing, there is a question that I did see over and over again, which was really the We the idea of value. So you've got a portfolio of many different products in it, and each of those products potentially is valuable in a different way to the organization. You know, Daryl, I know that used to manage things in the data space. Now, let's be honest, selling, selling a financial product much easier to work out value than providing a data service to multiple financial products. So you don't get sued by the by some sort of government entity because you're misrepresenting the data in different contexts, or the European Union comes in and gdprg to death, or whatever, hard though to articulate value in a consistent way to determine investment. So how do you get that consistent definition of value across the portfolio. Is it even possible? I think,

Darrell Fernandes: 34:03

I think Dave, the way I would look at that is your value is different, right? A website or a web page has a different way to articulate value to the business. It's in operational cost, transaction cost, customer engagement, those kind of things ultimately leading to business value, right? ROI of of the page is there, but it's through different metrics that you get there, right? Customer Data is about operational efficiency. In some cases. How can we maximize and not have redundant storage, not have redundant databases, not having redundant capabilities. So there's an operational efficiency, there's a risk management piece of that that comes together. But again, there's a there's a customer satisfaction that if the name, if a customer corrects their name, they do it once, and it cascades to every place in the organization. Because you manage your data well, so there are similarities, but I wouldn't want, I never was able to get to a place, and I'm not sure it would be worth the effort to get to a consistent definition of value across every product in the portfolio. When you get to the initiative level, the OKRs for the initiative should be able to cascade down into what each of the product teams drive through their value statements. I've never had a challenge where that couldn't be aligned. But it isn't a little bit of an alignment exercise there that you have to look at the portfolio, at the products, and what drives value for those products, especially when you get into new areas where you're experimenting with new products, because you're still trying to figure out and work out what the what the market value is for you've done the research, you've done the discovery, but you're still trying to figure out for you, how do you scale to get to that value? What does that look like? Where are the barriers?

Dave West: 35:58

Yuval, what do you say you I mean, you're working with a client that has many different levels of value, some of it very external, dollars and cents, some of it more internal, operational efficiency, you know, risk, etc.

Yuval Yeret: 36:16

Well, operational efficiency has dollars associated to it, I mean, eventually allows you to start trading in more countries without growing your support team, or some other things you could do if you improve your operational efficiencies. But what I'm seeing work, work well is similar to what Darrell is describing. You align on what are your strategic goals? What are you focused on as an enterprise, as a portfolio? In the case that we're talking about, it's multiple portfolios, but they're aligned to one set of enterprise strategies. Hopefully that's a consistent, small set that allows you to make value trade offs throughout the enterprise, not something where everything you know could map into in which case everything is valuable and that's not valuable. Once you have that, I agree with Daryl, you can start to ask yourself for each one of those product groups, what could it do to help our strategy? How important is this to supporting our strategy? And that should help you decide how to fund it for the next year, or how to think about it and for each one of those cross product initiatives, again, you should be able to talk about, how does this relate or align to what's strategic for us? Another technique is, you know, to use cost of delay. Reinerts talks about, you know, whatever it is that you're doing, if you're working at the portfolio level, bring the finance people into the room that they will help you figure out, you know, the numbers. They can turn a lot of stuff into numbers if you talk to them, we're afraid of talking to them a lot of the time, but bring them into the conversation, and there's a lot that you can actually do, cost of delay for and bring things to the to the same playing field, and if you cannot, if you are, I don't know, for example, Microsoft and you're trying to compare the value of, you know, a new feature for Xbox Live versus some new gen AI initiative. First of all, you know, you could probably get it to dollars, but another indication is that they're not the same portfolio. If the conversation is so disparate, so disjointed, maybe it doesn't make sense for this to be a portfolio. A portfolio should have a business model that makes sense for it. There should be an economic framework that's driving that portfolio, that the different products in some way fit into that model

Dave West: 39:16

that's kind of deep. There was, I'm reminded of a University I studied a something called cybernetics, which had a this guy called Stafford beer, who built economic models and then used computers, and he ended up running a small country in or helping run a small country in South America, which then had a revolution, and his models were blown up. But, but what was interesting is trying to define value, and Mars is a really interesting organization, because what they're doing is they're building something called it's, it's, it's basically a balanced scorecard for for investments that is much broader than just, you know, immediate revenue. It's sort of impact, impact based. And it really interesting. So, gosh, we could talk about value for an entire podcast, if not longer, but it is an interesting idea. The point that you raised, though, I think, is have that conversation, bring in the finance people use techniques to look at it from different perspectives, and then try to find something that balances consistently value across your portfolio. And maybe you have to accept that they're different things and they need to be managed in separate portfolios. You should you know your charitable contributions are different to your capitalist contributions as it were, whatever, which is interesting, hey, oh gosh, we're coming to time, and I need to bring this podcast to a close, at least this first version we I've put my my Kanban board up, and I've discovered, you know, that our flow is quite slow. And out of the seven topics, we managed to get two guns so we have we might want to look at our work in progress and move our flow a little bit better for the next podcast. I really do think there should be a next podcast. Hopefully you two will sign up for that. But I guess if we're going to leave anything from our listeners with in terms of what came out of today's discussion. We talked about getting started, we talked a little bit about value. We talked a little bit about transparency and applying these team level agile concepts to the to the enterprise level, to the portfolio level. Is there anything else that our listeners should take away from this first discussion, I

Yuval Yeret: 41:44

hope they they took the concept of, this is a fractal. The same principles apply. And the concept that it is a trail map we're not going to provide, you know, a detailed process. It's not necessarily, I mean, yeah, you could say it's a framework, but there are multiple things that you can try doing depending on where you are. The most important thing is to start thinking a different way. Start thinking from a product oriented perspective about your portfolio.

Darrell Fernandes: 42:22

I think that's the key Yuval. If you don't start thinking about it, contemplating it this way, looking through the lens from this perspective, you'll never appreciate the value you can get from it. So you have to take that leap and start to explore in order to decide which path is the right path for you.

Dave West: 42:42

And if you don't, this is digital enterprise, a software centric organization that's going to be doing that and building features and capabilities in their products that are going to basically beat you. So if you don't start thinking in this way, I think ultimately, as successful as you are today will ultimately be your ruling in the future. So thank you gentlemen for joining us today. I really, really do appreciate it. So we were here today. Listeners focused on really the Agile product operating model, the product portfolio management element of it, talking about a webinar that was run recently and the questions that came out of it. We talked about getting started. We talked about agility at scale. We talked about the importance of getting leadership to understand that at the portfolio level, and really, then really talked about the importance of value and how you can effectively build that balanced scorecard. Thank you for joining us today. I really appreciate you listening to the scrum.org community podcast. If you liked what you heard, please subscribe, share with friends, and of course, come back a little some more. Maybe this topic will continue. I know we have, gosh, almost five questions still outstanding that we need to address. I'm I'm very lucky that I get an opportunity to talk to a variety of guests. Obviously, today we had Yuval Yvette and Daryl Fernandez talking about portfolio management. But I'm lucky to talk to a variety of guests talking about anything in the areas of professional Scrum, product thinking and, of course, agility. So thanks for listening and Scrum up. You.