April 10, 2025 • 42 mins
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.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Lindsay Velecina (00:00):
Music. Welcome to the scrum.org community
(00:04):
podcast, a podcast from the homeof Scrum. In this podcast, we
feature professional scrumtrainers and other scrum
practitioners sharing theirstories and experiences to help
learn from the experience ofothers. We hope you enjoy this
episode.
Dave West (00:20):
Hello and welcome to the scrum.org community podcast.
I'm your host. Dave West, CEOhere@scrum.org today's podcast
is part of our agile productoperating model series. The
focus of today's podcast isabout portfolio management. In
January, I presented a webinaron how portfolio management fits
in to a palm that webinar hascreated some quite interesting
(00:45):
conversations about portfoliomanagement and the like, and one
of those sets of conversationswas with one of our PSTs, Lucas
Smith, who's joining us today.
Lucas is a PST and an executiveat Toyota, connected now I know
some of the listeners mayalready know this. I'm a big fan
of cars, so apologies if Lucasand I accidentally start talking
(01:07):
about cars. We're going to trynot to today, and it's, it's a
bit of a challenge, so Butwelcome to the podcast, Lucas.
Lucas Smith (01:17):
Thank you very much. I'm glad to be here. It's
great,
Dave West (01:19):
great to have you.
Okay, so Toyota hugely famousfor building products. As you
know, I look out my window andand see two Toyota pickup trucks
actually outside my window atthe moment. You know, they also
are very famous for creatingmany of the ideas that have led
the next generation ofmanagement thinking in the 20th
(01:41):
and 21st century. So I'm reallyinterested on how they and you
at Toyo connected approachportfolio management. I mean,
many of the organizations wetalked to and many of the
conversations I had after thewebinar were very much like this
is incredibly challengingbecause it's bringing together,
(02:02):
you know, money, effort, reason,you know, all of the challenge,
business strategy, everything inone place, and it's a sort of
massive melting pot of pain formany organizations. So I'm sure
Toyota are doing it really,really well. So tell me a little
bit at how you manage yourinvestments and your portfolio
products.
Lucas Smith (02:26):
Well, that's a really good question, and I will
also acknowledge that it is avery difficult challenge. It's a
difficult challenge when you'rejust dealing with a web or an
application that doesn't maybehave hardware and supply chains
and things behind it, but it'seven bigger challenge when
you're dealing with acombination of a physical
(02:46):
product that you're producing inmultiple locations around the
world, the supply chain withthat, as well as the increasing
complexity of software and theinterconnectedness of vehicles.
So that's that's really whereour Toyota connected has been
focused is around the connectedvehicle, the complexities with
(03:07):
that. So we don't covereverything, so I'll speak
primarily to our area, but Ithink we've approached it in a
couple different differentlevels. So I think maybe for the
purpose of this will assume youhave some sort of strategy,
right, an organizationalpurpose, right? So, so that
that's kind of an assumption,because if you stray too far
(03:30):
outside of your purpose, youkind of get lost, and stuff
doesn't work so well. So well,we'll ignore that, that big
question, but it is a goodquestion. So I think, I think
for us, the first level isreally just trying to understand
what your products are, right?
That is ultimately a very keypiece to this. And frankly, we
have lots of discussions aroundwhat qualifies as a product,
(03:52):
whether it's something acustomer uses, whether it's
something you can have internalteams using. I think of it as
both. But in general, we thinkof a product as something that
is long lived, that we have tomaintain, that we add things to,
and we kind of have a rule ofthumb. It's kind of a funny one,
(04:13):
but if someone might call youand complain about it, and be
able to name it, it's probably aproduct, right? There's a lot of
things that go on under thescenes and under the hood that
you know, a customer might notsee, and they might be a
product, but really, you thinkabout some sort of packaging
those into something that'sthat's understandable for
(04:35):
someone, so that that's a roughrule of thumb. So I would say
first, first we look at, whatare our products, and then I
really do, I think some of theAPM material is that you pulled
together is really correct inthat understanding the life
cycle and the funding of thatproduct is really important. I
(04:56):
would say the life cycle. Andthe life stage of that product
is really the next thing we lookat. We tend to refer to things
as either in an explore extractor explore expand extract and
end of life. So it's a littlebit of that model, right? And
each of those stages has somedifferent characteristics to it.
(05:22):
So within a big organization,right? It's it's hard to to have
a single funding stream, asingle funding model that works
for everything. So it'simportant to understand those
distinctions. Because if you'retalking with finance, or you're
talking with your investmentcouncil or your approval board
if they're stuck in thinkingabout everything as like this is
(05:43):
an established product, and wehave to be very careful with it.
That's a different funding,different approval thought
process than something that's anexploratory that isn't an
established product yet. Sothat's kind of an important life
cycle. So I would quicklyexplain those as explore is
something that you don't have amarket for yet. You might, but
(06:05):
you're trying to test it out,right? So the important thing
about things and explore phaseis to move quickly, to move you
know, small team, small amountof funding, learn fast, don't
you're not building somethingthat's really polished, but
you're trying to identify ifthis is really going to become
(06:25):
something, if there's really aneed 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 theusers. Build something that you
know gives you a competitiveadvantage. And so there's,
(06:47):
there's a lot of there's a clearinvestment, reward return in an
expand phase, right? You've madea case. You know that people
want this, so you're investingin it. Once you have an
established product, especiallybig organizations, it's it
becomes harder to think of thatas something you want to take a
(07:08):
lot of risks on, right? So nowit moves a little bit more into
what I would call an extractphase, right? It's an
established product. You may notbe changing tons of things about
it, but you need to continue toinvest in it, you need some sort
of continuous stream. But you'rethinking about, you know, all
the things about user costs,cost to operate, cost to
(07:29):
maintain it. You know, userengagement with it, but you're
not going to necessarily makehuge changes on that product
without testing it, or betatesting it, or doing some sort
of Canary release, right, justbecause the risk is a lot
higher, and then at some point,right? It becomes end of life,
or it's something that you don'tcare about investing as much in
(07:51):
anymore, because you don't thinkthere's as much return. So maybe
you have to keep the lights on.
Maybe you have to maintain itright, while people migrate to
your new product, your newsystem, but you're you scale
down your funding, you scaledown that around it a lot, so
that that is kind of the base.
Now, not everything fits socleanly, right, but, but that's
(08:12):
kind of the goal that we that wethink towards, and it does
really help to understand thepurpose, the key metrics, the
key value proposition of thatproduct, right in the market or
internally, right? If you havesomething that's more of a
platform, because they kind offollow a similar, similar thing.
So that's kind of our product.
And then can
Dave West (08:36):
I just lean into that just for a second? Yeah. So
ultimately, you fund productsbased on value and the stage
they are in their life cycle andthe amount of risk or reward,
etc. And then you allow becausethis is a fundamental idea,
really. And then you allow teamsto determine the work based on
(08:58):
strategy and business road mapsand user needs and etc, etc. But
for your products, would yousay? And I know it's never black
and white completely, butgenerally, that that is a
principle that you at Toyotaconnected follow. I would
Lucas Smith (09:12):
say that is our that is our goal and principle
that we attempt to follow. Iwould say we have, I think the
product base is really what wehave gone for, because we
believe that's where the valuereally is in this size and the
complexity of organization. Wehave aligned on some
terminology. So I think it'sreally important to align on
(09:33):
what you call a product and whatisn't a product, right? Because
that can determine the fundingas well. So the the life stage
of a product kind of determineshow you fund it, how you
evaluate it. But not everythingfits that product as cleanly as
we would like, right? So wethink of products again as
something someone would use thatwe want to have a continuous
(09:56):
funding for a mostly stableteam. We. Have a clear market
users we can, we can gage thatabove that or separate from
that, we would, we refer tothings as initiatives, right? So
we'd like to keep things assimple as possible. So, you
know, a base initiative might bejust something that, okay. We're
(10:18):
upgrading features for EVvehicles, for example, and that
might affect a couple differentproducts, right? There's got to
be kind of a cohesive strategythere. If we can do it just with
the product areas or businessareas working directly with each
other, that's great. But if itgets complicated enough, if it
(10:38):
touches enough differentproducts, or maybe it goes to
multiple companies within Toyotaor multiple suppliers. Now you
you get a little bit of adifferent kind of structure to
that. So we kind of do those intwo flavors. One is what we call
kind of a cross product or crossorganization initiative, and
that's something that might lastsix months to two years. It has
(11:00):
a determined time span. We tryto do that around giving a small
initiative team. So we try togive a small initiative team
ownership of that initiative forthem to then work into the
product areas. Oftentimes, thatinitiative gets funding just
because it's easier tounderstand. So we might get okay
to get ten million to upgradefor EV teachers. So then they
(11:23):
would take that funding and say,okay, you know, 5 million of
that goes into the app, 2million goes here. So they're,
they're hopefully dishing thatout into the product areas. Now,
if we get big enough, we havewhat we call a program. Our
program is basically our multigenerational vehicle launches,
right? And so that that'ssomething that encompasses, on
(11:45):
our scale, probably 30 or 40different separate products,
maybe 40 different vendors whoare building things, or we're
integrating things into that,plus you're trying to plan that
for 2030, different factoriesaround the world and different
vehicle lines. So that is apretty complicated structure,
and we have our whole dedicatedprogram team that manages that.
(12:10):
So they are still definingthings that they want to go into
the products. So they're stillpushing things towards the
products. But we tend to fundthose programs, because they tie
into vehicle sales for us, sothat that's just at least our
world, I would certainly say,you know, keep, keep it as
simple as you can. Don't add alot of structure if you don't
(12:33):
have to, because structure addscomplexity. Then you get to all
sorts of challenges withintegration. Who's doing the
testing? How are you actuallyintegrating things, the
dependencies, across that? Sofor us, I mean, honestly, we
have kind of a full time teamdoing that for our vehicle
programs, but on the life cycle,right the base of it is, again,
(12:54):
the products and we build on topof them.
Dave West (12:57):
Yeah, that's really, really interesting, because in
the webinar, that's pretty muchhow we just, we didn't have the
mega, sorry, the program stuff.
I didn't talk about that becausethe people I interviewed aren't
quite of the scale of there'svery few companies in the world
that are of the scale of Toyota.
(13:18):
And, you know, cars are the mostcomplicated machine that
humanity mass produces. So, youknow, they get think it's very
likely that that layer isperhaps not necessary for for
many organizations, there arebut a few that that would but
the initiatives is interesting,because there's exactly what I
(13:39):
saw at the two or threecompanies that I talk to in
preparation for the webinar.
That's exactly how they work aswell. They fund the products.
And then, you know, long, longterm teams allow them a level of
autonomy around roadmaps andplanning. And then there's these
initiatives, you know, infinance, it was GDPR and
(14:02):
financial initiatives, you know,around certain laws that are
coming, and they push that. Andif they get to a certain size,
then they become initiativeswith an initiative owner and
maybe a team around them, whichthen drives that so, very, very,
similar, I think, from what howyou described it. So, all right,
(14:24):
so, and at the heart of the thea POM approach is this idea of
balancing agility with control,right? You you really want
empowered teams that are takingownership for their products and
feeling like they actually makedecisions about what's going in
them and invested in it from amotivation perspective. But you
(14:45):
need, obviously, that level ofcontrol, particularly if you're
releasing the next generation ofEVs or or sports cars or
whatever the or the new Ravthought, whatever the things are
that. You're working to. Youneed that level of control and
transparency. How does it, inpractical terms, you know, what
does it? Does it? How do youexert these two country almost
(15:11):
contradictory kind of likepulls?
Lucas Smith (15:18):
Yeah, I would say you put your finger on one of
the key challenges, right? Iwould definitely agree with
that. I think, you know, I don'tclaim there's a one size fits
all right? It kind of doesdepend 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
(15:39):
goal of funding products. Noteverything is funded that way
for us, right? So one importantthing we have done to help
understand that control is justto do it's basically just a
quadrant map of our currentproducts, or our current area,
business areas, and how they arefunded, right? So the the goal,
(16:02):
right, is, you know, maybe your,your ideal dream is someone is
paying for that product, oryou're getting funding directly
into that product team, right?
That gives them the mostautonomy, right, and the most
ability to quickly make changesto that product, right? So,
knowing how quickly and howcritical it is that you can
(16:22):
adapt that product that wouldencourage you or be able to have
discussions within yourorganization to say, look, we
really need an independentstream that doesn't go through
additional brutal chains rightto do this product team and
allow them to adapt quickly.
Some of our products are fundedby external stakeholders within
(16:43):
the organization. So we mighthave you know, so the first
level that is our ideal isproduct funding directly to that
team. Maybe second level is likea long term funding structure,
but we still have to work withstakeholders 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
(17:06):
level two. We currently our goalis to get everything to level
two right, where we have a longterm thought of products,
funding stream, but we at leasthave engagement within the
enterprise. We havestakeholders. We know who we
need to talk to, so thatthey're, they're key, you know,
stakeholders and contributors tothat. We do have things that are
(17:28):
operate more like a projectfunding, right? So we call that
level three. So those are thingsthat we have to go before
approval board, right, and getfunding for a certain amount of
time, and we have to continuallydo that so that that gives more
control to the organization. Anda lot of times they feel better
about that funding, but it meansyou have less adaptability right
(17:51):
to change, and the team has lesseconomy with that. And then
level four, which is we try toavoid, but we do have some of
this just because of ourstructure is where we're just
kind of doing staff lock rightwhere we are. We are basically
putting people into someoneelse's product team so that
that's that's maybe a nuance ofthe corporate structure and the
(18:13):
different companies withinToyota, but just mapping your
products across those wasactually a really powerful
exercise for us, and it reallyjust helps us to see, okay, what
type of work, what type ofproducts do we or funding do we
take on? What's our goal? Can weget, you know, this one is stuck
in level three, can we make acase to move to more consistent
(18:35):
funding for this product becauseof the the market needs, or is
it okay that it stays there likeit's not a big deal. So I think
that was actually a really keyexercise for us, and allowed us
to have discussions internallyand with different parts of
Toyota to say, look, if you'retelling us we really need to be
innovative, we need to beadaptive, we need to change or
(18:56):
we need to catch up to themarket in some way, then you
have to fund it or structure itin 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 entityinside 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 moneycoming in, you know, it's a
(19:24):
financial product. It's, youknow, it's something that people
are buying or using orsubscribing to, either as a
shared revenue, you know, thatyou get a slice of a bigger pie,
or whatever. Second one is, onesthat are internal systems that
are very much have sponsorshipand and they're like, yes, we
(19:47):
need to have this call center,or we need to have this for a
period, but, but the money is alittle bit less direct. And then
the third one are theseprojects. You know, I was going
to a consuming package goodsorgan. Organization few weeks
ago, and they have, they fire upthese, oh, we need an app that
does this, you know, whatever itis, something about diapers, or
(20:10):
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 verylittle. I mean, it's kind of
like a bit, yeah, they try to beoutcome centric. They try to be
user centric. But at the end ofthe day, you're satisfying a
stakeholder with a big pot ofcash and and then so you deliver
(20:33):
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 atthe Dutch natural history
museum, and she said, we'rereally 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,
(20:56):
nobody maintains them becausethey haven't moved it into two
or one, and because of that,there's this thing. So it's
funny, I think that that modelis actually incredibly
universal, even though I I'd notreally thought about it until
you shared it with me, when,when we met in Orlando, what,
(21:16):
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 itkind of in the Agile product
sense, but if you look at itfrom an organization
perspective, what you're lookingat is, do you have a Profit and
Loss Center? Do you have a P andL center as an organization that
is getting revenue in for yourproduct, making decisions about
it? Or are you operating just asa cost center? A cost center now
(21:43):
has to get approval to spendmoney from someone else, so
that's kind of your level one,level two, and if you're a cost
center, but someone else outsideis deciding what they need to do
and funding you now, now you'rea level three project, right? So
that's the structure that a lotof people deal with and I think
it's okay to recognize that,right? And just plot it out like
(22:04):
there are trade offs, right?
There are trade offs betweeneach of those types of work.
Well,
Dave West (22:09):
the biggest challenge that level three, from my
experience, from talking topeople have, is the longevity
element. You know that you can'ttechnology. You know, software
doesn't die. You have to killit. I hate to say that, and
that's an awful analogy, but youreally do. And so there's all
these things sitting around thatare no longer maintained
(22:32):
adequately, or they're sort ofmaintained in the sort of
hidden, you know, I I rememberwhen I was working at commercial
union 100 years ago, there wasthis one app that was never
funded, but we always maintainedit. And it was just you, just
protect you, just move thosebecause we had to do time
sheets. And I just, I the time Ispent on the app, I just put on
(22:54):
my local project. And I knowthat was really awful, but
somebody had to maintain it. Itwas 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 gettingfunded, there's a cost, you
know? There's a buffer cost thatyou're adding to each of those
to basically maintain everythingelse, right? It's like, okay,
your first app costs you amillion dollars. Well, your
second one is 1.5 you know, itreally costs a million, but we
need half a million just tomaintain the old ones that you
(23:28):
don't fund, right, exactly.
Dave West (23:31):
And of course, that leads to massive amount of
technical debt. It leads to, youknow, you've not deployed the
latest security patch. It leadsto all of those disasters. I you
know, there's been many an auditof an existing organization, and
they found like, 400 apps thatnobody knew anything about. But
(23:54):
that's just the that's just theway of the world. Because, you
know, we are a little bit likemagpies, oh new shiny thing. Oh,
new shiny thing. And that's thereason why I think your strategy
of trying to get to at least twois admirable, because then you
have a product roadmap, you havea, you know, an operational
roadmap, you you know, you havea value proposition in terms of
(24:16):
an economic roadmap. You know, Ithink that that's really, really
really important. Let's youmentioned that some of these
programs are incrediblycomplicated, particularly at the
program level, so aboveinitiative and above product
dependencies, what happens withdependencies? How do you because
(24:38):
the worst thing in the worldfrom a product team is to be
dependent on somebody else'sroadmap. It just, it just makes
everything harder. How do you, Imean, you have OEMs. OEMs have,
you know, this is just, I wastalking to BMW about two years
(24:58):
ago, and and. Way, the number ofvariants that they have and the
number. And they showed me thesort of like the mathematical
equation for variants in theirsystem. And it was, you know, it
took up the entire board. It wasso complicated. What do you do
at Toyota connected becausesimplicity, it's a key premise
(25:21):
of Toyota management system. Andyou know, you do a really good
job of simplifying anything. Howdo you manage dependencies?
Lucas Smith (25:29):
And that's that, that is a good question. So I'll
try not to overload with toomuch, because vehicle programs
not everyone's dealing with,right? But those are, those are
the worst right in terms ofmanaging it from a base level,
you're just, you're addingstructure, minimal structure,
right as needed. We do find thatsome type of quarterly planning
(25:52):
helps a lot. So a quarterly roadmapping, 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, timewise, that we're planning stuff,
right? So, So visualizing that,doing quarterly planning with
(26:12):
all of our teams, allowing time,ahead of time to work and say,
hey, you know, we're going to belaunching this feature here.
What are the three things thatare dependent on it? Let's get
agreement from the differentteams and timeline on that.
That's kind of the base firstlevel right between products.
And we try to manage most of thethings just product to product
there. When you get toinitiatives, right initiatives
(26:36):
kind of feed into thoseproducts. So it doesn't
necessarily add a lot ofdependencies other than what we
can manage in quarterly planningprogram level. Absolutely right?
To your point, you know, we havemaybe a supplier who's adding a
new we call it the head unit isthe dash unit in the vehicle,
(26:57):
right? So we're designing a newone. They would be called our
tier one supplier. They're aglobal company, you know,
Fortune 100 company. They'regoing to be building 10 million
of these for us. But they havetier two supply. Two. Two would
be someone supplying them. Tierthree would be someone supplying
them, right? So those, thoseprograms, especially because
(27:17):
we're dealing with hardware, wewe have to plan out as kind of a
four or five year cadence,right? So we know enough about
building cars right that we knowroughly how much time it takes.
And we're adding buffers. Andwe're adding buffers between
finalization of a physicalproduct, finalization of the
(27:39):
software product integrationpoints right before we go into
pre factory builds, right? So wedo things like hand built
vehicles that we do testing onright before everything comes
together. And then there'scouple months before that goes
into a factory, right? So Iwould say that that just depends
on your risk. Right? For us,stopping a factory is like
(28:01):
millions of dollars a day,right? And when we, when we
build a product, it's got to goin there, it's got to work the
first time, so we are willing topay and have integration pay for
slower stuff ahead of timebecause of that risk. Yeah. Now,
if you can standardize, right,like that. That is a key
discussion for us. Right is, ifyou're, if you're changing your
(28:24):
your software, underlyingplatform every time, or the
processing chips on the vehicleevery time. Now, now you've
lost, you know, you have to redoa 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 createdifferentiation, but don't add a
(28:47):
lot of complexity, right? So,you know, frankly, Android and
Apple have this has been achallenge for them. Even screen
size differences on devicesmeans that your apps have to be
redesigned. They have to bedesigned in a way that they
scale and strength and contract.
So we have huge vehicle line. Wehave all sorts of different
(29:11):
screen sizes, but picking thosescreen sizes and standardizing
them on them, or having a fixedset is one way to simplify it,
right? And then, you know, socreating that, or designing that
from up front and saying, Look,we're not going to redesign the
multimedia system betweenCorolla and between Alexis,
(29:31):
right, like we might brand itdifferently, and we might have
different touch and feel to it,or different sounds that make it
sound more premium. But you'renot if you build a completely
different software product forthose where you allow the
organization or stakeholders todemand that you've just
duplicated your cost andmaintenance. So you gotta, you
gotta pick what is core andthen, but allow differentiation,
(29:55):
because stakeholders in yourcompany are always going to want
that if you've got multiplelevels of brand. And like, we
have a chief engineer forCorolla, right? And he argues
with us if we want to increasethe cost on something by five
cents a vehicle, right? Becauseto him, that matters a lot,
right? Whereas, you know theLexus LX, you know, they're
like, Okay, yeah, we want you toadd a couple dollars here,
(30:17):
because we want a more premiumfeel. We want a more premium
thing. So how do youdifferentiate 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 littlebit of a different camera
resolution, you know, morestorage space, you know, those
are things that actually don'timpact your software very much,
(30:38):
but they impact the userexperience, which create a
differentiation. So those arethings, just increasing the size
of your screen, increasing theresolution, maybe the speed of
responsiveness, maybe thesounds, the touch and feel. We
do spend a lot of time trying tothink through how to manage
reducing those, those number ofpermutations, 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 obviouslysmall releases before that, but
that they've, they've managed topersuade their customers to have
have a level of understandingthat many of us could only dream
(31:26):
about, and they have sort ofbrand following in a different
way. But then you look at likeTesla, the fact that when I got
my Tesla, there was twodifferent software platforms
running, you know, when theybrought out the the the the Y
and my s were very different.
(31:48):
Right now, it's all the same.
They've consolidated. Thescreens are the same.
Everything's exactly the same,and people seem to be okay with
it. But when you you know Alexisand a normal toy editor, as it
were, is, it's very interesting.
But reducing that complexity, Ithink, is crucial to managing
(32:10):
that level of dependencies anddeciding what core and context,
what differentiates, what makesus 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 aexpectations of updates, right?
So, you know, Apple, they have,you know, it's a, it's a good
model, because people thinkabout 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
(32:41):
phone every year. We update ourvehicle every year, but we do
major updates every three years.
Yeah, then you have kind of yourOS level, which is our firmware,
our sensor management, right?
Our vehicle platform, Applemight update that a couple times
a year, right? We we're on maybea twice a year update for that,
(33:02):
right? And only certain parts ofit we can update, and we're
trying to improve those, thosedifferent parts. But then on top
of that, what the customers seeare the app side, right? So, so
the even though Apple isn'tupdating their OS or their
phone, you get updates everyday, every week, you know, on
the different apps, and thatkeeps you happy, because you're
like, Oh, I got something new. Igot a new feature. Got a new
(33:23):
thing. So those are things, youknow, we can update stuff from
the vehicle. If something liveson the cloud. We can update that
very quickly. So we build, webuild the voice assistant that
runs on Toyota and Lexus, and wecan add new skills. We can add
new things behind the scenes onthat very quickly. Now we're
talking about modifying firmwareon a sensor on the vehicle. Now
(33:48):
we've got a lot much longerplay, because there's a lot more
vendors, a lot more testinginvolved. Now if we're talking
about needing to add a newsensor to enable a new product,
now that's multi year, so thatthose time horizons are
important to think about. Andwhen you come up with new
product ideas or new features,you have to know where those go.
Are this? Can we manage this inthe product? Or do we have to go
(34:09):
to the vehicle platform team? Ordo we have to get into the cycle
ahead of time, several yearsout, and say, Look, we're
thinking about one feature wejust released, actually, we did
this ahead of Tesla. Is theadvanced rear seat reminder,
where we've got, like, basicallya millimeter wave radar in our
(34:30):
Siennas that can detectheartbeats in back seats or in
the trunk. And so if you leave akid right in your car, it was
kind of designed around the hotcar. Yeah. So that took us
several years right from conceptat a hackathon where we could
show look, we know we can dothis, but it's a new sensor.
(34:51):
It's a new physical piece that'sgot 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. Wecan 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 havethese. Well, I'm not sure about
kids being like. I'm moreworried about dogs actually care
about my children, by the way,Lucas, I wasn't implying that I
don't they're just more vocalwhen they get locked in a car
(35:24):
than my poor dog.
Lucas Smith (35:26):
There's a smaller age range, typically, that they
would remind you, not remindyou, right? Like, if your four
year old, they're like, wait,you know, like, exactly what
happens? Unfortunately, it stillhappens. So,
Dave West (35:38):
yeah, it does. So it's great that that is a that
is a worthy cause. So just totake it all the way back and
that we need to finish. And Icould talk to you for hours
about this stuff, I I reallylove the whole, I mean, the
Machine that Changed the Worldis one of my favorite books of
all time, because it justboggles the mind how we built
(35:58):
cars and how we built theinfrastructure 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 automotivemanufacturing is one of the most
interesting things ever. And I'mdefinitely, well, I guess they
what they called petrol head,but I guess actually, I'm an
(36:19):
electric and petrol heads. Sothat's it. So I could talk for
hours, but so just take itforward. Thing, what was very
apparent from your conversationwhen you were talking about
dependencies Lucas, was that theultimately, the selection of the
products and the platforms, andmaking those right choices about
what is a platform, what is aproduct, and how do they fit
together, has everything aboutthis and and you have to be very
(36:44):
cognizant of your productarchitecture and continuously
monitor it and and ensure thatit's giving you that flexibility
time to market and that valuethat you seek is, is that a
challenge? Because it must bereally hard to change that those
(37:06):
product boundaries, even if itmakes sense to do so when you've
got this, this machine runningcontinuously around it? Yeah,
Lucas Smith (37:15):
no, no, absolutely right. And I think if you if
every time you have to add a newfeature to a product, you're
dependent on someone else, maybethat's a sign you should at
least evaluate those boundaries.
Now, maybe there's two thingsyou need to evaluate. One is
your horizontal boundaries,right? If? If, every time you're
adding a button or a widget orsomething, you're dependent on
(37:36):
someone else and change, we'llsay, we'll say this, you're
dependent on changes fromsomeone else. Yeah, and you
either need to look at thatboundary, or you need to look at
how you've done the technicalinterfacing between those
layers, right? So again, we'llgo back to a simple model with
the apps on your phone. Applehas the OS level, has made a
(37:57):
number of different calls andAPI calls and calls to different
sensors and getting differentdata like that that platform,
like every time you add a newfeature to an app, you don't
have to change the platform,right? You rely on it being
there, and you make changes toit. So just because we change an
app doesn't mean we don't haveto use something else that
(38:19):
someone has provided, ordifferent platform. But if every
time we require changes on them,then maybe it's a sign we either
haven't drawn the boundariesright, or technically we haven't
exposed the right level ofabstraction from that platform
that is usable, right? So Iwould say, keep track of those
things, right? Any any time youhave a cross area dependency,
(38:41):
it's at least something to lookat, right? Do you? Do you need
to change your boundary? Is thissomething that we need to
abstract better for APIs betweendifferent products, or between
platforms and products? Or isthis really just something we
can't solve just based on thistouches all the different layers
of our product, and Paul goesall the way from a physical
(39:01):
thing, right? I'm not going tochange the boundaries of my
product just because I need anew sensor on the vehicle, like,
that's a physical thing, right?
That if we don't have a radar inthe car, there's no way I can do
that product, right? I'm goingto have to require it. So
there's some things that arealways going to hit that, but it
is. It's definitely worthevaluating and keeping track of
(39:24):
that and saying, Okay, do wehave the right horizontal
boundaries from a productstandpoint, or do we have the
right kind of technicalstructure that enables our
products without too manydependencies on others?
Dave West (39:36):
Yeah, makes makes sense. Oh, I could talk all day,
and and I learned so much fromtalking to you, Lucas, thank you
for taking the time today. I Iknow our listeners are going to
be so thrilled to I mean, Toyotais obviously famous in our
world, right, you know? Andcoupled with actually, the
(39:56):
practical lessons of how you. Todeliver a product in a very
complicated environment. I lovethe the four different sort of
funding sort of models, as itwere. I love the, you know what
that has that implication onautonomy. I thought it was
really interesting. It allstarts with the definition of
(40:18):
product, and managing thosedependencies is a key
characteristic that you justmentioned again there. I think
that's super crucial. And at theend of the day, it's about
balancing agility with controland and how you do that, I think
is super interesting. So thanksfor 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 understandthat there are other people who
are experiencing the same thingsyou know, to to accomplish,
sometimes huge and great thingslike, require complexity, right?
So, you know, it's something youhave to embrace. There are
always trade offs. There's noperfect 100% answer to
(41:00):
everything. But you know thefact that you have an
opportunity to build something,especially if they can impact
people's lives and make adifference, even if it's a
little slower than you wouldlike, sometimes, you know,
that's a great place to be in agreat opportunity you
Dave West (41:16):
have that's great.
That's sage type words Lucas, bemindful of the of the system
that you're building, and makeit ensure it makes it
transparent, but also understandthat we're doing this to deliver
value which is, which is anincredible opportunity that we
all have in the industries andthe jobs that we do. So thanks
(41:36):
for your time, Lucas. I'll letyou get back to building that
next generation of car, which Ican't wait to hear more about.
But we'll take that offline, andI'll have over a beer sometime
in the future. And listeners,thank you for listening to
today's scrum.org, communitypodcast. If you liked what you
heard, please subscribe, sharewith friends, and of course,
(41:58):
come back and listen to somemore. I'm lucky enough to have a
variety of guests talking abouteverything in the areas of
professional Scrum, productthinking, and of course, agile.
Today we had, we had Luca Smith,PST and executive at Toyota
connected, talking about theAgile product operating model
with particular focus onportfolio planning and how an
(42:19):
organization as innovative andwith so much history and so much
scale that Toyota has isactually working in a very Agile
and creative way. So thanks forlistening, everybody. Scrummorg,
Music. Welcome to the scrum.org community
(00:04):
podcast, a podcast from the homeof Scrum. In this podcast, we
feature professional scrumtrainers and other scrum
practitioners sharing theirstories and experiences to help
learn from the experience ofothers. We hope you enjoy this
episode.
Dave West (00:20):
Hello and welcome to the scrum.org community podcast.
I'm your host. Dave West, CEOhere@scrum.org today's podcast
is part of our agile productoperating model series. The
focus of today's podcast isabout portfolio management. In
January, I presented a webinaron how portfolio management fits
in to a palm that webinar hascreated some quite interesting
(00:45):
conversations about portfoliomanagement and the like, and one
of those sets of conversationswas with one of our PSTs, Lucas
Smith, who's joining us today.
Lucas is a PST and an executiveat Toyota, connected now I know
some of the listeners mayalready know this. I'm a big fan
of cars, so apologies if Lucasand I accidentally start talking
(01:07):
about cars. We're going to trynot to today, and it's, it's a
bit of a challenge, so Butwelcome to the podcast, Lucas.
Lucas Smith (01:17):
Thank you very much. I'm glad to be here. It's
great,
Dave West (01:19):
great to have you.
Okay, so Toyota hugely famousfor building products. As you
know, I look out my window andand see two Toyota pickup trucks
actually outside my window atthe moment. You know, they also
are very famous for creatingmany of the ideas that have led
the next generation ofmanagement thinking in the 20th
(01:41):
and 21st century. So I'm reallyinterested on how they and you
at Toyo connected approachportfolio management. I mean,
many of the organizations wetalked to and many of the
conversations I had after thewebinar were very much like this
is incredibly challengingbecause it's bringing together,
(02:02):
you know, money, effort, reason,you know, all of the challenge,
business strategy, everything inone place, and it's a sort of
massive melting pot of pain formany organizations. So I'm sure
Toyota are doing it really,really well. So tell me a little
bit at how you manage yourinvestments and your portfolio
products.
Lucas Smith (02:26):
Well, that's a really good question, and I will
also acknowledge that it is avery difficult challenge. It's a
difficult challenge when you'rejust dealing with a web or an
application that doesn't maybehave hardware and supply chains
and things behind it, but it'seven bigger challenge when
you're dealing with acombination of a physical
(02:46):
product that you're producing inmultiple locations around the
world, the supply chain withthat, as well as the increasing
complexity of software and theinterconnectedness of vehicles.
So that's that's really whereour Toyota connected has been
focused is around the connectedvehicle, the complexities with
(03:07):
that. So we don't covereverything, so I'll speak
primarily to our area, but Ithink we've approached it in a
couple different differentlevels. So I think maybe for the
purpose of this will assume youhave some sort of strategy,
right, an organizationalpurpose, right? So, so that
that's kind of an assumption,because if you stray too far
(03:30):
outside of your purpose, youkind of get lost, and stuff
doesn't work so well. So well,we'll ignore that, that big
question, but it is a goodquestion. So I think, I think
for us, the first level isreally just trying to understand
what your products are, right?
That is ultimately a very keypiece to this. And frankly, we
have lots of discussions aroundwhat qualifies as a product,
(03:52):
whether it's something acustomer uses, whether it's
something you can have internalteams using. I think of it as
both. But in general, we thinkof a product as something that
is long lived, that we have tomaintain, that we add things to,
and we kind of have a rule ofthumb. It's kind of a funny one,
(04:13):
but if someone might call youand complain about it, and be
able to name it, it's probably aproduct, right? There's a lot of
things that go on under thescenes and under the hood that
you know, a customer might notsee, and they might be a
product, but really, you thinkabout some sort of packaging
those into something that'sthat's understandable for
(04:35):
someone, so that that's a roughrule of thumb. So I would say
first, first we look at, whatare our products, and then I
really do, I think some of theAPM material is that you pulled
together is really correct inthat understanding the life
cycle and the funding of thatproduct is really important. I
(04:56):
would say the life cycle. Andthe life stage of that product
is really the next thing we lookat. We tend to refer to things
as either in an explore extractor explore expand extract and
end of life. So it's a littlebit of that model, right? And
each of those stages has somedifferent characteristics to it.
(05:22):
So within a big organization,right? It's it's hard to to have
a single funding stream, asingle funding model that works
for everything. So it'simportant to understand those
distinctions. Because if you'retalking with finance, or you're
talking with your investmentcouncil or your approval board
if they're stuck in thinkingabout everything as like this is
(05:43):
an established product, and wehave to be very careful with it.
That's a different funding,different approval thought
process than something that's anexploratory that isn't an
established product yet. Sothat's kind of an important life
cycle. So I would quicklyexplain those as explore is
something that you don't have amarket for yet. You might, but
(06:05):
you're trying to test it out,right? So the important thing
about things and explore phaseis to move quickly, to move you
know, small team, small amountof funding, learn fast, don't
you're not building somethingthat's really polished, but
you're trying to identify ifthis is really going to become
(06:25):
something, if there's really aneed 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 theusers. Build something that you
know gives you a competitiveadvantage. And so there's,
(06:47):
there's a lot of there's a clearinvestment, reward return in an
expand phase, right? You've madea case. You know that people
want this, so you're investingin it. Once you have an
established product, especiallybig organizations, it's it
becomes harder to think of thatas something you want to take a
(07:08):
lot of risks on, right? So nowit moves a little bit more into
what I would call an extractphase, right? It's an
established product. You may notbe changing tons of things about
it, but you need to continue toinvest in it, you need some sort
of continuous stream. But you'rethinking about, you know, all
the things about user costs,cost to operate, cost to
(07:29):
maintain it. You know, userengagement with it, but you're
not going to necessarily makehuge changes on that product
without testing it, or betatesting it, or doing some sort
of Canary release, right, justbecause the risk is a lot
higher, and then at some point,right? It becomes end of life,
or it's something that you don'tcare about investing as much in
(07:51):
anymore, because you don't thinkthere's as much return. So maybe
you have to keep the lights on.
Maybe you have to maintain itright, while people migrate to
your new product, your newsystem, but you're you scale
down your funding, you scaledown that around it a lot, so
that that is kind of the base.
Now, not everything fits socleanly, right, but, but that's
(08:12):
kind of the goal that we that wethink towards, and it does
really help to understand thepurpose, the key metrics, the
key value proposition of thatproduct, right in the market or
internally, right? If you havesomething that's more of a
platform, because they kind offollow a similar, similar thing.
So that's kind of our product.
And then can
Dave West (08:36):
I just lean into that just for a second? Yeah. So
ultimately, you fund productsbased on value and the stage
they are in their life cycle andthe amount of risk or reward,
etc. And then you allow becausethis is a fundamental idea,
really. And then you allow teamsto determine the work based on
(08:58):
strategy and business road mapsand user needs and etc, etc. But
for your products, would yousay? And I know it's never black
and white completely, butgenerally, that that is a
principle that you at Toyotaconnected follow. I would
Lucas Smith (09:12):
say that is our that is our goal and principle
that we attempt to follow. Iwould say we have, I think the
product base is really what wehave gone for, because we
believe that's where the valuereally is in this size and the
complexity of organization. Wehave aligned on some
terminology. So I think it'sreally important to align on
(09:33):
what you call a product and whatisn't a product, right? Because
that can determine the fundingas well. So the the life stage
of a product kind of determineshow you fund it, how you
evaluate it. But not everythingfits that product as cleanly as
we would like, right? So wethink of products again as
something someone would use thatwe want to have a continuous
(09:56):
funding for a mostly stableteam. We. Have a clear market
users we can, we can gage thatabove that or separate from
that, we would, we refer tothings as initiatives, right? So
we'd like to keep things assimple as possible. So, you
know, a base initiative might bejust something that, okay. We're
(10:18):
upgrading features for EVvehicles, for example, and that
might affect a couple differentproducts, right? There's got to
be kind of a cohesive strategythere. If we can do it just with
the product areas or businessareas working directly with each
other, that's great. But if itgets complicated enough, if it
(10:38):
touches enough differentproducts, or maybe it goes to
multiple companies within Toyotaor multiple suppliers. Now you
you get a little bit of adifferent kind of structure to
that. So we kind of do those intwo flavors. One is what we call
kind of a cross product or crossorganization initiative, and
that's something that might lastsix months to two years. It has
(11:00):
a determined time span. We tryto do that around giving a small
initiative team. So we try togive a small initiative team
ownership of that initiative forthem to then work into the
product areas. Oftentimes, thatinitiative gets funding just
because it's easier tounderstand. So we might get okay
to get ten million to upgradefor EV teachers. So then they
(11:23):
would take that funding and say,okay, you know, 5 million of
that goes into the app, 2million goes here. So they're,
they're hopefully dishing thatout into the product areas. Now,
if we get big enough, we havewhat we call a program. Our
program is basically our multigenerational vehicle launches,
right? And so that that'ssomething that encompasses, on
(11:45):
our scale, probably 30 or 40different separate products,
maybe 40 different vendors whoare building things, or we're
integrating things into that,plus you're trying to plan that
for 2030, different factoriesaround the world and different
vehicle lines. So that is apretty complicated structure,
and we have our whole dedicatedprogram team that manages that.
(12:10):
So they are still definingthings that they want to go into
the products. So they're stillpushing things towards the
products. But we tend to fundthose programs, because they tie
into vehicle sales for us, sothat that's just at least our
world, I would certainly say,you know, keep, keep it as
simple as you can. Don't add alot of structure if you don't
(12:33):
have to, because structure addscomplexity. Then you get to all
sorts of challenges withintegration. Who's doing the
testing? How are you actuallyintegrating things, the
dependencies, across that? Sofor us, I mean, honestly, we
have kind of a full time teamdoing that for our vehicle
programs, but on the life cycle,right the base of it is, again,
(12:54):
the products and we build on topof them.
Dave West (12:57):
Yeah, that's really, really interesting, because in
the webinar, that's pretty muchhow we just, we didn't have the
mega, sorry, the program stuff.
I didn't talk about that becausethe people I interviewed aren't
quite of the scale of there'svery few companies in the world
that are of the scale of Toyota.
(13:18):
And, you know, cars are the mostcomplicated machine that
humanity mass produces. So, youknow, they get think it's very
likely that that layer isperhaps not necessary for for
many organizations, there arebut a few that that would but
the initiatives is interesting,because there's exactly what I
(13:39):
saw at the two or threecompanies that I talk to in
preparation for the webinar.
That's exactly how they work aswell. They fund the products.
And then, you know, long, longterm teams allow them a level of
autonomy around roadmaps andplanning. And then there's these
initiatives, you know, infinance, it was GDPR and
(14:02):
financial initiatives, you know,around certain laws that are
coming, and they push that. Andif they get to a certain size,
then they become initiativeswith an initiative owner and
maybe a team around them, whichthen drives that so, very, very,
similar, I think, from what howyou described it. So, all right,
(14:24):
so, and at the heart of the thea POM approach is this idea of
balancing agility with control,right? You you really want
empowered teams that are takingownership for their products and
feeling like they actually makedecisions about what's going in
them and invested in it from amotivation perspective. But you
(14:45):
need, obviously, that level ofcontrol, particularly if you're
releasing the next generation ofEVs or or sports cars or
whatever the or the new Ravthought, whatever the things are
that. You're working to. Youneed that level of control and
transparency. How does it, inpractical terms, you know, what
does it? Does it? How do youexert these two country almost
(15:11):
contradictory kind of likepulls?
Lucas Smith (15:18):
Yeah, I would say you put your finger on one of
the key challenges, right? Iwould definitely agree with
that. I think, you know, I don'tclaim there's a one size fits
all right? It kind of doesdepend 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
(15:39):
goal of funding products. Noteverything is funded that way
for us, right? So one importantthing we have done to help
understand that control is justto do it's basically just a
quadrant map of our currentproducts, or our current area,
business areas, and how they arefunded, right? So the the goal,
(16:02):
right, is, you know, maybe your,your ideal dream is someone is
paying for that product, oryou're getting funding directly
into that product team, right?
That gives them the mostautonomy, right, and the most
ability to quickly make changesto that product, right? So,
knowing how quickly and howcritical it is that you can
(16:22):
adapt that product that wouldencourage you or be able to have
discussions within yourorganization to say, look, we
really need an independentstream that doesn't go through
additional brutal chains rightto do this product team and
allow them to adapt quickly.
Some of our products are fundedby external stakeholders within
(16:43):
the organization. So we mighthave you know, so the first
level that is our ideal isproduct funding directly to that
team. Maybe second level is likea long term funding structure,
but we still have to work withstakeholders 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
(17:06):
level two. We currently our goalis to get everything to level
two right, where we have a longterm thought of products,
funding stream, but we at leasthave engagement within the
enterprise. We havestakeholders. We know who we
need to talk to, so thatthey're, they're key, you know,
stakeholders and contributors tothat. We do have things that are
(17:28):
operate more like a projectfunding, right? So we call that
level three. So those are thingsthat we have to go before
approval board, right, and getfunding for a certain amount of
time, and we have to continuallydo that so that that gives more
control to the organization. Anda lot of times they feel better
about that funding, but it meansyou have less adaptability right
(17:51):
to change, and the team has lesseconomy with that. And then
level four, which is we try toavoid, but we do have some of
this just because of ourstructure is where we're just
kind of doing staff lock rightwhere we are. We are basically
putting people into someoneelse's product team so that
that's that's maybe a nuance ofthe corporate structure and the
(18:13):
different companies withinToyota, but just mapping your
products across those wasactually a really powerful
exercise for us, and it reallyjust helps us to see, okay, what
type of work, what type ofproducts do we or funding do we
take on? What's our goal? Can weget, you know, this one is stuck
in level three, can we make acase to move to more consistent
(18:35):
funding for this product becauseof the the market needs, or is
it okay that it stays there likeit's not a big deal. So I think
that was actually a really keyexercise for us, and allowed us
to have discussions internallyand with different parts of
Toyota to say, look, if you'retelling us we really need to be
innovative, we need to beadaptive, we need to change or
(18:56):
we need to catch up to themarket in some way, then you
have to fund it or structure itin 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 entityinside 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 moneycoming in, you know, it's a
(19:24):
financial product. It's, youknow, it's something that people
are buying or using orsubscribing to, either as a
shared revenue, you know, thatyou get a slice of a bigger pie,
or whatever. Second one is, onesthat are internal systems that
are very much have sponsorshipand and they're like, yes, we
(19:47):
need to have this call center,or we need to have this for a
period, but, but the money is alittle bit less direct. And then
the third one are theseprojects. You know, I was going
to a consuming package goodsorgan. Organization few weeks
ago, and they have, they fire upthese, oh, we need an app that
does this, you know, whatever itis, something about diapers, or
(20:10):
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 verylittle. I mean, it's kind of
like a bit, yeah, they try to beoutcome centric. They try to be
user centric. But at the end ofthe day, you're satisfying a
stakeholder with a big pot ofcash and and then so you deliver
(20:33):
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 atthe Dutch natural history
museum, and she said, we'rereally 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,
(20:56):
nobody maintains them becausethey haven't moved it into two
or one, and because of that,there's this thing. So it's
funny, I think that that modelis actually incredibly
universal, even though I I'd notreally thought about it until
you shared it with me, when,when we met in Orlando, what,
(21:16):
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 itkind of in the Agile product
sense, but if you look at itfrom an organization
perspective, what you're lookingat is, do you have a Profit and
Loss Center? Do you have a P andL center as an organization that
is getting revenue in for yourproduct, making decisions about
it? Or are you operating just asa cost center? A cost center now
(21:43):
has to get approval to spendmoney from someone else, so
that's kind of your level one,level two, and if you're a cost
center, but someone else outsideis deciding what they need to do
and funding you now, now you'rea level three project, right? So
that's the structure that a lotof people deal with and I think
it's okay to recognize that,right? And just plot it out like
(22:04):
there are trade offs, right?
There are trade offs betweeneach of those types of work.
Well,
Dave West (22:09):
the biggest challenge that level three, from my
experience, from talking topeople have, is the longevity
element. You know that you can'ttechnology. You know, software
doesn't die. You have to killit. I hate to say that, and
that's an awful analogy, but youreally do. And so there's all
these things sitting around thatare no longer maintained
(22:32):
adequately, or they're sort ofmaintained in the sort of
hidden, you know, I I rememberwhen I was working at commercial
union 100 years ago, there wasthis one app that was never
funded, but we always maintainedit. And it was just you, just
protect you, just move thosebecause we had to do time
sheets. And I just, I the time Ispent on the app, I just put on
(22:54):
my local project. And I knowthat was really awful, but
somebody had to maintain it. Itwas 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 gettingfunded, there's a cost, you
know? There's a buffer cost thatyou're adding to each of those
to basically maintain everythingelse, right? It's like, okay,
your first app costs you amillion dollars. Well, your
second one is 1.5 you know, itreally costs a million, but we
need half a million just tomaintain the old ones that you
(23:28):
don't fund, right, exactly.
Dave West (23:31):
And of course, that leads to massive amount of
technical debt. It leads to, youknow, you've not deployed the
latest security patch. It leadsto all of those disasters. I you
know, there's been many an auditof an existing organization, and
they found like, 400 apps thatnobody knew anything about. But
(23:54):
that's just the that's just theway of the world. Because, you
know, we are a little bit likemagpies, oh new shiny thing. Oh,
new shiny thing. And that's thereason why I think your strategy
of trying to get to at least twois admirable, because then you
have a product roadmap, you havea, you know, an operational
roadmap, you you know, you havea value proposition in terms of
(24:16):
an economic roadmap. You know, Ithink that that's really, really
really important. Let's youmentioned that some of these
programs are incrediblycomplicated, particularly at the
program level, so aboveinitiative and above product
dependencies, what happens withdependencies? How do you because
(24:38):
the worst thing in the worldfrom a product team is to be
dependent on somebody else'sroadmap. It just, it just makes
everything harder. How do you, Imean, you have OEMs. OEMs have,
you know, this is just, I wastalking to BMW about two years
(24:58):
ago, and and. Way, the number ofvariants that they have and the
number. And they showed me thesort of like the mathematical
equation for variants in theirsystem. And it was, you know, it
took up the entire board. It wasso complicated. What do you do
at Toyota connected becausesimplicity, it's a key premise
(25:21):
of Toyota management system. Andyou know, you do a really good
job of simplifying anything. Howdo you manage dependencies?
Lucas Smith (25:29):
And that's that, that is a good question. So I'll
try not to overload with toomuch, because vehicle programs
not everyone's dealing with,right? But those are, those are
the worst right in terms ofmanaging it from a base level,
you're just, you're addingstructure, minimal structure,
right as needed. We do find thatsome type of quarterly planning
(25:52):
helps a lot. So a quarterly roadmapping, 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, timewise, that we're planning stuff,
right? So, So visualizing that,doing quarterly planning with
(26:12):
all of our teams, allowing time,ahead of time to work and say,
hey, you know, we're going to belaunching this feature here.
What are the three things thatare dependent on it? Let's get
agreement from the differentteams and timeline on that.
That's kind of the base firstlevel right between products.
And we try to manage most of thethings just product to product
there. When you get toinitiatives, right initiatives
(26:36):
kind of feed into thoseproducts. So it doesn't
necessarily add a lot ofdependencies other than what we
can manage in quarterly planningprogram level. Absolutely right?
To your point, you know, we havemaybe a supplier who's adding a
new we call it the head unit isthe dash unit in the vehicle,
(26:57):
right? So we're designing a newone. They would be called our
tier one supplier. They're aglobal company, you know,
Fortune 100 company. They'regoing to be building 10 million
of these for us. But they havetier two supply. Two. Two would
be someone supplying them. Tierthree would be someone supplying
them, right? So those, thoseprograms, especially because
(27:17):
we're dealing with hardware, wewe have to plan out as kind of a
four or five year cadence,right? So we know enough about
building cars right that we knowroughly how much time it takes.
And we're adding buffers. Andwe're adding buffers between
finalization of a physicalproduct, finalization of the
(27:39):
software product integrationpoints right before we go into
pre factory builds, right? So wedo things like hand built
vehicles that we do testing onright before everything comes
together. And then there'scouple months before that goes
into a factory, right? So Iwould say that that just depends
on your risk. Right? For us,stopping a factory is like
(28:01):
millions of dollars a day,right? And when we, when we
build a product, it's got to goin there, it's got to work the
first time, so we are willing topay and have integration pay for
slower stuff ahead of timebecause of that risk. Yeah. Now,
if you can standardize, right,like that. That is a key
discussion for us. Right is, ifyou're, if you're changing your
(28:24):
your software, underlyingplatform every time, or the
processing chips on the vehicleevery time. Now, now you've
lost, you know, you have to redoa 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 createdifferentiation, but don't add a
(28:47):
lot of complexity, right? So,you know, frankly, Android and
Apple have this has been achallenge for them. Even screen
size differences on devicesmeans that your apps have to be
redesigned. They have to bedesigned in a way that they
scale and strength and contract.
So we have huge vehicle line. Wehave all sorts of different
(29:11):
screen sizes, but picking thosescreen sizes and standardizing
them on them, or having a fixedset is one way to simplify it,
right? And then, you know, socreating that, or designing that
from up front and saying, Look,we're not going to redesign the
multimedia system betweenCorolla and between Alexis,
(29:31):
right, like we might brand itdifferently, and we might have
different touch and feel to it,or different sounds that make it
sound more premium. But you'renot if you build a completely
different software product forthose where you allow the
organization or stakeholders todemand that you've just
duplicated your cost andmaintenance. So you gotta, you
gotta pick what is core andthen, but allow differentiation,
(29:55):
because stakeholders in yourcompany are always going to want
that if you've got multiplelevels of brand. And like, we
have a chief engineer forCorolla, right? And he argues
with us if we want to increasethe cost on something by five
cents a vehicle, right? Becauseto him, that matters a lot,
right? Whereas, you know theLexus LX, you know, they're
like, Okay, yeah, we want you toadd a couple dollars here,
(30:17):
because we want a more premiumfeel. We want a more premium
thing. So how do youdifferentiate 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 littlebit of a different camera
resolution, you know, morestorage space, you know, those
are things that actually don'timpact your software very much,
(30:38):
but they impact the userexperience, which create a
differentiation. So those arethings, just increasing the size
of your screen, increasing theresolution, maybe the speed of
responsiveness, maybe thesounds, the touch and feel. We
do spend a lot of time trying tothink through how to manage
reducing those, those number ofpermutations, 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 obviouslysmall releases before that, but
that they've, they've managed topersuade their customers to have
have a level of understandingthat many of us could only dream
(31:26):
about, and they have sort ofbrand following in a different
way. But then you look at likeTesla, the fact that when I got
my Tesla, there was twodifferent software platforms
running, you know, when theybrought out the the the the Y
and my s were very different.
(31:48):
Right now, it's all the same.
They've consolidated. Thescreens are the same.
Everything's exactly the same,and people seem to be okay with
it. But when you you know Alexisand a normal toy editor, as it
were, is, it's very interesting.
But reducing that complexity, Ithink, is crucial to managing
(32:10):
that level of dependencies anddeciding what core and context,
what differentiates, what makesus 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 aexpectations of updates, right?
So, you know, Apple, they have,you know, it's a, it's a good
model, because people thinkabout 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
(32:41):
phone every year. We update ourvehicle every year, but we do
major updates every three years.
Yeah, then you have kind of yourOS level, which is our firmware,
our sensor management, right?
Our vehicle platform, Applemight update that a couple times
a year, right? We we're on maybea twice a year update for that,
(33:02):
right? And only certain parts ofit we can update, and we're
trying to improve those, thosedifferent parts. But then on top
of that, what the customers seeare the app side, right? So, so
the even though Apple isn'tupdating their OS or their
phone, you get updates everyday, every week, you know, on
the different apps, and thatkeeps you happy, because you're
like, Oh, I got something new. Igot a new feature. Got a new
(33:23):
thing. So those are things, youknow, we can update stuff from
the vehicle. If something liveson the cloud. We can update that
very quickly. So we build, webuild the voice assistant that
runs on Toyota and Lexus, and wecan add new skills. We can add
new things behind the scenes onthat very quickly. Now we're
talking about modifying firmwareon a sensor on the vehicle. Now
(33:48):
we've got a lot much longerplay, because there's a lot more
vendors, a lot more testinginvolved. Now if we're talking
about needing to add a newsensor to enable a new product,
now that's multi year, so thatthose time horizons are
important to think about. Andwhen you come up with new
product ideas or new features,you have to know where those go.
Are this? Can we manage this inthe product? Or do we have to go
(34:09):
to the vehicle platform team? Ordo we have to get into the cycle
ahead of time, several yearsout, and say, Look, we're
thinking about one feature wejust released, actually, we did
this ahead of Tesla. Is theadvanced rear seat reminder,
where we've got, like, basicallya millimeter wave radar in our
(34:30):
Siennas that can detectheartbeats in back seats or in
the trunk. And so if you leave akid right in your car, it was
kind of designed around the hotcar. Yeah. So that took us
several years right from conceptat a hackathon where we could
show look, we know we can dothis, but it's a new sensor.
(34:51):
It's a new physical piece that'sgot 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. Wecan 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 havethese. Well, I'm not sure about
kids being like. I'm moreworried about dogs actually care
about my children, by the way,Lucas, I wasn't implying that I
don't they're just more vocalwhen they get locked in a car
(35:24):
than my poor dog.
Lucas Smith (35:26):
There's a smaller age range, typically, that they
would remind you, not remindyou, right? Like, if your four
year old, they're like, wait,you know, like, exactly what
happens? Unfortunately, it stillhappens. So,
Dave West (35:38):
yeah, it does. So it's great that that is a that
is a worthy cause. So just totake it all the way back and
that we need to finish. And Icould talk to you for hours
about this stuff, I I reallylove the whole, I mean, the
Machine that Changed the Worldis one of my favorite books of
all time, because it justboggles the mind how we built
(35:58):
cars and how we built theinfrastructure 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 automotivemanufacturing is one of the most
interesting things ever. And I'mdefinitely, well, I guess they
what they called petrol head,but I guess actually, I'm an
(36:19):
electric and petrol heads. Sothat's it. So I could talk for
hours, but so just take itforward. Thing, what was very
apparent from your conversationwhen you were talking about
dependencies Lucas, was that theultimately, the selection of the
products and the platforms, andmaking those right choices about
what is a platform, what is aproduct, and how do they fit
together, has everything aboutthis and and you have to be very
(36:44):
cognizant of your productarchitecture and continuously
monitor it and and ensure thatit's giving you that flexibility
time to market and that valuethat you seek is, is that a
challenge? Because it must bereally hard to change that those
(37:06):
product boundaries, even if itmakes sense to do so when you've
got this, this machine runningcontinuously around it? Yeah,
Lucas Smith (37:15):
no, no, absolutely right. And I think if you if
every time you have to add a newfeature to a product, you're
dependent on someone else, maybethat's a sign you should at
least evaluate those boundaries.
Now, maybe there's two thingsyou need to evaluate. One is
your horizontal boundaries,right? If? If, every time you're
adding a button or a widget orsomething, you're dependent on
(37:36):
someone else and change, we'llsay, we'll say this, you're
dependent on changes fromsomeone else. Yeah, and you
either need to look at thatboundary, or you need to look at
how you've done the technicalinterfacing between those
layers, right? So again, we'llgo back to a simple model with
the apps on your phone. Applehas the OS level, has made a
(37:57):
number of different calls andAPI calls and calls to different
sensors and getting differentdata like that that platform,
like every time you add a newfeature to an app, you don't
have to change the platform,right? You rely on it being
there, and you make changes toit. So just because we change an
app doesn't mean we don't haveto use something else that
(38:19):
someone has provided, ordifferent platform. But if every
time we require changes on them,then maybe it's a sign we either
haven't drawn the boundariesright, or technically we haven't
exposed the right level ofabstraction from that platform
that is usable, right? So Iwould say, keep track of those
things, right? Any any time youhave a cross area dependency,
(38:41):
it's at least something to lookat, right? Do you? Do you need
to change your boundary? Is thissomething that we need to
abstract better for APIs betweendifferent products, or between
platforms and products? Or isthis really just something we
can't solve just based on thistouches all the different layers
of our product, and Paul goesall the way from a physical
(39:01):
thing, right? I'm not going tochange the boundaries of my
product just because I need anew sensor on the vehicle, like,
that's a physical thing, right?
That if we don't have a radar inthe car, there's no way I can do
that product, right? I'm goingto have to require it. So
there's some things that arealways going to hit that, but it
is. It's definitely worthevaluating and keeping track of
(39:24):
that and saying, Okay, do wehave the right horizontal
boundaries from a productstandpoint, or do we have the
right kind of technicalstructure that enables our
products without too manydependencies on others?
Dave West (39:36):
Yeah, makes makes sense. Oh, I could talk all day,
and and I learned so much fromtalking to you, Lucas, thank you
for taking the time today. I Iknow our listeners are going to
be so thrilled to I mean, Toyotais obviously famous in our
world, right, you know? Andcoupled with actually, the
(39:56):
practical lessons of how you. Todeliver a product in a very
complicated environment. I lovethe the four different sort of
funding sort of models, as itwere. I love the, you know what
that has that implication onautonomy. I thought it was
really interesting. It allstarts with the definition of
(40:18):
product, and managing thosedependencies is a key
characteristic that you justmentioned again there. I think
that's super crucial. And at theend of the day, it's about
balancing agility with controland and how you do that, I think
is super interesting. So thanksfor 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 understandthat there are other people who
are experiencing the same thingsyou know, to to accomplish,
sometimes huge and great thingslike, require complexity, right?
So, you know, it's something youhave to embrace. There are
always trade offs. There's noperfect 100% answer to
(41:00):
everything. But you know thefact that you have an
opportunity to build something,especially if they can impact
people's lives and make adifference, even if it's a
little slower than you wouldlike, sometimes, you know,
that's a great place to be in agreat opportunity you
Dave West (41:16):
have that's great.
That's sage type words Lucas, bemindful of the of the system
that you're building, and makeit ensure it makes it
transparent, but also understandthat we're doing this to deliver
value which is, which is anincredible opportunity that we
all have in the industries andthe jobs that we do. So thanks
(41:36):
for your time, Lucas. I'll letyou get back to building that
next generation of car, which Ican't wait to hear more about.
But we'll take that offline, andI'll have over a beer sometime
in the future. And listeners,thank you for listening to
today's scrum.org, communitypodcast. If you liked what you
heard, please subscribe, sharewith friends, and of course,
(41:58):
come back and listen to somemore. I'm lucky enough to have a
variety of guests talking abouteverything in the areas of
professional Scrum, productthinking, and of course, agile.
Today we had, we had Luca Smith,PST and executive at Toyota
connected, talking about theAgile product operating model
with particular focus onportfolio planning and how an
(42:19):
organization as innovative andwith so much history and so much
scale that Toyota has isactually working in a very Agile
and creative way. So thanks forlistening, everybody. Scrummorg,
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!