Toyota Connected: How the Ideas of the Agile Product Operating Model Shape Portfolio Management Strategy

How does Toyota apply Agile Product Operating Model (APOM) principles to portfolio management? In this episode of the Scrum.org Community Podcast, Dave West and PST Lucas Smith, Director of Agile Program & Services, Toyota Connected, explore how Toyota Connected structures its funding models, defines product life cycles, and manages dependencies in complex product ecosystems. Learn how Toyota Connected balances agility with control, ensuring product teams can innovate while maintaining strategic alignment. Tune in to discover how APOM principles are shaping portfolio agility at scale.

Transcript

Moderator: 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 of our agile product operating model series. The focus of today's podcast is about portfolio management. In January, I presented a webinar on how portfolio management fits in to a palm that webinar has created some quite interesting conversations about portfolio management and the like, and one of those sets of conversations was with one of our PSTs, Lucas Smith, who's joining us today. Lucas is a PST and an executive at Toyota, connected now I know some of the listeners may already know this. I'm a big fan of cars, so apologies if Lucas and I accidentally start talking about cars. We're going to try not to today, and it's, it's a bit of a challenge, so But welcome to the podcast, Lucas.

Lucas Smith: 1:17

Thank you very much. I'm glad to be here. It's great,

Dave West: 1:19

great to have you. Okay, so Toyota hugely famous for building products. As you know, I look out my window and and see two Toyota pickup trucks actually outside my window at the moment. You know, they also are very famous for creating many of the ideas that have led the next generation of management thinking in the 20th and 21st century. So I'm really interested on how they and you at Toyo connected approach portfolio management. I mean, many of the organizations we talked to and many of the conversations I had after the webinar were very much like this is incredibly challenging because it's bringing together, you know, money, effort, reason, you know, all of the challenge, business strategy, everything in one place, and it's a sort of massive melting pot of pain for many organizations. So I'm sure Toyota are doing it really, really well. So tell me a little bit at how you manage your investments and your portfolio products.

Lucas Smith: 2:26

Well, that's a really good question, and I will also acknowledge that it is a very difficult challenge. It's a difficult challenge when you're just dealing with a web or an application that doesn't maybe have hardware and supply chains and things behind it, but it's even bigger challenge when you're dealing with a combination of a physical product that you're producing in multiple locations around the world, the supply chain with that, as well as the increasing complexity of software and the interconnectedness of vehicles. So that's that's really where our Toyota connected has been focused is around the connected vehicle, the complexities with that. So we don't cover everything, so I'll speak primarily to our area, but I think we've approached it in a couple different different levels. So I think maybe for the purpose of this will assume you have some sort of strategy, right, an organizational purpose, right? So, so that that's kind of an assumption, because if you stray too far outside of your purpose, you kind of get lost, and stuff doesn't work so well. So well, we'll ignore that, that big question, but it is a good question. So I think, I think for us, the first level is really just trying to understand what your products are, right? That is ultimately a very key piece to this. And frankly, we have lots of discussions around what qualifies as a product, whether it's something a customer uses, whether it's something you can have internal teams using. I think of it as both. But in general, we think of a product as something that is long lived, that we have to maintain, that we add things to, and we kind of have a rule of thumb. It's kind of a funny one, but if someone might call you and complain about it, and be able to name it, it's probably a product, right? There's a lot of things that go on under the scenes and under the hood that you know, a customer might not see, and they might be a product, but really, you think about some sort of packaging those into something that's that's understandable for someone, so that that's a rough rule of thumb. So I would say first, first we look at, what are our products, and then I really do, I think some of the APM material is that you pulled together is really correct in that understanding the life cycle and the funding of that product is really important. I would say the life cycle. And the life stage of that product is really the next thing we look at. We tend to refer to things as either in an explore extract or explore expand extract and end of life. So it's a little bit of that model, right? And each of those stages has some different characteristics to it. So within a big organization, right? It's it's hard to to have a single funding stream, a single funding model that works for everything. So it's important to understand those distinctions. Because if you're talking with finance, or you're talking with your investment council or your approval board if they're stuck in thinking about everything as like this is an established product, and we have to be very careful with it. That's a different funding, different approval thought process than something that's an exploratory that isn't an established product yet. So that's kind of an important life cycle. So I would quickly explain those as explore is something that you don't have a market for yet. You might, but you're trying to test it out, right? So the important thing about things and explore phase is to move quickly, to move you know, small team, small amount of funding, learn fast, don't you're not building something that's really polished, but you're trying to identify if this is really going to become something, if there's really a need there. If you do now, you really go into the Expand phase, right? So expand is really where you want to put a lot of money, a lot of teams, and you're really trying to grow that. Capture the market, capture the users. Build something that you know gives you a competitive advantage. And so there's, there's a lot of there's a clear investment, reward return in an expand phase, right? You've made a case. You know that people want this, so you're investing in it. Once you have an established product, especially big organizations, it's it becomes harder to think of that as something you want to take a lot of risks on, right? So now it moves a little bit more into what I would call an extract phase, right? It's an established product. You may not be changing tons of things about it, but you need to continue to invest in it, you need some sort of continuous stream. But you're thinking about, you know, all the things about user costs, cost to operate, cost to maintain it. You know, user engagement with it, but you're not going to necessarily make huge changes on that product without testing it, or beta testing it, or doing some sort of Canary release, right, just because the risk is a lot higher, and then at some point, right? It becomes end of life, or it's something that you don't care about investing as much in anymore, because you don't think there's as much return. So maybe you have to keep the lights on. Maybe you have to maintain it right, while people migrate to your new product, your new system, but you're you scale down your funding, you scale down that around it a lot, so that that is kind of the base. Now, not everything fits so cleanly, right, but, but that's kind of the goal that we that we think towards, and it does really help to understand the purpose, the key metrics, the key value proposition of that product, right in the market or internally, right? If you have something that's more of a platform, because they kind of follow a similar, similar thing. So that's kind of our product. And then can

Dave West: 8:36

I just lean into that just for a second? Yeah. So ultimately, you fund products based on value and the stage they are in their life cycle and the amount of risk or reward, etc. And then you allow because this is a fundamental idea, really. And then you allow teams to determine the work based on strategy and business road maps and user needs and etc, etc. But for your products, would you say? And I know it's never black and white completely, but generally, that that is a principle that you at Toyota connected follow. I would

Lucas Smith: 9:12

say that is our that is our goal and principle that we attempt to follow. I would say we have, I think the product base is really what we have gone for, because we believe that's where the value really is in this size and the complexity of organization. We have aligned on some terminology. So I think it's really important to align on what you call a product and what isn't a product, right? Because that can determine the funding as well. So the the life stage of a product kind of determines how you fund it, how you evaluate it. But not everything fits that product as cleanly as we would like, right? So we think of products again as something someone would use that we want to have a continuous funding for a mostly stable team. We. Have a clear market users we can, we can gage that above that or separate from that, we would, we refer to things as initiatives, right? So we'd like to keep things as simple as possible. So, you know, a base initiative might be just something that, okay. We're upgrading features for EV vehicles, for example, and that might affect a couple different products, right? There's got to be kind of a cohesive strategy there. If we can do it just with the product areas or business areas working directly with each other, that's great. But if it gets complicated enough, if it touches enough different products, or maybe it goes to multiple companies within Toyota or multiple suppliers. Now you you get a little bit of a different kind of structure to that. So we kind of do those in two flavors. One is what we call kind of a cross product or cross organization initiative, and that's something that might last six months to two years. It has a determined time span. We try to do that around giving a small initiative team. So we try to give a small initiative team ownership of that initiative for them to then work into the product areas. Oftentimes, that initiative gets funding just because it's easier to understand. So we might get okay to get ten million to upgrade for EV teachers. So then they would take that funding and say, okay, you know, 5 million of that goes into the app, 2 million goes here. So they're, they're hopefully dishing that out into the product areas. Now, if we get big enough, we have what we call a program. Our program is basically our multi generational vehicle launches, right? And so that that's something that encompasses, on our scale, probably 30 or 40 different separate products, maybe 40 different vendors who are building things, or we're integrating things into that, plus you're trying to plan that for 2030, different factories around the world and different vehicle lines. So that is a pretty complicated structure, and we have our whole dedicated program team that manages that. So they are still defining things that they want to go into the products. So they're still pushing things towards the products. But we tend to fund those programs, because they tie into vehicle sales for us, so that that's just at least our world, I would certainly say, you know, keep, keep it as simple as you can. Don't add a lot of structure if you don't have to, because structure adds complexity. Then you get to all sorts of challenges with integration. Who's doing the testing? How are you actually integrating things, the dependencies, across that? So for us, I mean, honestly, we have kind of a full time team doing that for our vehicle programs, but on the life cycle, right the base of it is, again, the products and we build on top of them.

Dave West: 12:57

Yeah, that's really, really interesting, because in the webinar, that's pretty much how we just, we didn't have the mega, sorry, the program stuff. I didn't talk about that because the people I interviewed aren't quite of the scale of there's very few companies in the world that are of the scale of Toyota. And, you know, cars are the most complicated machine that humanity mass produces. So, you know, they get think it's very likely that that layer is perhaps not necessary for for many organizations, there are but a few that that would but the initiatives is interesting, because there's exactly what I saw at the two or three companies that I talk to in preparation for the webinar. That's exactly how they work as well. They fund the products. And then, you know, long, long term teams allow them a level of autonomy around roadmaps and planning. And then there's these initiatives, you know, in finance, it was GDPR and financial initiatives, you know, around certain laws that are coming, and they push that. And if they get to a certain size, then they become initiatives with an initiative owner and maybe a team around them, which then drives that so, very, very, similar, I think, from what how you described it. So, all right, so, and at the heart of the the a POM approach is this idea of balancing agility with control, right? You you really want empowered teams that are taking ownership for their products and feeling like they actually make decisions about what's going in them and invested in it from a motivation perspective. But you need, obviously, that level of control, particularly if you're releasing the next generation of EVs or or sports cars or whatever the or the new Rav thought, whatever the things are that. You're working to. You need that level of control and transparency. How does it, in practical terms, you know, what does it? Does it? How do you exert these two country almost contradictory kind of like pulls?

Lucas Smith: 15:18

Yeah, I would say you put your finger on one of the key challenges, right? I would definitely agree with that. I think, you know, I don't claim there's a one size fits all right? It kind of does depend on your organization, what your risk profiles are, what your products are, etc, and your organization structure. So, you know, I touched on our core goal of funding products. Not everything is funded that way for us, right? So one important thing we have done to help understand that control is just to do it's basically just a quadrant map of our current products, or our current area, business areas, and how they are funded, right? So the the goal, right, is, you know, maybe your, your ideal dream is someone is paying for that product, or you're getting funding directly into that product team, right? That gives them the most autonomy, right, and the most ability to quickly make changes to that product, right? So, knowing how quickly and how critical it is that you can adapt that product that would encourage you or be able to have discussions within your organization to say, look, we really need an independent stream that doesn't go through additional brutal chains right to do this product team and allow them to adapt quickly. Some of our products are funded by external stakeholders within the organization. So we might have you know, so the first level that is our ideal is product funding directly to that team. Maybe second level is like a long term funding structure, but we still have to work with stakeholders right to determine their needs, what they want, what they want to integrated. So that's, that's kind of our I, you know, we call that level one level two. We currently our goal is to get everything to level two right, where we have a long term thought of products, funding stream, but we at least have engagement within the enterprise. We have stakeholders. We know who we need to talk to, so that they're, they're key, you know, stakeholders and contributors to that. We do have things that are operate more like a project funding, right? So we call that level three. So those are things that we have to go before approval board, right, and get funding for a certain amount of time, and we have to continually do that so that that gives more control to the organization. And a lot of times they feel better about that funding, but it means you have less adaptability right to change, and the team has less economy with that. And then level four, which is we try to avoid, but we do have some of this just because of our structure is where we're just kind of doing staff lock right where we are. We are basically putting people into someone else's product team so that that's that's maybe a nuance of the corporate structure and the different companies within Toyota, but just mapping your products across those was actually a really powerful exercise for us, and it really just helps us to see, okay, what type of work, what type of products do we or funding do we take on? What's our goal? Can we get, you know, this one is stuck in level three, can we make a case to move to more consistent funding for this product because of the the market needs, or is it okay that it stays there like it's not a big deal. So I think that was actually a really key exercise for us, and allowed us to have discussions internally and with different parts of Toyota to say, look, if you're telling us we really need to be innovative, we need to be adaptive, we need to change or we need to catch up to the market in some way, then you have to fund it or structure it in a way that allows us to do that. Yeah.

Dave West: 19:04

And I actually think, even though, you know, Toyota connected is, is a unique entity inside Toyota that that actual model, maybe not the fourth one, but the 123, is very similar in most organizations. Actually, one is those products that, you know, there's definite money coming in, you know, it's a financial product. It's, you know, it's something that people are buying or using or subscribing to, either as a shared revenue, you know, that you get a slice of a bigger pie, or whatever. Second one is, ones that are internal systems that are very much have sponsorship and and they're like, yes, we need to have this call center, or we need to have this for a period, but, but the money is a little bit less direct. And then the third one are these projects. You know, I was going to a consuming package goods organ. Organization few weeks ago, and they have, they fire up these, oh, we need an app that does this, you know, whatever it is, something about diapers, or something about whatever, women's health or whatever, and they've created, and then it's, doesn't really, and they fund it, and the team have very little. I mean, it's kind of like a bit, yeah, they try to be outcome centric. They try to be user centric. But at the end of the day, you're satisfying a stakeholder with a big pot of cash and and then so you deliver that. And then it's like, okay, so what happens? How do we maintain it? I was talking to, actually, last year, talking to the lady, a lady that works at the Dutch natural history museum, and she said, we're really good at those threes. And I've got, like, a million of, oh, the history of the dinosaur app, the app, or the, you know, all of this stuff. She goes, nobody maintains them because they haven't moved it into two or one, and because of that, there's this thing. So it's funny, I think that that model is actually incredibly universal, even though I I'd not really thought about it until you shared it with me, when, when we met in Orlando, what, three weeks ago or so, which is, which is really interesting.

Lucas Smith: 21:21

And you see and you see that the structure, you know, we're talking about it kind of in the Agile product sense, but if you look at it from an organization perspective, what you're looking at is, do you have a Profit and Loss Center? Do you have a P and L center as an organization that is getting revenue in for your product, making decisions about it? Or are you operating just as a cost center? A cost center now has to get approval to spend money from someone else, so that's kind of your level one, level two, and if you're a cost center, but someone else outside is deciding what they need to do and funding you now, now you're a level three project, right? So that's the structure that a lot of people deal with and I think it's okay to recognize that, right? And just plot it out like there are trade offs, right? There are trade offs between each of those types of work. Well,

Dave West: 22:09

the biggest challenge that level three, from my experience, from talking to people have, is the longevity element. You know that you can't technology. You know, software doesn't die. You have to kill it. I hate to say that, and that's an awful analogy, but you really do. And so there's all these things sitting around that are no longer maintained adequately, or they're sort of maintained in the sort of hidden, you know, I I remember when I was working at commercial union 100 years ago, there was this one app that was never funded, but we always maintained it. And it was just you, just protect you, just move those because we had to do time sheets. And I just, I the time I spent on the app, I just put on my local project. And I know that was really awful, but somebody had to maintain it. It was an important app, right? But it just had the truth.

Lucas Smith: 23:06

It's the truth or your every time you introduce a new project that you're getting funded, there's a cost, you know? There's a buffer cost that you're adding to each of those to basically maintain everything else, right? It's like, okay, your first app costs you a million dollars. Well, your second one is 1.5 you know, it really costs a million, but we need half a million just to maintain the old ones that you don't fund, right, exactly.

Dave West: 23:31

And of course, that leads to massive amount of technical debt. It leads to, you know, you've not deployed the latest security patch. It leads to all of those disasters. I you know, there's been many an audit of an existing organization, and they found like, 400 apps that nobody knew anything about. But that's just the that's just the way of the world. Because, you know, we are a little bit like magpies, oh new shiny thing. Oh, new shiny thing. And that's the reason why I think your strategy of trying to get to at least two is admirable, because then you have a product roadmap, you have a, you know, an operational roadmap, you you know, you have a value proposition in terms of an economic roadmap. You know, I think that that's really, really really important. Let's you mentioned that some of these programs are incredibly complicated, particularly at the program level, so above initiative and above product dependencies, what happens with dependencies? How do you because the worst thing in the world from a product team is to be dependent on somebody else's roadmap. It just, it just makes everything harder. How do you, I mean, you have OEMs. OEMs have, you know, this is just, I was talking to BMW about two years ago, and and. Way, the number of variants that they have and the number. And they showed me the sort of like the mathematical equation for variants in their system. And it was, you know, it took up the entire board. It was so complicated. What do you do at Toyota connected because simplicity, it's a key premise of Toyota management system. And you know, you do a really good job of simplifying anything. How do you manage dependencies?

Lucas Smith: 25:29

And that's that, that is a good question. So I'll try not to overload with too much, because vehicle programs not everyone's dealing with, right? But those are, those are the worst right in terms of managing it from a base level, you're just, you're adding structure, minimal structure, right as needed. We do find that some type of quarterly planning helps a lot. So a quarterly road mapping, high level features discussion with dependent teams. So that is that helps a lot, because, you know, that's kind of the the level, you know, time wise, that we're planning stuff, right? So, So visualizing that, doing quarterly planning with all of our teams, allowing time, ahead of time to work and say, hey, you know, we're going to be launching this feature here. What are the three things that are dependent on it? Let's get agreement from the different teams and timeline on that. That's kind of the base first level right between products. And we try to manage most of the things just product to product there. When you get to initiatives, right initiatives kind of feed into those products. So it doesn't necessarily add a lot of dependencies other than what we can manage in quarterly planning program level. Absolutely right? To your point, you know, we have maybe a supplier who's adding a new we call it the head unit is the dash unit in the vehicle, right? So we're designing a new one. They would be called our tier one supplier. They're a global company, you know, Fortune 100 company. They're going to be building 10 million of these for us. But they have tier two supply. Two. Two would be someone supplying them. Tier three would be someone supplying them, right? So those, those programs, especially because we're dealing with hardware, we we have to plan out as kind of a four or five year cadence, right? So we know enough about building cars right that we know roughly how much time it takes. And we're adding buffers. And we're adding buffers between finalization of a physical product, finalization of the software product integration points right before we go into pre factory builds, right? So we do things like hand built vehicles that we do testing on right before everything comes together. And then there's couple months before that goes into a factory, right? So I would say that that just depends on your risk. Right? For us, stopping a factory is like millions of dollars a day, right? And when we, when we build a product, it's got to go in there, it's got to work the first time, so we are willing to pay and have integration pay for slower stuff ahead of time because of that risk. Yeah. Now, if you can standardize, right, like that. That is a key discussion for us. Right is, if you're, if you're changing your your software, underlying platform every time, or the processing chips on the vehicle every time. Now, now you've lost, you know, you have to redo a lot of stuff between your generation. So that's one thing, is minimize your complexity based on your scale, but then, if you can create things for customers that create differentiation, but don't add a lot of complexity, right? So, you know, frankly, Android and Apple have this has been a challenge for them. Even screen size differences on devices means that your apps have to be redesigned. They have to be designed in a way that they scale and strength and contract. So we have huge vehicle line. We have all sorts of different screen sizes, but picking those screen sizes and standardizing them on them, or having a fixed set is one way to simplify it, right? And then, you know, so creating that, or designing that from up front and saying, Look, we're not going to redesign the multimedia system between Corolla and between Alexis, right, like we might brand it differently, and we might have different touch and feel to it, or different sounds that make it sound more premium. But you're not if you build a completely different software product for those where you allow the organization or stakeholders to demand that you've just duplicated your cost and maintenance. So you gotta, you gotta pick what is core and then, but allow differentiation, because stakeholders in your company are always going to want that if you've got multiple levels of brand. And like, we have a chief engineer for Corolla, right? And he argues with us if we want to increase the cost on something by five cents a vehicle, right? Because to him, that matters a lot, right? Whereas, you know the Lexus LX, you know, they're like, Okay, yeah, we want you to add a couple dollars here, because we want a more premium feel. We want a more premium thing. So how do you differentiate that? You know, I think there's a lot of lessons. Apple is very good at that, right? And just a little bit of different screen size, a little bit of a different camera resolution, you know, more storage space, you know, those are things that actually don't impact your software very much, but they impact the user experience, which create a differentiation. So those are things, just increasing the size of your screen, increasing the resolution, maybe the speed of responsiveness, maybe the sounds, the touch and feel. We do spend a lot of time trying to think through how to manage reducing those, those number of permutations, actively.

Dave West: 31:04

I think the the complexity thing is really interesting, because obviously, I mean, Apple only releases once a year, really, let's be honest. I mean, there are obviously small releases before that, but that they've, they've managed to persuade their customers to have have a level of understanding that many of us could only dream about, and they have sort of brand following in a different way. But then you look at like Tesla, the fact that when I got my Tesla, there was two different software platforms running, you know, when they brought out the the the the Y and my s were very different. Right now, it's all the same. They've consolidated. The screens are the same. Everything's exactly the same, and people seem to be okay with it. But when you you know Alexis and a normal toy editor, as it were, is, it's very interesting. But reducing that complexity, I think, is crucial to managing that level of dependencies and deciding what core and context, what differentiates, what makes us special. You know that that's, that's the key, right?

Lucas Smith: 32:20

I think, you know, we actually talk about that layered model, right, from a expectations of updates, right? So, you know, Apple, they have, you know, it's a, it's a good model, because people think about it, right? It's like you've got the physical phone, right? That, to us is sort of like our physical vehicle, right? Apple updates their their phone every year. We update our vehicle every year, but we do major updates every three years. Yeah, then you have kind of your OS level, which is our firmware, our sensor management, right? Our vehicle platform, Apple might update that a couple times a year, right? We we're on maybe a twice a year update for that, right? And only certain parts of it we can update, and we're trying to improve those, those different parts. But then on top of that, what the customers see are the app side, right? So, so the even though Apple isn't updating their OS or their phone, you get updates every day, every week, you know, on the different apps, and that keeps you happy, because you're like, Oh, I got something new. I got a new feature. Got a new thing. So those are things, you know, we can update stuff from the vehicle. If something lives on the cloud. We can update that very quickly. So we build, we build the voice assistant that runs on Toyota and Lexus, and we can add new skills. We can add new things behind the scenes on that very quickly. Now we're talking about modifying firmware on a sensor on the vehicle. Now we've got a lot much longer play, because there's a lot more vendors, a lot more testing involved. Now if we're talking about needing to add a new sensor to enable a new product, now that's multi year, so that those time horizons are important to think about. And when you come up with new product ideas or new features, you have to know where those go. Are this? Can we manage this in the product? Or do we have to go to the vehicle platform team? Or do we have to get into the cycle ahead of time, several years out, and say, Look, we're thinking about one feature we just released, actually, we did this ahead of Tesla. Is the advanced rear seat reminder, where we've got, like, basically a millimeter wave radar in our Siennas that can detect heartbeats in back seats or in the trunk. And so if you leave a kid right in your car, it was kind of designed around the hot car. Yeah. So that took us several years right from concept at a hackathon where we could show look, we know we can do this, but it's a new sensor. It's a new physical piece that's got to go in the vehicles. And so it's going to be multi years, you know, to get that into the production line, even though. We can validate this product right now.

Dave West: 35:03

Oh, wow. And yeah, I recommend that we do it, because it'd be really good to not have these. Well, I'm not sure about kids being like. I'm more worried about dogs actually care about my children, by the way, Lucas, I wasn't implying that I don't they're just more vocal when they get locked in a car than my poor dog.

Lucas Smith: 35:26

There's a smaller age range, typically, that they would remind you, not remind you, right? Like, if your four year old, they're like, wait, you know, like, exactly what happens? Unfortunately, it still happens. So,

Dave West: 35:38

yeah, it does. So it's great that that is a that is a worthy cause. So just to take it all the way back and that we need to finish. And I could talk to you for hours about this stuff, I I really love the whole, I mean, the Machine that Changed the World is one of my favorite books of all time, because it just boggles the mind how we built cars and how we built the infrastructure around it, and the gas state, petrol stations, gas stations, and the freeways, and then the car manufacturers, and then it's just incredible. I think the story of automotive manufacturing is one of the most interesting things ever. And I'm definitely, well, I guess they what they called petrol head, but I guess actually, I'm an electric and petrol heads. So that's it. So I could talk for hours, but so just take it forward. Thing, what was very apparent from your conversation when you were talking about dependencies Lucas, was that the ultimately, the selection of the products and the platforms, and making those right choices about what is a platform, what is a product, and how do they fit together, has everything about this and and you have to be very cognizant of your product architecture and continuously monitor it and and ensure that it's giving you that flexibility time to market and that value that you seek is, is that a challenge? Because it must be really hard to change that those product boundaries, even if it makes sense to do so when you've got this, this machine running continuously around it? Yeah,

Lucas Smith: 37:15

no, no, absolutely right. And I think if you if every time you have to add a new feature to a product, you're dependent on someone else, maybe that's a sign you should at least evaluate those boundaries. Now, maybe there's two things you need to evaluate. One is your horizontal boundaries, right? If? If, every time you're adding a button or a widget or something, you're dependent on someone else and change, we'll say, we'll say this, you're dependent on changes from someone else. Yeah, and you either need to look at that boundary, or you need to look at how you've done the technical interfacing between those layers, right? So again, we'll go back to a simple model with the apps on your phone. Apple has the OS level, has made a number of different calls and API calls and calls to different sensors and getting different data like that that platform, like every time you add a new feature to an app, you don't have to change the platform, right? You rely on it being there, and you make changes to it. So just because we change an app doesn't mean we don't have to use something else that someone has provided, or different platform. But if every time we require changes on them, then maybe it's a sign we either haven't drawn the boundaries right, or technically we haven't exposed the right level of abstraction from that platform that is usable, right? So I would say, keep track of those things, right? Any any time you have a cross area dependency, it's at least something to look at, right? Do you? Do you need to change your boundary? Is this something that we need to abstract better for APIs between different products, or between platforms and products? Or is this really just something we can't solve just based on this touches all the different layers of our product, and Paul goes all the way from a physical thing, right? I'm not going to change the boundaries of my product just because I need a new sensor on the vehicle, like, that's a physical thing, right? That if we don't have a radar in the car, there's no way I can do that product, right? I'm going to have to require it. So there's some things that are always going to hit that, but it is. It's definitely worth evaluating and keeping track of that and saying, Okay, do we have the right horizontal boundaries from a product standpoint, or do we have the right kind of technical structure that enables our products without too many dependencies on others?

Dave West: 39:36

Yeah, makes makes sense. Oh, I could talk all day, and and I learned so much from talking to you, Lucas, thank you for taking the time today. I I know our listeners are going to be so thrilled to I mean, Toyota is obviously famous in our world, right, you know? And coupled with actually, the practical lessons of how you. To deliver a product in a very complicated environment. I love the the four different sort of funding sort of models, as it were. I love the, you know what that has that implication on autonomy. I thought it was really interesting. It all starts with the definition of product, and managing those dependencies is a key characteristic that you just mentioned again there. I think that's super crucial. And at the end of the day, it's about balancing agility with control and and how you do that, I think is super interesting. So thanks for taking the time. And absolutely

Lucas Smith: 40:37

it was great to talk to you. And if I if I have a last word, I would just say, anyone working in complex systems like, just understand that there are other people who are experiencing the same things you know, to to accomplish, sometimes huge and great things like, require complexity, right? So, you know, it's something you have to embrace. There are always trade offs. There's no perfect 100% answer to everything. But you know the fact that you have an opportunity to build something, especially if they can impact people's lives and make a difference, even if it's a little slower than you would like, sometimes, you know, that's a great place to be in a great opportunity you

Dave West: 41:16

have that's great. That's sage type words Lucas, be mindful of the of the system that you're building, and make it ensure it makes it transparent, but also understand that we're doing this to deliver value which is, which is an incredible opportunity that we all have in the industries and the jobs that we do. So thanks for your time, Lucas. I'll let you get back to building that next generation of car, which I can't wait to hear more about. But we'll take that offline, and I'll have over a beer sometime in the future. And listeners, thank you for listening to today's 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 areas of professional Scrum, product thinking, and of course, agile. Today we had, we had Luca Smith, PST and executive at Toyota connected, talking about the Agile product operating model with particular focus on portfolio planning and how an organization as innovative and with so much history and so much scale that Toyota has is actually working in a very Agile and creative way. So thanks for listening, everybody. Scrummorg,