Q & A on Product Portfolio Management Part 2: Evolving Portfolio Management for Product Success

In part two of this portfolio management Q&A, Dave West, Yuval Yeret, and Darrell Fernandes tackle the complexities of funding products vs. teams, especially in nonprofits. They explore shifting from work-based to product-based funding, managing technical debt vs. product roadmap progress, and aligning business and technology goals. The discussion highlights the role of initiative owners, evidence-based management, and finance partnerships in driving effective portfolio decisions. They also explore the concept of working cross-product. Tune in for insights on creating a more sustainable and impact-driven portfolio strategy. 

Transcript

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 is part two. Gosh, we liked it so much. We've come back for more. So part one and now Part Two was a podcast focused on answering the questions that came out of a recent agile product, operating model, product portfolio management webinar. We got a lot of questions. We started answering them, and we only got, actually, for the first two. So you know, if you're looking at my Kanban board, we didn't get we didn't move many across the board. So we've got some more to talk about today, and just like in part one, I've enlisted two people to help me with answering these questions, Yuval, Yvette, PST, an expert in the field who can blend lean portfolio management Kanban and professional Scrum, sometimes while on a a treadmill, which is very impressive to see. I'm not going to lie there. Welcome to the podcast. Your Val, thank

Yuval Yeret  1:31  
you, Dave, not on a trend. I'm standing on the treadmill. I'm not walking on

Dave West  1:38  
there we go. Which is which is good, which is good. I'm glad you, because you're making me feel really bad. And then we've also very lucky to have dar Fernandez, executive advisor to scrum.org, ex CIO and delivery lead for two very large financial institutions, and he's been applying product thinking in their portfolios, Tia and Fidelity Investments. So we're going to share some of his insights there. Welcome to the podcast, Darryl.

Darrell Fernandes  2:08  
Thank you, Dave. We're looking forward to a conversation

Dave West  2:12  
part two, so we started. So maybe listeners, if you've not listened to part one, you probably should, but that doesn't mean that you can't get stuff out of part two, I'm going to jump straight in to the question that we're that's on next on my list, which is around budgeting and funding. We've got a couple of questions here, but really the first one is, I'm concerned that funding the products versus funding the teams won't work for for nonprofits. And I think the question was, one of the key concepts of the webinar, was, fund the products, not the work, and that, that's a fundamental sort of concept. And this, this question really says, Hey, we're already far too busy. We've already got like 87 initiatives. How the heck can I fund these products? Instead, what I'm doing is I'm funding work and hoping that the products evolve in parallel. So I know you've all you must. You've, you're doing this actually, at the moment with a large organization, there's a lot of things moving. They've, you've got people that are already too, too busy, and suddenly are adding product on top. What would be your words of wisdom on that?

Yuval Yeret  3:36  
I don't know that it's wisdom, but more often than not in the organizations that I work with, the funding model already funds teams. I mean, we say products, and you know, there are differences in how we work in product oriented ways, but funding teams is pretty common now in situations where you fund the teams, it doesn't mean that the teams aren't busy working on too many initiatives. It means you have an issue of juggling too many initiatives that you need to deal with. And you know, the way around that is to start to see the flow and improve the flow. We can talk through that, but it's not a funding concern. It's not that the funding model needs to change. On the other end, in organizations that do have a funding model for initiatives, again, the key challenge that you need to face. There are two challenges. One is, are we willing to change our funding model and fund stable teams and get decouple the funding and budgeting conversations from the team structure in what, what work are we doing? Conversation? Essentially in your annual operating plan, say these are the teams or groups, or if. Portfolios that we have, and this is their operating budget, and it is what it is. And now we're empowering product owners, portfolio owners, whatever level, to do the right thing. The key challenge there is sometimes political, because in organizations where the work is funded based on initiatives. You often have finance people and PMO people that are managing, you know, those investments and are managing to this funding moving to a mode where you find teams, often, is a big change for these people, and you know the feeling that they're losing control, and you need to give them an alternative. Evidence based management is an alternative that can, you know, show them that there's value in the work that is being done. But it is a change. And again, this change is very different than you have lots of things in flight, and you need to focus on fewer people. And that would be a concern regardless.

Dave West  6:05  
Okay, so, gosh, there's two things there. I do want to lean in a bit on this, you know, fund the work thing, because I think that we have, I have some examples of where that isn't the case, and it is a real challenge. But the you sort of dropped a bombshell about pMOS there, Yuval, that I just need to, well, I'm not sure we'll finish it, but bring up. So what you're saying is that pMOS, who historically have managed these complicated I mean, we've all filled in timesheets, you know, which I remember that was my Friday afternoon after the pub, which I'm not sure that was a good thing or a bad thing, but I got through it. But the these people that are in these organizations, in the PMO project offices, etc, are going to have to basic, well, you would encourage them to change what they're focused on, to really coaching and enabling evidence to be the primary mechanism of progress and building, dare I say, dashboards with the teams to demonstrate progress against that evidence. Because that, that's, that's a big change to most pMOS,

Yuval Yeret  7:16  
rather than that. Oh, a bit more than that. Okay, if you're moving to a product oriented portfolio, one of the key things that you're doing is you're saying, If, until now, let's say 80% of my budget was allocated to initiatives, and 20% was business as usual, change management that you trust and empower teams to work on. It's typically what you want to do is not just manage the same initiatives using product orientation. You actually want to push a lot more of the budget into these product teams, product groups, and tell them, here's your budget, here's 50% of the overall budget, whatever the number you need to come up with. What makes sense, but you go manage it. I'm not gonna micromanage you. I'm not gonna tell you how to work on this initiative. There will be fewer initiatives that need management. There would be fewer program managers, you know, that will be busy, busy running initiatives in the organization. There would be more product owners, product managers throughout the organization, that make decisions around what, what features, what you know, investments make sense, what should be in those product backlogs while the funding is stable. That's a meaningful change that. And you know that there's the conversation around moving from program management to value management and being enablers and having a different role in this organization. That's a huge change for for pMOS,

Dave West  9:04  
Daryl, you've been a little quiet, and I apologize for that, as we talked about this, but tell me, you know, in the organizations that you were part of, and you don't have to obviously, share any secrets, but that's the kind of change that you were driving. I mean this value management, rather than portfolio management. This, you know, the ownership your

Darrell Fernandes  9:31  
outcome, yeah, outcome impact driven right? And empower the teams to to get to that outcome. There's balance, right? There's balance in the long term, sustainability of the deliverable versus the short term feature function of the deliverable, but, but the outcome of the impact is really what you're trying to drive towards. In this particular question. It's interesting to me, so I'm going to do a little bit of a pivot, because I see two things in this question that intrigue me a little bit. One is. I see a notion that there's these product teams of one, or these product teams of one or two, and those those individuals are overwhelmed. And I can look back to the Phoenix Project as a great example of flow and flow constriction. And it's it's not in the app dev side, it's more in the dev ops side, but it still talks a lot about the same challenges that you see here when you have app dev product teams of one or two, where you just you can't get all the work through and take taking a step back from that you generally want to build broader. You may only have funding for one or two people, or ability to invest in one or two people in a product, but you need to then join other other products together to create some structure that allows you when priorities drive to go wider than one or two persons of capacity to deliver value, right? So you have to really take a step back and evaluate whether these product teams of one or two are the right thing for your organization in most cases, when we came across those, we took a step back and said, We need to merge some things that our product teams are one or two that have like dev skills or like business partners, etc, to get more capacity and the accountability then becomes a little broader, because you have to balance across multiple outcomes. It's a little harder, but you have that capacity on demand, quote, unquote, when you need it to deliver true business value for a specific reason. So that's one piece, the other piece that's pretty interesting about this question, less about our topic at hand, maybe, but nuanced in the nonprofit piece of this question, which in mission based organizations, priorities are really hard because everything is so important to the mission, and in solving the problems towards the mission is such a almost emotional effort that it becomes hard to prioritize. And so what I read into this question a little bit, and this is me kind of doing way more, way more interrogation than is probably appropriate. Is that this particular organization probably isn't prioritizing, well, right? They want to do everything with a limited set of resources, and there's not clear ways to to balance the most important things with the less important things. Everything's important because it's a mission, right? So, so everything becomes important and that becomes a big challenge. I think the product model and the portfolio management on top of the product model can actually expose that risk and expose that challenge in a different way, and if you use it to your advantage, I think forcing those conversations at the portfolio level, through this vehicle becomes a value add, and I think it can, can drive the prioritization to the right level of the teams necessary to help the people doing the work do the most important work, because it's all important. So I I know that's a little bit of a pivot from the from the program management side of the question, but, but that's kind of where I saw this question going. So

Dave West  13:07  
I mean, running a mission based organization value and impact against that mission can sometimes annoyingly, I have to be honest, brings that up when we have our regular meetings about how I'm running his his business, and the, you know, sort of impact, impact and value, everything that we do has to have any has an economic element, but it also has an impact element, and we have to balance those. But it's about making choices. And choices are really hard to make, particularly as and this is the other thing about mission based that you're not non profit. You know these sort of organizations you you know your stakeholders are in. You really want to satisfy those stakeholders. And changing priorities is as a huge impact, maybe a personal, human impact, which which we don't see so much in a big financial organization, maybe so interesting. So I do want to lead us to another topic around budgeting, though, that is, you know, that sort of CapEx, these timesheets, putting time into the right buckets, you know, making sure you capitalize appropriate investments. I remember when I was my first job, 92 I think it was commercial union, which no longer exists, not, not because of me, just, just for the record, they got merged with another insurance company and then brought into another one and the huge Aviva, amazing organization, actually, big scrum shop anyway, but sorry, but the I remember having to create time sheets on that Friday afternoon, and I remember one of the motivations for doing it, one of the reasons why my boss, Geeta Shah, said that I need. To do it was because of the way in which money was being capitalized, etc. So you had projects, and you had work inside those projects and and all this sort of stuff does. Does that change with the product model? Now you, you know, you, you obviously live this. You worked a lot with finance. Obviously, fidelity is a different perspective than maybe Tia on this. But what happened? How can you do it? You can

Darrell Fernandes  15:26  
do it. It takes work, right? It's not free. Capitalization can't be unwound if you have significant capital portfolio, capitalization happening can't be unwound in a single cycle. It takes. It takes, in cases, years, if you even choose to to lessen your capitalization approach. So you have to find tools that allow you to track the work in a way that that can still be capitalized and still solve that business problem, which your P and L requires, right? If you've got that built into your P and L, you can't ignore it. You have to solve for it. So you've, you can, you can use feature tagging, which is an approach to that. And you can automate feature tagging if, if you're still tracking hours, it becomes easier. Many organizations have walked away from tagging hours and kind of gotten to a model where they do associate allocation of their FTEs, which is a estimation of how much work is happening against features, and those features are then tagged and in a discretionary or a non discretionary bucket. So there are ways to do it, and there are ways to automate a good portion of that and simplify it, but, but it must be done. You can't just turn it off, at least in my experience, because of the financial impacts to turning it off, in a immediate sense, become too big to explain, and so you have to find a way to manage through it. And maybe you choose to through a glide path over years, wind out of your capitalization. Maybe you don't. That's a business decision that's market driven. There's, there's a lot of things outside of product delivery that go into that.

Dave West  17:20  
Yeah, so I mean, and you worked through this with finance, so basically, by involving your CFO, and you know that part of the organization, who actually, from my experience, and maybe you Val, you're going to say, I'm wrong here when, when I asked, comes to you, but my experience is those people really want to help, but they actually don't. They don't want to be a bottleneck, a hurdle, a burden. They actually want to drive good stuff into the processes. Absolutely.

Darrell Fernandes  17:53  
I'm sorry, Yuval, just one thing, and then I'll flip it to you when you talk about this approach, and the fact that it's evidence based, and it brings more transparency than maybe other approaches. They actually really want to jump on board, because they're not used to having that level of exposure and and clarity to what what's actually happening. Yuval, I'll flip it to you. Sorry, yeah,

Yuval Yeret  18:15  
I would agree, in general, but it is you change and finance. People are not the people you know that risk is something that they would like to avoid, even when they're in a business of, you know, helping people manage risk. So what I found is the evolutionary path works like you don't have to change how you do your capitalization and your time sheets on day one of working towards a product oriented portfolio management approach. You, you know, like we do with velocity based on story points versus throughput, don't necessarily throw away your story points on the first day. I mean, I, you know, I'm a content trainer. A lot of PSDs are saying, No, you know, don't do story points, partially because you know what we've brought into the community. But you know, why not use them in parallel for a while and see that it makes sense to, you know, to trust the throughput, and there's no additional value in what you get with the story point. So here as well, do Timesheets in parallel to doing feature tagging or using, you know, new tools that can associate check ins to the code base with JIRA tickets and show you stuff. There's lots of cool stuff that's available these days, but run it in parallel and see that. Then. Evidence that you get makes sense, and over time, maybe you can start to remove those timesheets. That's what I'm seeing most of. To be honest, most of the clients I worked with, it took them years, if at all, to stop doing timesheets as part of this, because it wasn't the biggest fight worth fighting at the time.

Dave West  20:25  
They though I am, I'm afraid, reminded of so I had to basically get 40 hours every Friday afternoon. And I we used to have a, this is England in the 90s. You go to the pub of Friday lunch, and I'd come back and I look at the projects, and there was and I'm like, Oh, where are we against those projects? How much have we spent? And then it doesn't matter what I did that week, I was completely the opposite, really. I mean, yeah, and then yeah, and just tried to, then, oh, and get it to balance. And then if it didn't balance, my bosquito would be like, all over me, and I'm like, I've got, well, I didn't work on that. She's like, Well, can you make it work? But it does take time, and I think the transition and seeing and getting that transparency of the change, I think it's a bit of a theme for the change that we're describing. Try things, see what they go that doesn't mean throw away existing processes overnight, but at least involve people in the change from finance and and all good things can happen. Right? Apply

Yuval Yeret  21:32  
evidence based management. For words, evidence based management. Dave,

Dave West  21:36  
oh my god, it's going to be turtles all the way down now. Yuval, so I'm going to get confused, but yes, it's like, you need to adopt this in an agile way, using evidence to drive change and and that's whether we're talking about portfolio management, whether we're talking about, I don't know, how we manage features, whether we're talking about stakeholder engagement, whether we're talking about organizational constructs, governance, compliance. If you don't use an incremental, evidence based approach to this very complex socio technical system, you're always going to be in in trouble. I mean that that is, that is the reality. And yes, this is just one other thing, all right, so carrying the theme about, um, let's talk a bit, a little bit about the this, this. I that this portfolio strategy, you know, we talked a little bit about, you know, the choices. But ultimately, this particular question is, how does product portfolio, strategy change? If you're in a fast startup Tech with fluid teams, technical debt piling up all over the place, they're doing a lot of support type your teams are now having to do a lot of support type activities. You know, would you focus on stabilizing. The question was, would you focus on stabilizing the product, mitigating that, technical debt, managing that? Would you focus on, you know, just keeping the systems going? I actually had a very similar choice to make when, when I came in as a CPO of task we had, you know, we were bootstraps, so we're having to pay people, you know, surprisingly, on the revenues from the products. And I had a bunch of customers that we'd sold a story to that maybe our products didn't quite live up to and I but I also had a product roadmap that that we were using to drive investment, talking to VCs, etc, and I wanted to demonstrate progress against this roadmap. Whilst trying to it was really we were transitioning from a service based company to a product based company. And it was, it was only because of the inspirational leadership of Mick Kirsten and neelan and and some others that provided me the air cover that allowed me to to do that, because we made the choice that ultimately the long term value of the business was going to be search, as a product company and as a services company. Yeah, we might be able to build up. So this is business for a bit, but that isn't the long term strategic value of the business. So, so I've lived through this, what would you say? You know, I don't know who wants to you know, you've allowed you when you're in this situation where you've got a product, you've got teams aligned, you've got a road map, you've got stakeholders, and you you've got support the operational element. What you do.

Yuval Yeret  24:41  
So we need to remember that we're talking about portfolio, product oriented portfolio management here. But the answer to the product level is both, you know, turtles all the way. It's what we use to make. Distinctions. And the other piece of this is we want, in the portfolio level to create an environment where products are empowered to make decisions. So if I was in the position of being a portfolio leader, first of all, what I need to understand is, okay, what is my situation and what do I want my strategy to be? And I don't know what's the right balance between eliminating technical debt and keeping current customers happy and working towards future horizons, but I need to come up with one. I need to see transparently what's the current level of investment and set guardrails for where do I want to be now those guardrails, I don't want to be managing them on a day to day basis. What I want is to communicate them to the different products, so that product managers, product owners, owning those products with their teams, can make decisions day to day in a way that is aligned to the strategy around, how do we want to allocate our capacity around these, these different concerns? That is a portfolio management construct? How do we provide strategic intent around types of investments? And not just what is the strategy, what are the goals, but also types of investments, but creating autonomy that is aligned to those investments and

Dave West  26:31  
supporting the challenge, you know, that my team had, particularly as they you know, I initially, I had one scrum team. Let's not, let's not be grandiose here. And that scrum team was very much. They had very strong relationships with those clients, because they'd sold the product back in the day before I joined, actually, and it was really hard to go and say, Look, you're going to have to say no. In fact, you're not going to have to say no, is what we ended up I'm going to have to say no. So you give them to me as the product owner of that product, and I'm going to have to talk to them. And that took a bit of time. Guard rails, we exactly had those, and we put those in very quickly. We had a CEO with Mick Kirsten, who loved measuring things, so everything was in this really comprehensive So, and when we slipped on those guard rails, we had conversations about it, and we did slip, but we made choices. You know, making payroll was one choice we often had to make. And the, you know, it was, it was interesting. So guardrails and empowering make, you know, getting that product owner to make those decisions was, was crucial. Daryl, have you been in a similar situation with some of your products?

Darrell Fernandes  27:54  
Absolutely. And I think, you know, on the portfolio, we talked earlier about impact, right? And what's the impact, what's the outcome? And so when we talk about empowerment, well, empowerment comes with an accountability, right? You have to You're accountable for something, and you're empowered to find the best way to deliver that. And what we see here is a little bit of not being able to define the impact of solving for some of these technical legacy challenges, therefore, we can't seem to find the time to go work on them, at least, that's how I read the question. So, so I think you you have to really look at what, what impact am I as the leader or the portfolio level, looking for, how can I measure that, and how can I then value that as it relates to because paying, paying, you know, payroll this month versus payroll for the next six months are two different questions, right? And you probably have to solve for both, yes, how do you balance the ability to hit payroll this month but not create a situation where you've, you've done so much debt delivery that you can't pay payroll in six months. You have to really look at that. You have to understand what's happening. I, you know, I look at, and you've all talked about turtling up here, I look at flow, right? What is your balance that's driving your flow? And if you have too much technical debt, it's absolutely going to impact your velocity. So how do you balance the both at the product and at the portfolio level, the management and, in some cases, a little bit of extra debts? Okay, because the the revenue side of the house isn't counting on that particular piece of the portfolio to drive new over the next three quarters, whatever the case may be, and you can manage that differently than the place where getting to market quickly is absolutely critical, and you have to take a different look at your debt in that piece of the portfolio. I'll give you part for the example, account opening, right account opening is fairly ubiquitous now it's fairly. Absolutely standardized. But if you want to launch a new product that's got nuance to it, you may not use a central capability to drive account opening. You may make a choice from a technical debt perspective, to create a net new experience to drive that account opening, to get to market faster, to evolve faster, to learn about what works and what doesn't work for a customer with the intent over time, once you're in market, of reverting back to the mean, of getting back onto a standard capability set for account opening, but you have to make those choices and create technical debt at times in order to go as fast as the market demands. I

Dave West  30:41  
think, from my experience, the most important thing was to have that conversation in a very transparent way, absolutely and that was now I was blessed, because I was surrounded by people that got it really quickly and just knew we were talking the same language from day one. That's the reason why I joined and that really helped, but we had to make some hard choices, and I'm reminded of recently, there's a an organization called Sonos in the US that provides wireless speakers that ultimately hadn't managed their portfolio correctly in terms of those guardrails that Yuval described and their technical debt had gone out of control, and then they added a new product to the platform. They're using a platform model, and it broke and it stopped working. And I personally lost two speakers. They fell off my system. I have no idea why I was I was trying to logicalize how, because I bought many of them at the same time, so there wasn't that anyway, but they just fell off. And actually still today, one of them I can't get back on because of that, and it has stopped me from buying any future Sonos products, which is, which is interesting, and I'm sure they're an amazing organization, and there are, they are on the road to recovery, but it's those choices, having it transparent, and it's, it's hard, and you have to get everybody on the same page. Really, really interesting choices.

Yuval Yeret  32:13  
Yuval, yeah, you know, maybe last quick note about this, I agree, the most important thing and what the power of portfolio level management is the conversations are happening at the right level. They're happening not just at the one product level, but across products. But if those conversations are not conversations that enable trade offs, if what you're doing is, you heard we need to have goals. And what you do is everybody gets goals. You Dave get goals, and Daryl, you get goals, and you get a goal, and you need a goal, and everybody gets multiple goals. Then goals are not helping you. It doesn't help to say we need to reduce technical debt. While we, you know, create this new capability, while we do that other thing, while we launch the new platform, you need to do it in a way that forces

Dave West  33:10  
trade offs, that makes those conversation something

Yuval Yeret  33:13  
over something else, like working software over something. It doesn't mean we won't do any of the other thing, but it's a choice.

Dave West  33:25  
But that initiative that in, yeah, so that imagine there's an initiative associated with technical debt, because the you know that from the flow metrics, the company has seen that it's getting harder and harder to add new capabilities. They're having more defects, etc, becomes an initiative. It you've got a choice. Then you either stop, and I had this actual choice, actually at task top. And I remember the the conversation, this was later on in the journey, when we decided to build what we called factory, because, you know, we're an integration hub. And you can imagine that every time somebody released a new API to their product, JIRA or ServiceNow everything broke, and so we built so I so I'd got this evolved debt around the connectors, we called them, that I couldn't manage effectively. And we had this conversation. We had to make a choice, you know, to do we stop moving. It was exactly right. It This wasn't about status reporting. This wasn't about saying red, green, blue. This was, this was or yellow, or whatever it is. Sorry. This was about actually saying, Okay, we either bring in some more people to help, which we didn't have the budget to do. Or we do. We start, we slow down on our roadmap, delivery, and we keep a couple of customers. Luckily, one of them is dar or so he was fine, but we don't necessarily service them quite as well as. As we, as we historically have, and we had to make those choices and for six months. And what was even worse, you that is we made that choice and then sit, you know, with a six month sort of time frame, and then, guess what, after three months, we realized it was probably nine months and and that was, that was, luckily, it was luckily, it was over the summer and everybody was on vacation, so that we ignored, yeah, so we slipped it in there. But it was, yeah, it was, it was, it was exactly what you said, making those trade offs. It's not about status reporting, it's not about communication. It's about decision making.

Yuval Yeret  35:37  
One of the things I find really powerful is taking your goals and putting them on a Kanban board. For me, that's like the essence, what's the smallest, lightest thing to do at the portfolio level, take your goals, put them on a Kanban board. Visualize. How many of those goals do we have? OKRs, wildly important goals, rocks, whatever initiatives, epics, call them, whatever you want to call them. But how many of those do we have? Is it realistic if a new goal comes up, don't say immediately, yes, we have to go and do you know Gen AI, everybody's doing Gen AI. We have to integrate Gen AI into our organization. Okay, what's going to be the impact of that versus the other things that are currently in flight? Do we want to switch over to that or to stop, starting, start, finishing?

Dave West  36:38  
Yeah, and that means making choices. And choices are hard, and organizations, from my experience, the larger the organization, the less willing, really, they are at making choices. I hate to say that, but it seems to be what I see. They fill up their boards and they fill up their initiatives, and they fill up this stuff. And then they, instead of saying, Well, hang on a minute, we've got a business that we don't know what's going to be in three months, so we should leave some capacity, some slack in the system, and they don't do that. And because everybody's, you know, everybody's got a mission, everybody's got a goal. I mean, who doesn't want to go. All right, so we're coming up to time, but I do have one last question that is around roles and responsibilities. My gosh, we've managed to fly through this Kanban board of questions we're doing. This has been a good one. Today I see practice second time is always a charm, right? It's well, one question is, what does cross product mean? Very simple question, what does it mean to you? I know what I meant when I presented it. I mean an initiative that has that impacts multiple products in terms of their functionality or capability. That's what I think cross product means, or a very annoyed product, which is a different kind of cross I guess the next question, sorry, Yuval, I

Yuval Yeret  38:04  
have a caveat on that. Oh, it's an initiative that significantly, meaningfully impacts multiple products. If I'm working on something and I need Daryl to, you know, do a day of work to help me finish my work or deploy it. That's not cross product in the portfolio sense. Yes, so we need to be careful not to manage all of the organization's work at the portfolio level. That's why I'm saying that we need to minimize the amount of things that we manage as cross products and maximize the amount of work we empower product teams to manage exactly

Dave West  38:47  
and in in the case of Yuval asking Daryl to, you know, do a small, minor thing so it make his life so much more easy, or delivery thing, then that has just been managed in the backlog like any other stakeholder that comes and knocks at darryl's door, cross product initiatives are ones where there's the Yuval would have a wheelbarrow of requests to Daryl and vice versa, maybe, which starts adding to the complexity of the situation. Thank you for calling that out. Yuval, I think that is really, really, really important. And honestly, it isn't a scientific sort of measure, cross product or not. Cross product, you know, is it 700 requests? Is it four? 300 is it 12? You know, I don't know. I think you know when you know, though, and and I think it, you know, I think it's sort of clear. So thanks for for making that clearer for our listeners. The other thing was interesting is, in the presentation, I introduced a bit like the way in which lean portfolio management, they do this idea of a initiative owner or an epic owner, or whatever, somebody that owns. These cross product initiatives. And the words of advice for want to a better term I provided for that was, you know, that they need to have a regular cadence. They need to have, you know, transparent artifacts, maybe a backlog, maybe a Kanban board, maybe blah, blah, blah, and they have an initiative owner. And there was a question about, what's the conflict between product owners, initiative owners. So I know Darryl you, you were in financial services, where there were these big initiatives, you know, whether it's moved to cloud, whether it's GDPR, whether it's some new socks compliance, that is, isn't about socks, it's about something else. But anyway, everyone's got to wear green socks from now on that, you know, how did you balance ownership and empowerment at the team level with these very powerful senior people that came around and goes, I need to have this. The company will fail without it. I think

Darrell Fernandes  40:58  
there's different types of initiative owners, and you, you hit on a couple there. Dave, right? So let's, let's talk about cloud migrations. So, so the first conversation is, why are you doing a cloud migration? You're doing a cloud migration for the capacity that it can provide you. From an elasticity perspective. Are you doing? You know? Why? Why are you doing? Are you doing it for cost containment, because it's it's off prem, and you can manage it better all those questions, right? And if it's those kind of risks that you're managing or impacts that you're managing, you can take something like Cloud migrations. It's still an initiative, but empower the product teams differently than if you're launching a new financial product which requires an account opening and account reconciliation, trading capabilities, which are all separate products to come together to offer a new financial product. Right? So there's different kinds of initiatives, and I think you have to be clear, when you ask somebody to own an initiative, what are the what's their role in driving the impact, and what tools do they have to drive that impact? And then the product teams need to understand what their role is in the in the initiative. So if I'm an account opening product owner, and I'm being asked to contribute, to participate with, collaborate with a new financial product, then I then I need to understand how that objective is going to be fulfilled through my organization, and how we're going to measure it, and how it's going to fit with my other priorities, and have those conversations, because I think that those are the real challenging initiatives. Is more the business initiatives than the pure tech initiatives in my in my mind, because the prioritization at the product level becomes the challenge, right? Because if a product has multiple priorities coming from multiple initiatives, and this is what Yuval, I think, was trying to avoid, which is only use the initiative construct when you absolutely have to big enough to to use it, the prioritization becomes, becomes where the rubber meets the road, and having that portfolio level conversation about the the choices that have to be made at each product level in order to make the initiative happen, and make sure the initiative owner is kind of aware of that, because sometimes the initiative owner may be taking direction from one side of the house and the product owner direction from another side of the house. You really need to reconcile that. You need to have a vehicle to reconcile that. Go ahead, Yuval, I see

Dave West  43:35  
Yuval.

Yuval Yeret  43:38  
I think you're making an important assumption there all that the product owners are product owners. A lot of organizations that I see at the point that they're starting their portfolio journey, you know, their product owners are not really the Empowered product owners that we talk about, and it's a slippery slope. To the point where we think the initiative owners, you know, tell product owners what they need, and it happens. I think you described the right dream scenario, that the right environment which we need to work towards. That's exactly what a product oriented portfolio looks like, where we carved out products that have real owners, real empowerment, and those initiative owners learn to act like product owners. We talk about product owners as influencers, as you know, experimenters, they do need to make some decisions, but they make decisions about their initiative. They cannot make decisions about other products. They need to influence the people in the products. That is a dynamic that is alien, foreign and. Lot of the people though to a lot of the portfolios, but I think it starts with at least acknowledging that the initiative owner comes from the product owner family. An initiative owner in your portfolio should be one of your best product owners or product managers. They should be an expert in product ownership. Be very careful with, you know, because it's at that scale thinking about it's not somebody from the product world, it's somebody from the project world. That's an anti pattern that that I often see,

Dave West  45:41  
yeah, I mean, and then that makes sense, because, oh, you got this big initiative. It's cross product. It's a, you know, business, it's high profile. You got your product teams running. And of course, the natural assumption would be to get a really good project manager that to get it, because there's, you know, it's, it's ultimately about coordination, isn't it? Well, actually, it's not. It's about influencing. It's about building a roadmap. It's about making trade offs. It's about compromise. It's about, you know, and yes, there is some element of scheduling and the like, but it's not that isn't the focus, and I think that that is a key skill set that's often missing in these initiatives. The other thing, I think is really important is there isn't many of them. I think that the, you know, the majority of the work needs to be being done by the product teams based on their product roadmaps. And the not everything is an initiative just because it affects multiple products, which is the point I think you raised earlier, and I think that's crucial and and ultimately, we want to empower the product owners. So give them the guard rails, give them the the the this is what we believe at this point, you know, and then allow them to be transparently communicating that to the people that ultimately own the products. And you know, one thing that I've seen a lot is that you've got different reporting structures for different products, meaning that the and that can cause a lot of conflict as well. So, you know, the technology product teams, or, you know, their product owners report into the CIO, CTO, whatever, and then you've got the business product people reporting into the business lines, which ultimately means, makes it very hard when you've got, you know, escalation issues, because that you've got two because the technology leader has a different set of goals than the business leader. And then then there's this game of, you know, and is it going to go away up to, you know, the CEO, and if it's a big financial company that I'm not sure that makes sense. So it just goes around in circles. Let me just jump

Darrell Fernandes  47:50  
in real quick, Yuval, and then I'll jump, throw it to you. But I think that opens a whole nother conversation. Dave, about aligned incentives, and regardless of organization structure, are people working towards the same outcomes, right? And if they're not, what steps can you take to to make that happen more? Because as long as people are working to different incentives, you're you're going to have that challenge. And the more aligned you can make, regardless of organization structure, the outcomes driving the incentive model, the better off you are in this product centric portfolio, product portfolio centric model. So I think that's a whole nother conversation. We didn't have a question about it, but I think it's an important one to note. Yvon,

Yuval Yeret  48:36  
yeah, another rabbit hole that relates to that. You know, this is just coming off the of the back end of a conversation I'm having with a real client right now. What's the scope of their portfolio? Is it developing technology products, or is it a business portfolio? And I'll just quickly raise the question and the impact of it, and maybe we can discuss it in part three, if we ever do it is, if your portfolio, as it often is, is an IT technology portfolio, what might happen is, or what has a good chance of happening, is that when initiatives come at your doorstep, it looks like the classic demand intake process where you're told this is what we need to do to achieve a business goal that we've already decided we need To achieve. And you don't have optionality. If you really want to be a product oriented portfolio and have optionality and focus on impact and outcomes, it actually leads you to the fact that you needed to be a business and technology partnership, not an us and them, where. Where you know, technology and business are involved from day one of thinking about something in the funnel and deciding, do we want to invest now in going to cloud, or in reducing technical debt, or in Gen AI, or in going into this weird crypto thing, or whatever it is, all of those are business decisions that need product support, and you need to make these decisions as a portfolio. That's a much harder change for some organizations. You don't necessarily need to start with that, but you need to acknowledge it until you're at that level, it would be hard for you to be really product oriented and impact oriented.

Dave West  50:50  
I think that you know the reality is that most organizations are still on their legacy. Organizations are on their journey from Business and Technology, separate to business technology, and I think that productization can be a really good tool as a catalyst for driving that transition. However, if, if productization is thought of as something the IT organization does on its own, then, yeah, you can build some great technical products, and that can be, you know, and, but then it's a very different set of goals, and ultimately leads you to these challenges, of these, you know, ownership battles, which, which makes not good for anybody, right? We've come up to our time, gentlemen, thank you so much for spending I could. I just learned so much when I have these conversations. I really do appreciate you taking the time and listeners. Thank you for listening. Today, I was with your value at PST, expert in the field on lean portfolio management, Kanban and professional Scrum, talking about portfolio management. Portfolio Management. And Daryl Fernandez, executive advisor to scrum.org, and ex CIO and delivery lead. We've been talking about portfolio management today. We've been talking about the questions that came out of the webinar. We walked through budgeting and funding, operational, strategic investments, you know, capex, OPEX, we talked about strategy and the challenges of that. We talked about roles, accountabilities and empowerment, all of them, you know, come to a head at that portfolio level. Thank you for listening today to the scrum.org, community podcast. 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 air is professional Scrum Product thinking. And, of course, agile. Thanks, everybody. Scrummorg,