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

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/q-a-on-product-portfolio-management-part-2-evolving-portfolio-management-for-product-success/transcript.md ## Published episode notes Navigating Agile Portfolios: Funding Products, Making Trade-offs, and Aligning Teams This is part two of my conversation with Dave West and Darryl Fernandez from the Scrum.org Community Podcast. If part one was about seeing the portfolio mess, this one’s about wrestling with it: funding models that don’t quite fit, PMOs caught between old habits and new expectations, and the perennial challenge of making real trade-offs instead of just handing out more goals like party favors. We dig into why “fund the product, not the work” sounds great until you’re staring at 87 initiatives and a nonprofit board that thinks everything is top priority. We talk about how shifting from initiative-based funding to stable teams is less about spreadsheets and more about giving real ownership, and how that shift can get political, fast. You’ll hear stories from the trenches, like how time sheets and CapEx accounting become the last hill to die on, and why running old and new models in parallel is sometimes the only sane way through. We also get into the weeds on cross-product initiatives, initiative owners vs. product owners, and why the only thing harder than aligning incentives is getting people to actually make choices. If you’re looking for a playbook, you won’t find it here. But if you want to hear how leaders are actually navigating the mess, balancing flow, evidence, and the human side of change, you’re in the right place. 00:00 Introduction to Goal Setting Challenges 00:43 Welcome to Scaling With Agility 02:27 Introduction to the Podcast and Guests 04:31 Diving into Budgeting and Funding Models 05:49 Challenges with Funding Models and Team Structures 07:24 Political and Organizational Changes in Funding 13:37 Prioritization in Mission-Based Organizations 16:20 Capitalization and Financial Management 23:39 Adopting Evidence-Based Management 24:35 Product Portfolio Strategy in Startups 27:56 Aligning Product Decisions with Strategy 29:22 Implementing Guardrails and Empowerment 30:29 Balancing Technical Debt and Market Demands 32:48 The Importance of Transparent Conversations 39:47 Managing Cross-Product Initiatives 45:44 Empowering Product Owners and Initiative Owners 50:00 Aligning Business and Technology Goals 53:48 Conclusion and Key Takeaways This episode was initially published on the Scrum.org Community Podcast https://podcasts.scrum.org/872401/episodes/16698612-q-a-on-product-portfolio-management-part-2-evolving-portfolio-management-for-product-success To hear more, visit yuvalyeret.substack.com Product Portfolio Management Q&A (Part 2): Funding Models, PMOs, and Making Real Trade-Offs – https://yuvalyeret.com/blog/product-portfolio-management-qa-part-2 ## 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/q-a-on-product-portfolio-management-part-2-evolving-portfolio-management-for-product-success/ ## The friction around portfolio and funding 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. I did a goal. And everybody gets multiple goals, then goals are not helping you. What's the smallest thing to do at the portfolio level? Take your goals. put them on a conman board. Visualize how many of those goals do we have? OKRs, widely important goals, rocks, whatever. How many of those do we have? Welcome back to Scaling with Agility. I'm Yvall Yerit and today we're sharing part with my conversations with Dave West and Darryl Fernandez from the Sprounter Community Podcast. If part 1 was about seeing the portfolio mess, this one is about wrestling with it. Funding models, they don't quite fit, PMOs, top-between old habits and new expectations, and the perennial challenge of making real trade-offs instead of just ending up more goals like part-of-things. We dig into why Fund The Product Not The Work sounds great until you're staring at 87 initiatives and onboard the things everything will stop priority. We talk about how shifting from initiative-based funding to stable teams is less about spreadsheets and more about giving real ownership. And how that shift can get political fast. You'll hear stories from the trenches like how time sheets and capital expenses accounting become the last hill to die on. We also get into the weeds on cross-product initiatives, initiative owners, services product owners, and why the only thing harder than aligning incentives is getting people to actually make choices. If you're looking for a playbook, I'm afraid you won't find it here. But if you want to hear how leaders are actually navigating the mass balancing flow, evidence and the human side of change, you're in the right place. As always, think of this as a trail map, not a recipe. Let's get into the episode. Hello, welcome to the Scrum.org Community Podcast. I'm your host, Dave West CEO here at Scrum.org. 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 Canban board, 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 advance in these questions. Yaval Yvette, PST, an expert in the field who can blend lean portfolio management, and ban, and professional scrums sometimes while on a treadmill, which is very impressive to see. I'm not going to lie there. Welcome to the podcast, Yivelle. Thank you, Dave. Not on the treadmill. I'm standing on the treadmill. I'm not walking on the treadmill. There we go, which is good, which is good. I'm glad you're making me feel really bad. And then we're also very lucky to have Dauphin Andes, executive advisor to Scrum.org, XCIO 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. Thank you, Dave. We're looking forward to a conversation. Part two. So we started. So maybe listeners, if you've not listened to part one, 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's 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 nonprofits. And I think the question was one of the key concepts of the webinar was fund the products, not the work. And that's a fundamental sort of concept. And 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, 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're doing this actually at the moment with a large organization. There's a lot of things moving. They'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? 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 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 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, organizations that do have a funding model for initiatives, again, the key challenges you need to face, there are two challenges. One is, are we willing to change our funding model and fund stable teams and get the couple, the funding and budgeting conversations from the team structure and what what work are we doing in conversation? Essentially in your annual operating plan, say, these are the teams or groups or even 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 that based on initiatives, you often have finance people and PMO people that are managing 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 the feeling that they're losing control and you need to give them an alternative. Evidence-based management is an alternative that can 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. Okay, so I gosh, there's two things there. I do want to lean in a bit on this, you know, from the work thing because I think we have to make examples of where that isn't the case and it is a real challenge. But you sort of drop to bombshell about PMOs there, you've held it. 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 time sheets, you know, which I remember that was my Friday afternoon after the pub, which I'm not I'm not sure that was a good thing or a bad thing, but I got through it. But these people that are in these organizations in the PMO, project offices, et cetera, are gonna 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, though I say, dashboards with the teams to demonstrate progress against that evidence. Because that's a big change to most PMOs, right? It's more than that. Oh, a bit more than that. 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 going to micromanage you. I'm not going to tell you how to work on these initiatives. There will be fewer initiatives that need management. There would be fewer program managers that will be busy running initiatives in the organization. There would be more product owners, product managers, without the organization that make decisions around what features, what investments make sense, what should be in those product backlogs while the funding is stable. That's a meaningful change. 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 PMLs Darryl, 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 ownership outcome you would put your own system. Yeah, how come an impact driven, right? And empower the teams to get to that outcome move balance, right? There's balance in the long-term sustainability of the deliverable versus the short-term feature function of the deliverable, but the outcome and the impact is really what you're trying to drive towards. In this particular question, it's interesting to me. So I'm gonna do a little bit of a pivot because I see two things in this question that intrigued 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 individuals are overwhelmed. And I can look back to the Phoenix project as a great example of flow and flow constriction. And 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 the product teams of one or two, where you just, you can't get all the work through. And taking a step back from that, you generally wanna 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 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, et cetera, to get more capacity and the accountability becomes a little broader because you have to balance across multiple outcomes 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 non-profit piece of this question, which in mission-based organizations priorities are really hard because everything is so important to the mission and 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 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 app. ## What is really happening in the system And I think it 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 know that's a little bit of a pivot from the program management side of the question, but that's kind of where I saw this question going. So, 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 business and the sort of impact, impact and value. Everything that we do has to have 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, the non-profit, these sort of organizations, your stakeholders you really want to satisfy those stakeholders and changing priorities as a huge impact, maybe a personal human impact 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 time sheets putting time into the right buckets, you know making sure you capitalize appropriate investments. I remember when I It's my first job, 92, I think it was commercial union, which no longer exists, not because of me, just for the record. They got merged with another insurance company and then brought into another one and they're huge. Aviva, amazing organization, actually big scrum shop. Anyway, but I remember having to create time sheets on that Friday afternoon. Now I remember one of the motivations for doing it, one of the reasons why my boss, Gita Shah, said that I needed to do it, was because of the way in which money was being capitalized, et cetera. So you had projects and you had work inside those projects and all this sort of stuff. Does that change with the product model? Or you know, you obviously live this, you worked a lot with finance, obviously fidelity a different perspective than maybe TI on this, but what happened? How can you do it? You can do it. It takes work, right? It's not free. Capitalization can't be unwound if you have significant portfolio capitalization happening. It can't be unwound in a single cycle. It takes, it takes in cases years if you even choose 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&L requires, right? If you've got that built into your P&L, you can't ignore it. You have to solve for it. So you can use feature tagging, which is an approach to that, and you can automate feature tagging. 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 an estimation of how much work is happening against features and those features are then tagged 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 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 an 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 a lot of things outside of product delivery that go into that. 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're going to say I'm wrong here when I ask 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 or hurdle, a burden. They actually want to drive good stuff into their processes. Absolutely. I'm sorry, you 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 clarity to what's actually happening. You fell off with it to you, sir. Yeah, that would agree in general, but it is you change and finance people are not the people, you know, 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 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'm a combat trainer, a lot of PSDs are saying, no, don't do story points partially because what we've brought into the community, but why not use them in parallel for a while and see that it makes sense to trust the throughput, and there's no additional value in what you get with StoryPoint. So here as well, do time sheets in parallel to doing feature tagging or using new tools that can associate check-ins to the code base with georetic kits and show you stuff. There's lots of cool stuff that's available these days, but run it in parallel and see than the evidence that you get makes sense and over time maybe you can start to remove those time sheets. 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 time sheets as part of this because it wasn't the biggest fight were fighting at the time. 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, it was in England in the 90s, you go to the pub of Friday lunch and I'd come back and I'd 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 I doesn't matter what I did that week, I was completely the opposite really. I mean, yeah, I just tried to get it to balance. And then if it didn't balance, my boss Gita would be like all over me. And I'm like, 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 all good things can happen. I think apply evidence-based management for the words evidence-based management, Dave. Oh my God, it's gonna be turtles all the way down now, you've L, so I'm gonna get confused. But yes, it's like, ah, You need to adopt this in an agile way using evidence to drive change. 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 trouble. I mean, that is the reality. And yes, this is just one other thing. All right, so carrying the theme about. Let's talk a little bit about 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 start attack with fluid teams, technical debt piling up all over the place? They're doing a lot of support. 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 me when I came in as CPO of Tastot, 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 would sold a story to that maybe our products didn't quite live up to. But I also had a product roadmap that we were using to drive investment, talking to VCs, etc. I wanted to demonstrate progress against this roadmap while trying to – it was really we were transitioning from a service-based company to a product-based company. And it was only because of the inspirational leadership of Matt, Kirsten and Nielen and some some of us that provided me the air cover that allowed me to do that because we made the choice that ultimately the long-term value of the business was going to be such as a product company and as a services company, yeah, we might be able to build a services business for a bit, but that isn't the long-term strategic value of the business. So I've lived through this. What would you say, you know, I don't know who wants to, you know, you've argued when you're in this situation where you've got a product, you've got teams aligned, you've got a roadmap, you've got stakeholders and you've got support, the operational element. What'd you do? 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 turtles all the way. It's what we use to make our 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 said guardrails or 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 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? supporting the challenge that my team had, particularly as they initially had one Scrum team. That's not the 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 Carson, 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, making payroll was one choice we often had to make. And it was interesting. So guard rails and empowering, getting that product owned to make those decisions was crucial. Darryl, have you been in a similar situation with some of your products? 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, and we talked about empowerment. Well, empowerment comes with an accountability, right? ## The practical shift 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, I think you have to really look at 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 payroll this month versus payroll for the next six months or two different questions, right? And you probably have to solve for both. How do you balance the ability to hit payroll this month but not create a situation where 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 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. In some cases, a little bit of extra debt's okay because the revenue side of the house is accounting 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 a perfect example of account opening, right? Account opening is fairly ubiquitous now, it's fairly 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 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 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. We had to make some hard choices. And I'm reminded of recently, there's 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 you've all 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 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 interesting. I'm sure they're an amazing organization and they are on the road to recovery. But it's those choices, having it transparent, and it's hard and you have to get everybody on the same page. Really, really interesting choices. Dev, you're Val. Yeah, maybe last quick note about this. 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 get 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. Why will we create this new capability? Why will we do that other thing? Why will we launch the new platform? You need to do it in a way that forces trade-offs. That makes sense. It's a conversation. It's something over something else. Like they're just working software over something. It doesn't mean you won't do any of the other thing, but it's a choice. But that initiative, and so imagine there's an initiative associated with technical debt because from the flow metrics, the company has seen that it's getting harder and harder to add new capabilities, they're having more defects, that's how it becomes an initiative. You've got a choice then. You either start, and I had this actual choice, actually a task top, and I remember the conversation. This was later on in the journey when we decided to build what we called factory, because we were an integration hub, and you can imagine that every time somebody released a new API to their products, Giro, or service now, everything broke. And so we built, so I'd got this evolved out 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, do we stop, move, it was exactly right. This wasn't about status reporting. This wasn't about saying red, green, blue. This was yellow, 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 slow down on our roadmap delivery and we keep a couple of customers, luckily one of them is Dao, so he was fine, but we don't necessarily service them quite as well as we historically have. And we had to make those choices. And for six months, and what was even worse you though, is we made that choice. and then with a six month sort of time frame. And then that's what, after three months, we realized it was probably nine months. And that was luckily it was over the summer and everybody was on vacation. So that we ignored, so we slipped it in there. But it was, yeah, 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. One of the things I find really powerful is taking your goals and putting them on a conman 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 conman board. Visualize how many of those goals do we have? OKRs, widely important goals, rocks, whatever. initiatives, ethics, 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. 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 the stuff and then they instead of 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 got a mission. Everybody's got a goal. I mean, who doesn't want a goal? 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 Canban border questions. We're doing, this has been a good one today. You see, practice, second time's 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, Yvonne. I have a caveat on that. It's an initiative that significantly, meaningfully, impacts multiple products. If I'm working on something and I need Darryl 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 of success. So we need to be careful not to manage all of the organizations work at the portfolio level. That's why I'm saying 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. And in the case of Yaval asking Darrow to, you know, do a small minor thing, so it make his life so much more easy or delivery, or you think. Then that is just been managed in the backlog like any other stakeholder that comes in knocks at Darryl's door. Cross-product initiatives are ones where there's, that the Yaval would have a wheelboule of requests to Darryl and vice versa, maybe, which starts adding to the complexity of the situation. Thank you for calling that out, Yvall. I think that is really, really, really important. ## What leaders should pay attention to And honestly, it isn't a scientific sort of measure, cross product or not cross product. You know, is it 700 requests? Is it 400? Is it 12? You know, I don't know. I think you know when you know though. And I think it's sort of clear. So thanks 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 Leem Portfolio Management, they do this idea of an 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 that they need to have a regular cadence, they need to have transparent artifacts, maybe a backlog, maybe a cam-bandboard, maybe blip blip blip blip. and they have an initiative owner. And there was a question about what's the conflict between product owners and initiative owners. So, I know, Darryl, you were in financial services where there were these big initiatives, whether it's moved to cloud, whether it's GDPR, whether it's some new SOCs compliance that isn't about SOCs, it's about something else, but everybody's gotta wear green SOCs from now on that. How did you balance ownership and empowerment to the team level with these very powerful senior people that Cameron goes, I need to have this. The company will fail without it. I think there's different types of initiative owners, and you hit on a couple there, Dave. So let's talk about cloud migrations. 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, or you're doing, you know, why, why are you doing it for cost containment? Because 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'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 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 need to understand how that objective is going to be fulfilled through my organization and how we're gonna measure it and how it's gonna fit with my other priorities and have those conversations. Because I think that those are the real challenging initiatives is more the business initiatives in the pure tech initiatives 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 Yavala, I think, was trying to avoid, which is only use the initiative construct when you absolutely have to, big enough to use it, the prioritization becomes where the rubber meets the road and having that portfolio level conversation about 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 in 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, E-Valley. I think you're making an important assumption there, O, that the product owners are product owners. A lot of organizations that I see at the point that they're starting their portfolio journey, their product owners are not really the empowered product owners that we talk about. It's a slippery slope to the point where we think the initiative owners tell product owners what they need and it happens. I think you described the right dream scenario, 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 product. That is a dynamic that is alien, foreign, 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 wall, it's somebody from the project wall. That's an anti-tottern that I often see. Yeah, that makes sense because you got this big initiative. It's cross product. It's a business. It's high profile. You've got your product teams running. And of course, the natural assumption would be to get a really good project manager to get it. Because 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 elements of scheduling and the light, 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 majority of the work needs to be being done by the product teams based on their product roadmaps and not everything is an initiative because it it affects multiple products, which is the point that I think you raised earlier, and I think it's crucial. And ultimately, we want to empower the product owners. So give them the guardrails, give them 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 it makes it very hard when you've got escalation issues because the technology leader has a different set of goals than the business leader. And then there's this game of, and is it going to go away up to the CEO of, and if it's a big financial company, then I'm not sure that makes sense. So it just goes round in circles. Let me just jump in real quick, Yvonne, then I'll jump through it to you. 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 make that happen more? Because as long as people are working to different incentives, 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 product portfolio centric model. So I think that's a whole other conversation, we didn't have a question about it. But but I think it's an important one to note. 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 the real client right now. What's the scope of the 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 need it to be a business and technology partnership, not an us and them, where 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 JNI 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. I think that, you know, the reality is that most organizations are still on their legacy organizations or on their journey from from business and technology separate to business technology. And I think that can be a really good tool as a catalyst for driving that transition. However, 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, but then it's a very different set of goals ultimately lead you to these challenges of these, you know, ownership battles which makes not good for anybody. All 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, and come to a head at that portfolio level. Thank you for listening today 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.