Product Portfolio Management Q&A - Part 1

Help me think through how this episode applies to my situation. Start by asking what I am trying to change. Separate the episode's claims from your suggestions, and say when the notes do not support a claim. Use the transcript to find passages, then check the audio before quoting. Transcript: https://yuvalyeret.com/podcast/episodes/product-portfolio-management-qa-part-1/transcript.md ## Published episode notes For this episode, I’m sharing a conversation originally recorded for the Scrum.org Community Podcast. Dave West, Darryl Fernandez, and I discuss the messy realities of product portfolio management. We discuss how most organizations are still managing way too much WIP, why “empowered teams” is more than a buzzword, and what it looks like to bring empiricism and evidence-based management to the portfolio level. Think of this as a trail map, not a recipe. We riff on why portfolio agility is turtles all the way down, how the same principles of flow and transparency that work for teams can (and should) scale up, but only if you’re willing to experiment, visualize the mess, and start small with intent. You’ll hear stories from the trenches, like why starting with a single strategic initiative, instead of a big-bang reorg, can give you the leverage you need to turn the aircraft carrier without capsizing the whole fleet1. 0:00 Introduction to Scaling With Agility 00:23 Welcome and Episode Overview 01:38 Scrum.org Community Podcast Introduction 01:46 Answering Webinar Questions on Agile Product Operating Model 03:25 Principles of Portfolio Management 04:22 Starting with Flow and Evidence-Based Management 08:45 Quarterly Business Reviews and Organizational Readiness 14:39 Balancing Change and Organizational Constraints 32:40 Defining Value Across the Portfolio 39:52 Conclusion and Future Discussions This Q&A About Product Portfolio Management was initially published on the Scrum.org Community Podcast - https://podcasts.scrum.org/872401/episodes/16534612-q-a-about-product-portfolio-management-part-1 The Portfolio Agility Trail Map is available at https://yuvalyeret.com/the-portfolio-agility-trail-map/ To hear more, visit yuvalyeret.substack.com Product Portfolio Management Q&A (Part 1), Where to Start, and How to Think About Value – https://yuvalyeret.com/blog/product-portfolio-management-qa-part-1 ## Transcript This transcript was edited from automatic speech recognition for readability. Speaker turns may be wrong or absent, and it may contain recognition errors. Check the audio before quoting or attributing a passage. Episode: https://yuvalyeret.com/scaling-ai-podcast/product-portfolio-management-qa-part-1/ ## The friction around portfolio and funding The power of enabling agility elsewhere in the organization is multiplied. You start to have people at the right level of the organization talking about focus flow, steering, using evidence and discovery and suddenly all of the practices that the teams in the trenches are using start to make more sense. Welcome to Scaling with Agility. I'm Yvall Yerit and around here, we try to cut through the process theater and get real about what it takes to move the needle on agility, especially its gap. For this episode, I'm sharing a conversation we're regionally recorded for the Scrum.org community podcast, where Dave West, Darryl from Nenders and I dig into the messy realities of product portfolio management. We get into the weeds, how most organizations are still managing way too much working process while in power teams is more than a buzzword in what it actually looks like to bring in your seasonal and evidence-based management to the portfolio level. Think of this as a trail net, not a recipe. We refun light portfolio agility is turtles all the way down, obviously in principles of flow-turns, paronsy that work for teams 10 and sheets scale up, but only if you're willing to experiment, visualize the mess and start small with your tech. You'll hear stories from the trenches, like why starting with a single strategic initiative instead of a big bang reorg can get you the leverage you need to actually turn your aircraft carrier around without capsizing the boat. Alright, let's get into it! Hello and welcome to the Scrum.org Community Podcast. I'm your host Dave West CEO here at Scrum.org today's podcast. actually going to be focused on answering some questions that came out of a recent webinar. The webinar was about 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 of the webinar. I'm very lucky to have Yevaluet, PST. The reason why I'm excited to have Evan Yevalu here, he's an expert in the field, obviously we all know Yevalu, but he's really good at blending that safely in portfolio management, camban and professional scrum, which ultimately I think is the future of portfolio management, maybe with a little bit of design thinking and OKR's thrown in for good measure. So I'm really grateful for Yval being here. And then we have Dao Finandas, who's actually an executive advisor to Scrum.org, but with leveraging his old experience, he's the XCIO and delivery lead. The two organizations applying product thinking to their portfolio, TIA and Fidelity. The reason why it's great to have Darryl is he's done this in large, complicated, successful organizations. So he's got the battle scars to prove it. Darryl, you're welcome to the podcast. They leave. Nice to be here. 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 be a two-parter listeners. Gosh, control yourself. That's really exciting. But we've got some great questions. 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'd you start really was a question that came over and over again. We talked about this process and I didn't mean to invent a process but 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 life cycle. So funding and then there was this managing cross product initiatives. they were related, they were distinctly separate. And we got a lot of people saying, my organization's doing none of this. Where do we start? Now, I know, Yavil, you're involved in this with a client at the moment. So where do you start? Where did you start? We'd flow 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 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 the sort of aircraft carrier, you need a trim tab. Flow is that sort of trim tab, that thing that is not that hard to set up. You know what, Portfolio Conman wore to look at 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 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, mitigating the amount of work in process and hopefully reducing it. Whether it's recognizing that that you're actually involving too many things, or managing too many things, and it quite makes sense to create and power teams that can actually run those things, and you just want to fund them, give them a mission, give them a goal, outcome-oriented goal, and let them run, ideally, or on products. That's where product-seeking can help, designing your product strategy. And over time, maybe bringing evidence-based management and in-parances. what I see in my work with clients, that's one of the hardest pieces to bring in to convince both leaders and teams to work on. So we typically don't start with that and we don't apply it all across the board. In fact, makes a feature with 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. 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 use that as an opportunity to reduce whip, increase value, focus on outcomes, and incrementally move towards something that's a little bit more product centric, more empowered, more outcome oriented. But that sort of summarized what you just said, you've, uh, awesome. Gosh, that was a mouthful. Excellent. Now, Darryl, sorry. What do you think? I just wanted to key off one thing that you've also 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, and that the point that you've all made about a single initiative might be a good place to start, whether that single initiative 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 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 you've all evolved, and you said, David, brings transparency, it brings clarity, it brings focus, it brings energy to the outcomes that you're driving. It's also important in being able to get really good at it, as you scale it I think is tremendously valuable. So just another important point note 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. You agree that, and it's often missing it, isn't? ## What is really happening in the system Obviously, all big organizations have regular cadences where they evaluate investment. However, 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 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 camban that you're describing, you're about. That's also important as you get started. Yes, I also see another siloed behavior but not necessarily across functions. One other pattern I see is the organization has some sort of phase gate process, former a normal 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 we actually use pushlog to drive things into the organization rather than creating pull. And that's one of the key things that starting to see the big picture, starting to manage using a common system is helpful. The other thing I wanted to share, 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? you'll probably appreciate this. They're all the current metaphor that you see Treyomat or a plan the beast, right? Because they got 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 a green slope of starting a convent board and seeing some stuff. you might want to try a blue or trying a specific initiative or you might go into the double black diamond evidence based management across the entire organization switching to product oriented teams from day one. You know, Lylage League are depending on your context and readiness. I think it's a absolutely critical that you have that conscious approach. You've of all 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 think is a great place to start. Because you're thinking about these things holistically, not just in a change mode, but 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 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 teams to outline what's happening at their level and how it may impact the overall portfolio and the cross-product dependencies, I think is absolutely critical for the organization. It is interesting you bring that up because organizations are very ill-equipped to deal with change at this magnitude on a frequent basis. We teach, I mean, you teach at actually a vowel, Darryl and I just potted around mentioning it, but you actually teach the issue of alps. You teach about empiricism and the importance of inspection and adoption from transparency and the fact that some of the best, best laid plans, best laid assumptions are actually missing. You deliver something like, oh, That wasn't quite what I expected. Now, you scale that across initiatives. So you put, I don't know, 20% of all your money into, I don't know, some personal banking initiative. You realize that actually crypto is the way to go, which many of us might now be thinking about, and you're like, oh, that's not what I expected. Now, having an organization that can absorb that level of change in priority is the holy grail when it comes to the pursuit that we're on. 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. So how do you balance that kind of level of need with the ultimate sort of constraints that an organization has? I know, you know, Dao, you did this for a living for a while. Yeah, I think that when you look at macro at that level, Dave, there's so many forces that are coming in to you. You've all earlier pointed about stage gates and about processes. There is some level of insulation that the organization has built to help adapt in those ways because it's when you're at scale doing these kind of changes. 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, obviously, we went to COVID like everyone else did. A lot of regulations changed real time, COVID, and you could spend a lot of energy trying to reorient 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 you can use this as an installation from some of that and really get focused. And I think one of the things that the combination of portfolio management 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. 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 and 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 gonna hate a lot of them. One of the important things I find is to use the flow 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. products. Are they really products if that's happening? This crypto thing that keeps heating these four products in our world, does it make sense for us at this point to organize the product around crypto so that we can let that area focus on it or condemnation 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, if you talk about what does it need to be an agile portfolio management approach and that resilience, it's both the ability to change where you're heading. That's coming from limiting them out of 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 JNI for improving the developer experience or for helping our tellers achieve more in their day? How do we know that it's working effectively, that it's achieving what we intended to achieve there? Are we even open? We talk about the ground values of openness. It's very hard for portfolio leaders that I've seen to be open to the possibility that we're missing the mark, that we were wrong with our assumption that we need to do crypto. Go tell any salesperson that sold a big deal based on if we have that feature this customer will buy. Go tell them that there's a chance that the customer won't buy even if we build that feature in a port. 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. And so you just to pull on that thread for a second, the thing that we tend to fund, one we need to fund outcomes? Yes, totally. An initiative needs to have a clearly identified objective and a set of results associated with it, whether using okay RZBM, whatever. So we get that and that resonated really well from the webinar. The other thing that is important is that what you don't have to discovery is an explicit, you need to have discovery and then make a decision. ## The practical shift Now that doesn't mean that you can't align to it. It doesn't mean, it certainly doesn't mean 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. A 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's hard to do, but I think it's crucial because otherwise you're investing things that ultimately don't give you the value that you seek, I think. I want to be careful with how we talk about funding. I think a key role of the, I agree here all of the portfolio is to manage funding, but we manage that funding in two distinct ways 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. goal we found 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 death from the portfolio level but we're not going to manage that hands on. 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 of the work, not more than that, but it depends. And for those, we want to introduce and use the discovery process that you're talking about more explicitly. Those would be the initiative that we will manage on the portfolio con ln board, for example. the time when word 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 whether that work is done by the same teams or other teams 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 that's a prescription that's not necessarily part of the usual principles and practices. Yeah, I don't know and 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 market, but also there's a certain level of ownership that is missed which then requires significant amount of work to gain. Engineers in particular, and obviously my experience is software products, right? A very good at saying that's a really good idea, but it wouldn't work here. And yeah, but I don't want, I agree, that I'm not sure it should be prescribed, however, if it is a cost, if you don't. And I think that's what I meant by. The one thing I'll, let's emphasize one thing. The discovery should be focused on the main risk with the initiative that we're considering. Main risk is visibility. It should be a technical discovery. It should be a technical proof of concept that engineers should be involved. But a lot of the time, especially these days, the main risks are desirability and viability. Will the customers come? Is it something people really want, really need, are we thinking about the right user experience? There's this anti-pattern of we focus too much on this solution way too early. That we need to help organization around. We need to think about the problem market theme before we dive into the solution. And perhaps I've just been badly burned. Though my other learning is that if we teach the delivery organizations how to separate those concerns in a more effective way, teach them how to do real discovery, then 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 don't want to get too bogged down in that area. 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 how you make it transparent, Which is that what I do though, one to the couple of things is God, 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 upfront and accept that we're gonna, I think that's what you said, you've all drow obviously you worked for large organizations that wanted some level of stability in terms of the timeframe. So it's impossible to be prescriptive here. However, in 10, wise, what should the cadence be, even for a large organization of their portfolio planning? We talked about QBRs, quarterly reviews. I talked about annual planning cycles in the webinar. Was that too naive? Should I have made that more precise? What, there was a number of questions about that. 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 budget? You do that, right? 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 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 next window of time, you can define and 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 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 one-off ceremony, it becomes the way you run your business, which is the ideal that we were always working 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 months. I listened to Darryl in what I'm hearing is a product owner. 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 the product backlog that doesn't mean we don't have a 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 the 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 working with 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, only CIOs. They don't have that expertise in agility. What we need is to use the language, what I've 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 in the trip, people that are actually on board for helping these teams work in the product-oriented fashion because they know the language. And the other thing that you end up doing is removing all that translation, that reforming. 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 make a lot of sense if it's about work, 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 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. Darryl, I know they're used to manage things in the data space. Now, let's be honest, telling 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 some sort of government entity because you're misrepresenting the data in different contexts or the European Union comes in and GDPR, due 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? ## What leaders should pay attention to I think Dave, the way I would look at that is your value is different. A website or a webpage has a different way to articulate value to the business. It's an operational cost, transaction cost, customer engagement, those kinds of things. leading to business value, ROI of the pages 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 comes together. But again, there's a customer satisfaction that if the 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 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 market value is for you've done the 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? You're Val, what do you say? You're working with a client that has many different levels of very external dollars and cents, some of it more internal operational efficiency, risk, et cetera. Operational efficiency has dollars associated to it. That 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 well is similar to what Darryl 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 there are line two, 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 could do not be in which case everything is valuable. That's not valuable. Once you have that, I agree with that. All 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 to use cost of delay. Reinertsen talks about whatever it is that you're doing. If you're working at the portfolio level, bring the finance people into the room. They will help you figure out 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 at 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 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 a new feature for Xbox Live versus some new JNI initiative, first of all, you could probably get it $2, 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. Portfolio should have a business model that makes sense for it. There should be an economic framework that's driving that portfolio that different products in some way fit into that model. That's deep. That's deep. I've reminded of a university. I studied something called Cybernetics, which had a 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 what was interesting is trying to define value. Mars is a really interesting organization because what they're doing is they're building something called it's basically a balanced scorecard for investments that is much broader than just immediate revenue. It's impact based and it really interesting. 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. Maybe you have to accept that they're different things and they need to be managed in separate portfolios. Your charitable contributions are different to your capitalist contributions as it were or whatever, which is interesting. Hey, gosh, we're coming to time and I need to to bring this podcast to a close, at least this first version. We, I've put my cambam board up and I've discovered that the 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 working progress and move us, 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 enterprise level to the portfolio level. Is there anything else that our listeners should take away from this first discussion? I hope 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 gonna provide a detailed process. It's not miss-sell, 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 or into perspective about your portfolio. I think that's the key. You've all 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. And if you don't, this is just your 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 ruin in the future. So thank you, gentlemen, for joining us today. I 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 in 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, 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. ## Source boundary These are the published show notes from the podcast feed. They are a starting point for discussion, not a verbatim record of the conversation. The transcript is machine-generated and may contain errors or unlabeled speakers. Check the audio before quoting anyone.