00:00:01

One of the themes that have showed up in every plenary talk over the last two days is this notion of project to product. The next speaker is Dr. Mick Kersten, who literally wrote the book on it. Uh, his book, project to Product is generally a book that I admire and envy. When I first read the draft of it, uh, my first reaction was, I wish I were smart enough to have written a book like this. I, I think it's a very important book because it provides that last of language that can help span the business community and the technology community. And in his talk, he's actually going to also provide a historical frame that suggests that's a new, that's a part of a new management mode that gets created only once or twice in a century. So without further ado, Dr. Kersten.

00:00:51

Thank you Jean. And hello everyone. So, for the first decade of my career, I spent all of my time in the code and writing code and coming up with new programming technologies when I was working at Xerox Spark and new kinds of development tools, uh, because I actually thought we could code our way out of pretty much any problem. And the really interesting things I learned as we were building these tools that were making us more and more productive and keeping more and more of our time in the code, creating value is just that feeling of focus and flow and joy that you get when you're delivering amazing things for your users and your customers. And I got so interested in trying to scale some of these concepts. I actually went and did my PhD, uh, in connecting some of the lessons that we learned from programming languages, from software architecture to end-to-end value streams into how business flows through software delivery.

00:01:38

And my PhD supervisor and I, uh, decided to try out and see if these concepts could work for large scale enterprise IT organizations, and founded the company tasktop to, to experiment with this. So I then spent the last decade of my career in trying to apply these concepts and trying to understand why that same feeling that I had of, of being in the flow of my work and so engaged that both at an individual and at a team level was so different to what I was seeing when I was traveling the world. And, and learning to what it's like, what it's like for these organizations and for IT leaders, uh, to try to manage these very large complex code bases and businesses that were trying to transform. And the main thing I noticed is that that velocity that I was feeling of delivering value in open source and with my open source colleagues, that that was a hundred and something a thousand times slower than what I was seeing in the organizations with thousands and sometimes tens of thousands of developers.

00:02:31

So I realized that something was really wrong in the way that we were looking at software. And from all those journeys and lessons from all those amazing and very smart leaders, I actually came up with this notion of the flow framework on how we can bring this feeling to flow to organizations as a whole and survive what's happening in terms of the, this era of digital disruption. So I'm gonna go into some depth on the flow framework today, tell you a little bit about the flow metrics and tell you a few of the stories in the book project to product. Now, the first story, uh, this was a, this, this was the one that really completely changed my worldview. Uh, this was the first time I had had discussions with a CIO, and this was when Nokia was trying to transform itself. So Nokia realized, uh, a year before we all realized that there was gonna be a phone coming out of Cupertino that was gonna have a much larger screen.

00:03:16

And remember, Nokia got very good at building these phones. That was, that was my phone up there with shiny, beautiful stainless steel buttons, very elegant devices, uh, but with a very small and very limited digital experience. And they realized that in order to compete with Apple coming onto the market where the phone was going to be all glass, it wasn't just about being able to source glass capacitive touch screens, uh, they were going to need to be able to innovate in software. The entire user experience was now going to be based purely on software with these devices. It was just basically, you know, things were turning into a glass rectangle. And so at a leadership level, at a board level, they realized back in 2006 that they needed to transform. We started working with them, with them in 2007 and started to apply some of the concepts that we learned in open source and connecting developers to agile tools on connecting the value stream at Nokia.

00:04:05

So I got to watch this firsthand, and I got to see also that Nokia was becoming through this process at Poster Child for how you scale Agile. They brought in the best consultants, and Dean Leffingwell was there, the creator of the Scaled Agile framework. Uh, Ken Schrader was there helping them train everyone on Scrum. And the entire agile transformation was actually being measured because it was such a key part, such a key thing to the business. So I remember when I was at the Agile conference in Chicago, and Nokia was up on every slide as the absolute proof point that Agile works at large scale. And some of the ways that they were testing that Agile was actually being adopted across Nokia, uh, was with the Nokia test created by Nokia Siemens Networks, uh, which basically checked if teams were using the Agile tools and if they were trained on Scrum.

00:04:51

And what actually was happening is that while all this was going on, uh, the business side was thinking everything was on track because of the way that they were measuring their Agile transformation. Meanwhile, the result was actually a local optimization of their value stream. So they were making things go agile in the middle, but nothing was actually moving faster. End to end, the developers realized that I was working daily with developer managers, uh, and developers themselves interviewing them, and they realized something was fundamentally wrong. Someone as far as going to the board saying, we cannot do this. We'll, never, we'll, never, never actually meet these business objectives, but everyone thought everything was on track. And with this massive misstep and massive misunderstanding of something that the technical side understood that the business side didn't, uh, Nokia actually ended up losing the entire mobile market that it created in failing to transform.

00:05:38

So this is a profound lesson to me as I realized that measuring the wrong things, that measuring just this one silo, um, and using these proxy metrics of, are people trained on Agile? Are they using my Agile tool? The, the one that we deployed completely derailed this transformation and ended up destroying this company. So I think, uh, nothing illustrates this kind of local optimization of your value stream. Then John smart slide from this conference last year where you can see we are so freaking agile transformation's on track. But meanwhile, if you take the customer's perspective, so for Noia, they would need to innovate on new kinds of widgets on bringing an app store to market. They had no chance of doing it in a window that was meaningful. Now, that was, uh, back in around 2007. And the concern that I started increasingly getting over the last few years is that not enough has changed.

00:06:26

So as I worked more closely with large enterprise organizations, also very motivated and very driven to succeed in the digital transformations, I realized that there was, there were more fundamental problems. So this is another story of a top 25 bank by revenue. It was on its third transformation. The first two were agile transformation. This one was with DevOps. So everyone was sure it was down to succeed. Um, and even more interestingly, uh, the budget for this transformation was approximately a billion dollars, an incremental billion dollars for this digital transformation. That sounds like a lot, but you'll actually hear, see a bigger number in, in a couple slides. Um, the thing I learned, um, was that the way this transformation was being tracked was yet through another set of proxy metrics of activities, everything was being tracked as project plans, which to me was completely foreign because coming from open source and from this product mentality, we always tracked results, how people were adopting what we were doing, how much we were delivering, not this year long plan of different activities and, and cost and budgets.

00:07:23

And the amazing thing is that two years after the transformation was, sorry, two years into the transformation after its completion, um, things were successful in terms of the budget results, in terms of the project plans being hit. Everything looked green, but that green was an illusion, right? It's this watermelon effect where in the project plan, everything looks green, you look inside and everything's actually red. You interviewed any person on the business side on the, OR on the IT side, and they were saying that we're actually delivering less than before. Because again, these proxy metrics, these cost centers, um, and project management as the guiding force connecting the business and the technologists were just fundamentally broken. So the bottom line is that there's something wrong there. And we now have companies on the market that have been on the market for a while that are doing it, right?

00:08:10

So if you compare the stock price change of this, this particular decade of Amazon, who has their product value streams aligned to their organizational structure and to pizza teams, to their software architecture, microservices, you can see that've basically created a disruption machine. The tech giants who've done this properly, it's, they just get to choose what market they go into next. Meanwhile, those other companies have long realized they need to transform. Uh, some of the ones on the right who we've heard from at at this conference are actually doing better than others, but they're, things are still moving way too slowly, and they're actually moving so slowly right now in terms of these large scale transformations that at the current rate of disruption, half of the s and p 500 is predicted to be replaced in the next 10 years, or is forecast to be replaced in the next 10 years.

00:08:54

Um, we're seeing this move from industry segment to industry segment. So even the banks apparently aren't safe now. Uh, and this Bloomberg article, uh, from just last week indicates that banks have spent a trillion dollars on their digital transformations, but few have reaped those benefits. So we're talking about a trillion dollars I saw, I felt like I personally saw a billion dollars go up in flames at this one bank. You take this collectively, it's a trillion dollars, and very few are seeing the results. So there's just something very wrong with this approach because of course, all these organizations are very motivated. These are really good people with good intentions trying to succeed, not trying to lose their jobs or have their companies decline in the process. So I got to wondering, as I was writing the book, I was actually in the middle of the book, as you know, this rate of churn, this rate of disruption, the fact that we're all dealing with technologies changing and, uh, cloud runtimes and, uh, container, uh, orchestration methods changing.

00:09:49

What feels like almost on a weekly basis is, is this normal? Is this, is is what we're experiencing in our career is normal. And Jean pointed me at the work of Dr. Cla de Perez. So in 2002, Dr. Perez published a book, um, called Technological Revolutions and Financial Capital, where she actually zoomed out for us, uh, to look at the last five technological revolutions. So there've been five of these, the industrial revolutions, steaming railways, uh, steel and heavy engineering, oil and mass production, and what we're living today the age of software and digital. And the really fascinating thing about her work is that she identifies in the, in her models, that each revolution has two distinct periods. It has this installation period where some new means of production becomes very cheap. So think back to, uh, the early, uh, 19 hundreds where Henry Ford created the assembly line and all of a sudden creating many cars became cheap.

00:10:46

At that moment, there's all this financial capital, all this VC venture type capital that wants to make a huge return on that new means of production. And so in Detroit, in just that one city, at that point, you had over 300 car startups, which we don't remember the name names of today. Uh, but over time the new giants who master that new means of production form. And we have those giants today, those giants form, and we end up with this thing called the turning point where the just the creative destruction accelerates and accelerates the few companies like the Fords and the GMs in the last revolution who've mastered this new means of production, accumulate more and more of the world's wealth. And we're today at the point where the fang of Facebook's, Amazon, apple, Netflix, Google, Microsoft, as well as the bats, so Alibaba, Baidu, and Tencent, their combined worth is the equivalent of the GDP of Japan.

00:11:38

So those nine companies form a combined wealth of the third largest economy economy on the planet, and they're continuing to actually grow and disrupt further. So now what's happened is in past revolutions, uh, there's, after the turning point other, there's a dissemination of technology. And this is why I think this conference and what you heard Gene say earlier today about this concept being, being for the horses, not just the unicorns and the tech giants who figure this out. Um, that's what brings about the deployment period where the rest of the world's economy, uh, actually learns these new means of production masters and scales them. This is actually where inequality in past, uh, periods has actually gone down, and we get a much richer and wealthier economy and co Paris actually cause these things, the golden ages. So the question really is how do we collectively work to get through this turning point, get to the next golden age and make your company and your work a key part of that.

00:12:34

And, uh, so hint is that we're not going to do it with more project management because <laugh>, uh, in each of these revolutions, uh, we've come up with different managerial methods. They are factory systems, subcontracting, taylorism, Fordism, uh, and each of them helped with that particular means of production. Now as it turns out, project management came from Taylorism. It came from being treating people as interchangeable and fungible cogs and large machine, which you can actually do if you're building bridges or data centers or really large, large buildings and things of that sort. Um, but Henry Ford realized it doesn't work when you're doing more complex work. He realized he actually needed to invest in his staff, and Fordism came about. So trying to use Taylorism for creative work, trying to use project management and assuming you have that much certainty over two year, multiple year projects is just a completely flawed approach, uh, to innovating, to surviving, uh, this turning point in the age of software.

00:13:32

So to get get a better sense of this, I actually went and visited, um, one of our key customers and tried to understand how that company, how b the BMW group had survived the last turning point in the age of manufacturing. They are one of the companies, the brands, uh, that made it. And not so much in terms of how they did the production itself, but how the business and production were connected. And it was an absolutely fascinating journey. Um, you heard a little bit from BMW yesterday on terms of the IT side. This is purely on the car production side where I went into their most advanced plant, the MW Leic plant where the one and two series car cars are made and those cars come off the assembly line every, every 70 seconds. More interestingly, the I 3 9 8, the electric cars are made there and there was not a Gant chart in sight.

00:14:17

Um, but what you did see all of the plant was just the complete embodiment of these lean principles to precisely specify value by product, identify the value stream for each product, make value flow the interruptions, and let customer pull value from the, from the producer. These are from Jim Mack's book Lean Thinking and everything at the, but the plan embodies even the architecture and the, the building from space. You can see the one in the two series assembly line is very long. It's extensible. The buildings actually get extended as new manufacturing steps get added and it's completely automated. The I eight line, to my surprise, was the shortest thing thing. And in 772nd time my tack time, it actually had a 30 minute tack time. The people working on it were, uh, generalists and it was only the width of the building because this value stream was actually optimized for learning, not for high throughput and velocity.

00:15:04

And so now comparing car production and what we have today in enterprise it, everything was up around these integrated production lines and no notion of disconnected tool chains. You can't have disconnect in the, in that kind of value stream. Everything was managed as product and product that connected to business value rather than projects. Everything was architected around flow. So there's not one big large enterprise architecture that the I eight and I three shared there. Everything was architected around the flow needs of that particular value stream. Not technology layers not separating, uh, the persistence from the, from the data layer and so on. And from the engagement layer, everything was optimized end to end. So we always start end to end with customer centric measures like lead time, which happened to be the best predictor of car company performance in the market, um, because of course they embody what the customer experience is rather than optimizing in silos and looking how fast are we in, uh, in closing user stories.

00:15:53

Um, and everything was measured first in terms of business results rather than these proxy and silo metrics. So the key thing I learned from this is that we need to apply these concepts of flow of software delivery, but to do that we need to agree on what flows through software value streams. And we simply haven't done that through academia in in the industry. We know it's not function points in lines of code, but we need a common definition of what flows, what the flow items are. And that's the key point of the flow framework. Um, and remember, flow is about what customers pull. They don't pull releases, they pull what's in the releases, they want new features. Uh, they want fixes to defects. They'll, they'll make them choose your solution, the features and the quality of it, um, rather than the competitive solution. Um, risks are now a core part of software delivery.

00:16:37

So making sure that we have data privacy and security, um, as key to the market and to our customers. And technical debts are also a first class part. Infrastructure debts and resolving those debts is the first class part of software delivery. As we implement more features, we actually build up debts through taking shortcuts to get those features to market. So these are the four flow items, and these are mutually exclusive and comprehensively exhaustive. They're mey, which means these represent all the work that's done in your software value streams. So if you're using something like the Scaled Agile frameworks, which has a very rich, uh, and will refine taxonomy over of work items, then you might have dozens of those. Each of those work items actually maps into one of these flow items. So I'll give you a quick example now of what this looks like.

00:17:20

And uh, when I was first preparing these slides, Jean told me, uh, Mick, you need to explain the flow items just with up and down arrows because that's all executives will pay attention to. So this, this will explain everything purely through up and down arrows. Um, think back of your last push to market and pushes to market. Um, and those, those releases that, that you're putting out their success is really dependent on the features that you deliver, right? Because that is what customers, what users consume. As you do that. And as the business is wanting more and more of those features, uh, debts and risks just rise, quality goes down. And then this interesting thing happens that defect works goes up and up to the point where you can get into a debt spiral where defect work consumes all of the value stream, the business gets extremely frustrated.

00:18:05

'cause feature works goes down to zero. And this is the exactly the situation that Nokia found itself in, that developers understood why because they were building on a burning platform platform that was real and technical debt and that could never support an app app store, uh, the symbian operating system. They had to re-platform. But of course the business just won more features and just kept prioritizing more features and this drove that company into the ground. Now here's another version of that story. This is, uh, in 2003 when Bill Gates, uh, wrote the trustworthy computing memo. So the SQL slammer thing happened, uh, and Bill Gates actually said, we're gonna bring feature work down to zero across Microsoft's value streams. We're gonna work on security, we're gonna work on debt reduction, which no enterprise IT company co has ever said ever probably is. We're gonna stop all feature work now.

00:18:52

Um, and it's not that Microsoft didn't have competitive pressures, it's just that Bill Gates understood that zero sum game and these trade-offs and knew how to steer Microsoft around that and focus on debt work on. He couldn't re-platform the way he say Amazon has re-platform because their product portfolio is probably the most complex since it actually started the moment the age of software started. Um, they reduced debts and risks and then of course quality went up, feature work went up. And we now have the largest market cap company, the most valuable public company in the world as a partly as a result of this. And the interesting thing is that most other tech giants, most, many other unicorns have, have actually been through this. They've had these near death experiences where they're technical debt piled up, but they were able to steer their companies in the right direction.

00:19:34

Amazon spent almost a billion dollars on its re-platforming, but that actually produced AWS, LinkedIn has had multiple replatforming. And for each of the tech giants, uh, the advantage I think that they've had is that all of them have as their CEOA former software developer. So these flow framer concepts and, and these notions of these trade offs of debts and risks and defects, they're just innate if you've, you know, spent part of VQ building software. But we really need to bring some of that understanding and those concepts to today's business leaders. And that's really the goal of the flow framework. So I'll give you a quick overview right now of it, uh, and tell a few stories of some of these things that the flow framework has you track. So the first thing you start with is you define your products, your product portfolio. These are internal products, external products, uh, platform products.

00:20:20

And for each product value stream, you don't track how many user stories or issues were closed. You actually track each of the flow metrics. And so you've got this more abstract, high level, more business centric view of what flows. Um, the flow metrics are flow, velocity, flow efficiency, flow time and flow load, which I'll show you. And you correlate those flows to business results. So to some notion of value for an external product that could be revenue, uh, that could be active users, the cost and you do not track cost, uh, for how much development costs, how much operations cost you track cost per value stream. So all of the people involved in that product value stream, even the hosting cost of that value stream are the cost of the value stream. With those two things together, you can actually get to things like product, uh, lifecycle profitability.

00:21:04

You track the quality of the value stream and you track the happiness of the staff on the value stream. So not how happy all your developers are and how happy all your support people are, but how happy all the people on the product value stream are. So you have that early warning indicator if you've got an architectural problem, if you actually need to invest in architecture improvement for this value stream. And so I'll give you a couple examples right now of how these flow metrics can answer the key questions that have been so hard for especially for business leaders to answer and understand. So this is a story, uh, from DevOps Enterprise Summit in Vegas this past fall that Nationwide Insurance shared. So they were wondering, we worked with 'em closely and we actually looked at this end-to-end flow time, why it was taking 120 days to deliver value to customers to deliver new features to customers.

00:21:49

And of course, the gut reaction for this is we need more developers and CIOs are always thinking we, we need many more developers. But when you dig into the flow time, as they did a few years ago, um, they realized only two point half percent of the days spent delivering value to customers were in development. So doubling the developers would've had almost no result. There were issues of upstream and downstream processes that needed to get resolved and those were the bottleneck, not developers. And so this is why the concept of flow time is so important. Rather than optimizing that two point a half percent for user story open to user story closed in Jira, you have to take a more customer centric point of view and actually optimize the flow for your end-to-end value stream the way a car manufacturer does. Uh, as part of this, of course, we're always looking for where our bottlenecks are when you start thinking this way and we start thinking in terms of value streams.

00:22:40

And so this is one of my experiences actually that was quite interesting, where we were hiring more and more developers because hands on keyboards and, and writing code, you know, always to me seemed like the, uh, the most important thing, uh, having come from the background. And then we started realizing from what we were hearing while we dug into this, that we might have a ratio of developers to designers wrong because adding those developers was not producing more features at the rate that we thought, uh, you know, you actually look more closely. And the fact that developers had Photoshop open was probably a a an odd sign. But I actually dug into this a little bit and I realized that we had a ratio of one to 40 of developers to designers. Meanwhile, companies like Atlassian, companies like Dropbox had actually shifted one to nine ratio, one to six ratio because of how important user experiences and great user experiences are in today's consumer and in today's business applications.

00:23:27

So by tracking flow efficiency, you actually learn where the wait states are. If developers are waiting on wire frames, you know, you might have a problem there and you start having the right conversations. And that's how you actually do. You do that by tracking flow of efficiency. You see where things wait in an end-to-end value stream, again, not in a segment of the value stream 'cause you could have different weights in different ones of your value streams. Uh, then there's this other key one that I think a lot of you have probably experienced as well is why is delivery slowing as we add developers? This seems completely counterintuitive, um, but yet it happens all the time as complexity rises. And this one's really interesting and in, uh, the last few months of my trips of helping companies adopt the flow framework, this is actually one of the most common issues.

00:24:09

This shows up a lot in Dominican de Grandes book in terms of dependencies. But so often we see that values that architectures, the software architectures that we use are not actually aligned to the product value streams. It's kind of the opposite of what you see at Amazon with those microservices and that loose coupling between their product value streams. You've got these enterprise architectures, uh, that were made to look elegant and be future-proof in terms of extensibility. And it's the opposite of what you see in that BW plant where the I eight has its own highly optimized value stream. So flow velocity when you, for example, see why does it take us so long to resolve risks? Well, maybe you should have a value stream dedicated, uh, to your security framework because there's so much dependency on that security framework and you've just asked everyone to implement GDPR.

00:24:54

So one more story here. Why are the teams working on this particular product value stream less happy than the others? And this was an another kind of key lesson for me. Once you start measuring things like employee engagement or employee NPS for product value streams, you'll actually start to see this and you start to ask those kinds of questions. And in our case, we noticed that it was a flow load issue. So the issue was that we were putting so much feature load on this value stream, we were not allowing the developers to work on tech debt. They were completely overloaded with a feature backlog. And we knew this, we were gonna let them pay down the tech debt. We just didn't realize how much their engagement went down because they feel they felt like they were failing the company, which is exactly what happened at Nokia.

00:25:32

You, we actually have now studied forensically the employee engagement logs from Nokia. And that's what was happening. Employee engagements was going down 'cause developers wanted to fix those features, wanted to help the company succeed, but they were completely overloaded with tech debt and the flow load would've indicated that as well as the per value stream promoter scores or engagement scores. So the question is how do we do this? Um, we have to stop over focusing on the tools and the technologies and really put a layer of abstraction over the tool network. So basically you make sure that we've got these flow items connected end-to-end so that we can trace them and connect them in these end-to-end value streams. And then from that, generate these flow metrics. And it's not as hard as it seems because once you've got those flow metrics, you start getting these insights and they're simply a mapping and the modeling of the work that's happening across your entire tool network.

00:26:22

So just as a quick example, um, our work at tasktop, it actually starts, a lot of it starts in Salesforce. It'll start in Zendesk where those customer requests come in. Um, all of that goes into our product management tool. Work gets done in Jira, some of it goes to our, one of our partners Jira, uh, who help us with some of that work. But all of this is connected. And the really neat thing is once it's connected, once it's abstracted with these models, you can can measure these flow metrics and you can and actually see the flow of vis business value and these bottlenecks. So here's an interesting one. Uh, in one of our products we noticed that we had a very large feature backlog and we really needed to get through this feature backlog is is key to this product success. So as soon as you see that spike over there in flow load, so how many features that team has to work on and starts thrashing as they reprioritize things, uh, the flow time goes up almost instantly.

00:27:08

So it's now taking them way longer to get anything done. So what we did is we actually doubled the size of this team, uh, over here. And flow velocity didn't go up immediately. And then we got to really worrying because we realized that the core architecture for this thing was, was actually built in Scala. It was our first experience with Scala. And we, uh, the, our VP product development called Brian and I started wondering like, do we need to rip out the s scala? Are people way too slow to ramp up on it? And we actually thought, okay, well we should probably move this scala to things we know, like Java types type script. Uh, then what happens is the team said, no, you know what, let give us a chance. Let's, let's let's, you know, give us a couple sprints to ramp up. And we actually seen the flow velocity rise and improve.

00:27:48

Um, and we realized we were wrong and that the scholar stuff was fine and that they were able to ramp up. But this shows you, uh, the importance of having that same common language, that higher level of abstraction that's closer to business value in terms of the making it very easy for the team to show us that we were wrong. So really the goal here is to use these flow metrics, this flow framework, this this layer over top your agile tools and your DevOps practices to stop these local optimizations and basically having waterfall on the ends and agile in the middle. And to have this flow orientation where you actually measure flow, um, where you can stop using project management for visibility. And you actually have a direct visibility of what's flowing through your product value streams and what business results those are delivering. This is why companies like Google can actually kill products so easily because they realize if they're adding a bunch more features, it's not getting adopted more, it's not delivering more business results.

00:28:38

Well, it's time to kill that product. That doesn't happen in the world of project management. Um, it actually has a really significant effect of how you think about budgeting. So in budgeting and project management, you bake in all the risks upfront. Uh, it's not optimized for any of the principles of DevOps, of flow feedback or learning because you're trying to pretend that you understand, uh, the whole life cycle of this product rather than learning through leases and through through iteration. Whereas in a product oriented mindset, you actually invest further. When you see those business results happen, that's when you ramp up the teams. Uh, that's when you make further investment in this product when it's incrementally delivering results. Uh, another really important one is in a project oriented mindset. Again, that tailors mindset. You're bringing people to work, and I'm still, it drives me crazy whenever I see this, but, but we see this all the time.

00:29:24

You'll have developers assigned to eight, 10 different product values. So eight, 10 different projects. And guess what? Their productivity, not that you see it in project management, but has tanked, um, in a product oriented world, no developer or no team is assigned to more than one product value stream. They get to master the work, they get to master the insane complexity of the technology stacks they're working with today. And I think one of the most interesting and most impactful things that I've been noticing is the effects of product thinking on software architecture. So a lot of organizations are just putting a ton of effort on their business, their customer facing products. But as it turns out, if you actually look at the dependencies between your product value streams, you'll notice that your internal products, your platforms, your APIs, your data pipelines, those things are actually a bottleneck for all those external value streams.

00:30:12

And then you'll notice that your actual value stream network, the tool chain itself, uh, is one of your most important products because that's what makes all your developers productive. So to tech giants, this is kind of obvious. Satya Nadel said there could not be a more important thing for an engineer than to work on the systems that drive our productivity. Today's enterprise, it's completely flipped. All the good developers are on the stuff on top, and you've got your complete starting stuff on the bottom tech giant completely flipped. The highest paid developers are on the bottom layer on the developer productivity tools, the value stream network, then on the internal APIs and platforms that enable everyone to build great software. And this is why companies like BMW realize that their most important product is not that I eight, it's the factory, it's the plant. So in summary, um, disruption's going to accelerate.

00:30:57

So we just need better business. We've, I think we've figured out the technical tools, we figured out the ways of agile and DevOps. We now need better business tools to survive it. And today's IT practices of managing value of we through projects just won't work for the innovation that you need to survive. You need to shift from project to product at an organization level. Um, and you get a shot to connect the business with technology with this a simple, uh, language of the flow framework. So I, I do hope this works for you, um, to do that, connect your value stream network, define that product portfolio, track flow metrics and connect them to your business results and to your plans. So the ideas that you go from project and call centers, the product value streams from silos and these proxy metrics that lead us straight to flow metrics and business results and from fragmented value streams to an integrated value stream network. So, uh, you can learn more about the book over here. Uh, in terms of the help I'm looking for, it's really, I've been doing a ton of learning and how this works in terms of changing your organizational steering model, connecting to finance. So any stories or wins or or difficulties that you've had on that front, please reach out. And, um, with that, thank you very much.