Archive.fm

The Innovation Show

David Rogers - The Digital Transformation Roadmap Part 2

David Rogers - The Digital Transformation Roadmap Part 2   Mastering Digital Transformation: Insights from David Rogers   In this engaging episode, Aidan sits down with David Rogers, the author of 'The Digital Transformation Roadmap'. They delve into the significant challenges and strategies for digital transformation within organisations. Key topics include overcoming psychological and organisational debt, technical capabilities required for transformation, the importance of suitable technology, retaining key talent, and evolving organisational culture. David also shares insights on governance and iterative funding, emphasising the need for smart shutdowns and resource allocation. The episode is packed with practical examples, including successful digital transformations at Walmart and Netflix. David's profound experience and practical tools make this essential listening for business leaders and innovators.   00:00 Introduction and Welcome 00:13 Understanding Organisational and Technical Debt 02:18 The Importance of Tech Capabilities 03:29 Talent and Culture in Digital Transformation 05:19 Governance in Digital Transformation 08:27 The Role of Teams and Boards 20:00 Smart Shutdowns and Innovation Governance 26:07 The Corporate Innovation Stack 29:34 The Broken Model of Innovation 30:02 Governance Model for Innovation 30:42 Path Three Innovations: Challenges and Management 32:15 Innovation Structures and Strategies 34:12 Skipping Vision and Priorities 35:07 Walmart's Strategic Innovation in Online Grocery 41:24 Four Stages of Validation 49:21 Case Studies: Netflix and Diapers.com 54:37 Conclusion and Final Thoughts   Find David here:   Find Aidan McCullen for Keynotes and Corporate Workshops here:   David Rogers, Aidan McCullen, Digital Transformation, Innovation Governance, Iterative Funding, Corporate Innovation, Organizational Change, Innovation Strategy, Technical Debt, Psychological Debt, Innovation Boards, Startup Culture, Agile Methodology, Product Validation, Strategic Priorities, Business Validation, Smart Shutdowns, Innovation Stack, Customer Validation, Executive Insights  

Duration:
56m
Broadcast on:
24 Jul 2024
Audio Format:
mp3

Welcome back to part two of the digital transformation roadmap and the author of that book, David Rogers. Welcome back, sir. Thanks so much, Aidan. It's great to be here back with you. Great to be talking with you about the book. It's very happy. For me and David, we're just talking an offer about how I think overwhelmed people feel when they realize how much work there is to be done. They don't realize that this is a total overhaul of the way we have been taught to do business. And that is a huge challenge towards the end of the book. You talk about technical death, but a huge part of this is psychological death. Or, as I've heard it, call it sometimes, organizational death. It's like you have these layers of organizational processes that have built up over time and become very encrusted like a layer at the Earth's core. Just the same way that technology, when you talk about serious technical death, you've got these layers of systems. I've worked with banks. They got over 100 different applications that are all like trying to talk to each other. Some of them were built 30 years ago on coball and they're just layered up and unearthing. To really solve the underlying problems, you've got to do some archaeology. It's the same thing with the organizations, these processes and budgeting and resourcing and metrics and KPIs and how meetings are run and all of these different things at different levels of the company that actually all impact your ability to change and transform. And so just coming in and saying, we're going to change a piece here, we're going to have a team or a squad that does something different. That may be your starting point. That may be you're like chipping into the rock and your entry into this giant edifice, but it's got to keep going deeper and deeper and deeper if you're really going to drive the change. Even to your point about it's built on cobalt or some old language that is maybe not agile, maybe it's not even built for a cloud platform, et cetera, because that's to actually the skill set as well, because this has happened. We've had developers in the past using old languages and they were very resistant to use new languages mainly because they didn't understand them. And this talks that the capabilities link that's so important as well that maybe we'll just mention here because we probably won't get to it today. Yeah, that's the fifth step and as I what I call the roadmap in the book, the framework is about what I broadly call capabilities. And that's really three very interconnected things. It's about do you have the right kind of digital technology? This is information architecture in the cloud, modular, moving away from monolithic one gigantic application to decomposing it into lots of small microservices using APIs to connect them and so forth. And that's a technical shift, but actually what I've seen and learned, it's much more profoundly an organizational shift because when you actually change the information architecture into these small components organization follows technology. In this case, you have to set up individual teams to take ownership of each of these microservices. And that naturally brings about this kind of squad based or small multifunctional team or this kind of problem defined organizational structure, which you see all the big companies that are digital native that operate at scale that Google's the Amazon's and so forth. They all are built around this. So there's the technology, the talent, which is not just what are the technical skills we need, but also bringing them people with different backgrounds from inside or outside of our industry with entrepreneurial experience and not just experience working inside big companies. So what's the kind of range and mix of talent we need the talent gaps we have currently and how do we manage that, right, not just hiring people. It's not even just training people. It's also, I find one of the biggest stumbling blocks in that talent life cycle is retaining the key talent that you are going to need for your digital future because you can hire the smartest people if you've got a paycheck and the most talented product managers from roadblocks or Amazon or Meta or wherever if they are stuck in a morass of bureaucracy inside your big company, they are going to leave and then in addition to the talent, it's the culture really being clear. I know this is one of the things you talk about in your book, but really thinking about defining what is the culture we need as an organization. How does our culture need to shift and evolve if it's really going to match our strategy where we're headed as a company defining that clearly, communicating it, not just clearly but in ways that really stick with people using stories and symbols and symbolic action and so forth. Lastly, enabling that culture to actually happen by really looking carefully at all the processes in your company and figuring out which ones are blocking the cultural behaviors you want. How by changing those processes, can you make it easier for people to behave in the way that you want and the culture that you need. Take a step back and we're going to start with vision. Then we're going to talk about how to select your priorities and then how to validate as well all key steps in the digital fund for transformation roadmap. But one that often gets overlooked and one where so much of this all comes tumbling down is governance or step for managing growth at scale and I'm going to tee you up with a beautiful opening to this chapter as well. As you say, as you start to apply the process of experimentation to digital ventures in your own business, you are now ready to begin the next step of the DX roadmap, repeating this process at scale across your organization. Major challenges must be addressed, which ventures should be funded. Who will decide when to shut some down. What rules should be waived for new ventures at the start. Will the successes be handed off to the core business. What will you do with digital ventures that don't fit your current organizational structure. There are a plethora of these questions that we don't consider because we just go straight into building or falling over the idea after validation, which is an absolutely core step. You have to have a governance. David's going to take us through that over to you. What are the gaps I see where folks will come in who have been in a product role or in an innovation role and startup, or maybe you are that person who is working at meta or Amazon or Google and now you've been hired into a bank or agribusiness or professional services or an industrial manufacturer, and it's almost like you take for granted you like well I know what I've got to do on my team we've got to get close to the customer we've got to validate we've got to test we're going to find the problem. We've got to keep building and speed shorten that cycle of sprints. You take for granted the sort of organizational infrastructure that was around you in that other business and all of a sudden you're like wait why is everything so hard now that I'm working in a hundred year old consumer package goods company. It's because of the governance. Right. So, the challenge for leaders here is it's not enough. It might be your starting point your kind of organizational or sort of cultural proof proof case to have 18 build a great digital innovation that customers love and provide for the business. And then people start to get excited but if you're going to repeat this, you're going to scale this across an established business with different priorities competing priorities. You have to look at these rules and how do we manage. How do we manage different projects and priorities and goals and teams and experimentation at scale. So, part of this is understanding this is what we call a portfolio. I think about, and I know all those years to your show already know when you start the innovation journey you don't know what's going to work. And you've made you place bets right so you're thinking about a variety, a funnel if you will you're starting with pursuing a number of ventures knowing most of them will not work out. So how do we do this. Some of the key elements. One of the key elements I'll start on governance is this relationship between what I call teams and boards. And it's obvious say in the startup world, but it's just not there in in most established companies. So you've got two kind of groups of people that have to work together and they have to have very clear decision rights. So the first is the teams, those are the ones who are actually doing the innovation doing the experimenting in the rapid validation. And then you've got the boards and these are the folks who sponsor them who who give them initial green light say okay, we're giving you a little bit of runway, little time little money, go for it, come back. And we're going to make a decision on whether or not we continue to fund you. They're the ones who sponsor who green light and then who iteratively fun that team. But they also should be doing a bit more right like a great venture capital investor they should also be advising right they should be some of your wise counsel giving you perspectives on the market, making introductions. Because you're in a big company, one of the most important parts of this is actually acting as a liaison, or an advocate within the organization. So all of a sudden you want to do something next and you need something from legal or from supply chain, or you need an introduction to an outside partner who works with the marketing team. And this is again a critical role of this support this group called the board. And different names it might be an innovation board technology innovation board a a growth board is a term you'll hear the what you want to avoid. Common still just with a whole group of different companies last week, and I would say the majority when I asked them who sponsors innovation, they gave same some version of the single sponsor model. Well, the CEO signs off like who who approves when you do something different that's not just regular operations continue to improve the company but like a big interesting innovation that Oh, it's the CEO. You've either got one person who has the power. Oh, it's the CTO. Or you have a few different senior executives who each individually if they want to step up and put their name on something they can sponsor it right. This is a terrible one. Right. It's, it's sub optimal for the team because it doesn't matter who that one person is they are not going to give you the support that a group. You know, a diverse interesting well chosen group that that's on this, you know, board would do because they're always going to have more perspectives, more insights and so forth. It is much worse for the organization, because when you have a single sponsor, they will go to bat for you. They will marshal the resources for you, and then they will never give up. They will never back down. They will never admit this idea is not working because it's them. They're the only one who approved it. So whether it's because the classic pet project, your sponsor has fallen in love with a solution. You're working it. You're iterating. You're talking to the customer every day. You probably at some point realize this is not going to work like we should pivot or shut this down. But the sponsor will be like, no, no, you got to try this. You got to try this. They're so passionately there. They're emotionally attached to it. Or they're just, it's reputational. They don't want to admit that this thing that your idea and they stupidly signed off on it. But now they can't be on the table. They know that was a foolish of them to sign off. So the single sponsor model just as a repeatable model. Obviously, anything you can, it could work in a given instance, but as a repeatable scalable model, it does not work. So you need to set up really clear decision rights. I'm like, what does the team do and decide on and what does the board decide on. And that I would say the first element of governance in large organizations. Brilliant man, brilliant. I have to say, not only just the idea of the sponsor falling in love with the idea, but sometimes as you say, deep down in your gut, this isn't working. And with the great pleasure on the show, we had Joe Bauer on the show talking about resource allocation. He introduced that whole concept of resource allocation. And what he, what the core message was was that a manager is almost like this immiscible layer in an organization that allows some ideas bubble to the top. But they will decide on allocating resources, not based on the idea, but based on the person behind the idea and whether they have a track record of success. So you can see why so many ideas die. Yeah. Yeah. Yeah. Yeah. And it's interesting. So that brings me to the green lighting. So resource allocation, I really think of two, two stages because there's a nuance that you want to get right at both green lighting is just the very first trench of, of resourcing. Right. So it's going from zero to one. So it's a different beast than all the comes next, which is iterative funding. All these repeated meetings, do we keep going or not keep going or not keep going or not green lighting. I actually advise executives, someone who's in the sponsor role who's on the board, ideally, to not try to pick the best idea. Right. Because that puts you in the position of trying to think about what's going to succeed or not. And that is not your job. And it's not your job because you have no idea. You do not know that like the whole point of experimentation is you do not know what's going to work until you get out there. So it's not a bad idea to actually consider team. Right. Particularly if you've got a process where it's something like a hackathon or an open pitch shark tank for anyone in the company can bring in ideas. There's a lot of benefits of having that kind of open net. You got to consider, does this person really, do they have the right mindset more than anything? It's like, do they go in, are they like passionate about the problem, but they haven't fallen in love with the solution yet. Do they understand like what it's going to take to experiment. So, and test and learn. So, so, considering the person is important, considering strategic fit. We'll talk about that in terms of priorities is really important because this is an established business. So it's not, this would be a great idea for anyone to do. Right. That's the question for a VC. It's actually, is this a great idea that we in particular should do a very different question for an established company. So you got to think about that in green lighting, but the overall rule in green lighting. Is what I call minimal deliberation and minimal funding. Right. So you want to spend as little time, you want the process to be as lightweight as possible to decide who gets green light. And then you want to give those who get started as little as possible in terms of time and money in the first round. So it's not this big high stakes. Well, I always got to like look at the data and we got to know at least doesn't have a chance. What's the odds of success of this versus that. You don't know, but don't sweat it. You're giving them five or $10,000 in 90 days. It's like, it's fine. Just like interesting strategic problem. I wouldn't have thought of that solution, but you have a reason why you think it might be worth exploring. Go for it. Right. Let's go for it. So green lighting and then we go into the other part of resource allocation, which is this iterative funding. And so you've got the problem here is that all of a sudden companies will set up a green lighting process. And then they just fall back into traditional BAU business as usual budgeting, which is like these long cycles typically annual budgeting and it's complete mismatch for experimentation. So you have to create a parallel funding model where you've got dedicated pools of resources that you're pulling from. And they're being given out on these short, commonly, depending on what you're building. This is one of the things I know from different industries and companies. If you're building a lightweight app, you could give them two months, not even 90 days of resourcing between round. If you're building something for an industrial sector, you may say, or where there's a whole lot of stakeholders, even before you build the very first illustrative MVP. There's like a lot of people you're going to talk to. You might give them a little longer, but short rounds, come back. Each meeting with the board you define. Okay, if we approve or giving you another round of resourcing and time. What do we need to know next? Right. So we agree with the team. Why don't we need to validate next? What do we need to learn next? Come back with this data at our next meeting. And then based on that, the board. And here's one of those decision rights come into play until the next meeting. The team has complete autonomy and control of its work. Right. Guard rails. Don't break the law. Right. Give some very specific guardrails. And then it is up to them. Who's the customer? What's the feature? What do you build next? Every iteration. It's entirely up to them. They know the definition of success. They know that what they've got to bring back at your next meeting. Right. They know what they're held accountable for. And then it is the board's decision on whether to refund, whether to fund it again or the next round. David, can I just make sure our audience are clear that that's the innovation board and not the board of the organization? Yes. When you think about who the innovation board is. So unless your company is maybe 50 people, 100 people, okay, then your innovation board might be the same as your management board or something. But if you're talking about large scale organization, the board cannot be the board of directors. It cannot be the, it should not be the senior leadership of a whole company, because the one other thing the boards members have to have. What do they need? They need some experience. They need different perspectives and insight. They can advise the teams. They need some understanding of iterative funding and experimentation and how to, how does this kind of process like a venture capital funding model work. But they also need to have the bandwidth. Right. And this is the problem. You get two senior, you get people. It's like, they have those two things you need. You want cloud. You do need to have at least one person on the board who's got some cloud in the organization who can go to bat for you. Right. But if you get a whole bunch of the people from the top tier one, you got your overflowing with cloud. That's great. But they have no bandwidth to actually pay attention. Listen to you and give you advice and that's the problem with going to senior. I do see companies try that. I was reading about Schotens in your book, Smart Schotens. What came to mind, and this is the weird mind that I have, I think in metaphor, was that old movie, Old Yeller. I have to put them, the dog and it's like, come on, Yeller. Because a family guy did a skit of this and Yeller's like, no, no, no. No, I did nothing wrong. Like, come on, Yeller, time, you have to talk to that kid. It's time to put you down. And this is a little bit what happens with the Smart Schotens, particularly if you've made the error of having that single sponsor earlier on. Yeah. Yeah. So shutdowns are one of the hardest parts of innovation governance in companies, established companies. And there's a number of reasons. Part of it is right. If you do have a single sponsor, you've got them overly attached to it. Part of it is this misconception that if an idea fails, if it doesn't pan out when you test it, that that's a terrible thing. Right. Just automatically, as opposed to, well, how much did it actually cost us? Like, how much resources did we lose? How much time, money, people, did we get any value or learning out of it? It's just like, oh, well, shut down, that must be a disaster. It's a sort of psychological assumption. Whereas if you are doing smart shutdowns, you're going to have most of the shutdowns happen with very little cost and with a significant amount of learning. And then the last part is this sort of if you are the one being shut down, right? You're on the team. It's seen, it's perceived and may very well be, in fact, strike against you in terms of your career. Right. And your next what's available to you next inside the company. So those are the things we have to address. You've got to make shutdowns, first of all, be a norm. And expected norm that you have to understand that if you're shutting things down quickly and cheaply, which is the first rule of what I call a smart failure. Right. It's not just enough to fail fast. If you're in a big company, you have to fail smart. And the first thing there is, that means did we fail? It's okay if the idea didn't work as long as did we fail as cheaply and as early as possible. Right. And you keep pushing yourself on that. So you don't want to get to that point and say, gosh, we should have been able to see this six months ago and a million dollars ago. The data was all there. And we just finally admitted today. If you're doing that, the costs are not high at all. So smart shutdowns, you make it a process. You make it a norm. You go in and you start with projections of survival rates. You say, here's our innovation process for this set of projects or efforts or initiatives in the company. And here are the milestones and we expect 50% will stop at milestone one. And then another of those who make it through another 50% will stop at milestone two. And after that, we've got some pretty good ideas remaining milestones will probably shut down 10 or 20% more. So you, you, you set up this expectations. People are comfortable with it. Then you go out of your way to, as I say, celebrate smart failure you spotlight and recognize and have stories in the book of companies who do this extremely well. That a well managed product project that you shut down is actually a great thing and something we should all learn from. Right. So you, you make it not just something people have to hide on their resume, but something you actually literally in public forums get up and praise when you're talking about innovation and growth and not even at some separate failure party. You do that, but I prefer where it's at the same place where you're talking about your innovation successes. You're also talking about your successful shutdowns and what was done right and how we need to learn from that. So, and then you have to follow through, you have to really be that the people who are on those projects, don't get then cast into wilderness or they're not allowed at least to do an innovation project anytime soon. You actually put them on the next one. Right. This is what good companies do. The Google Susan Wojcicki went from a disaster. It was as a product disaster. It wasn't that expensive, but Google answers was her project. It was going to be like Quora. Exciting new product completely flopped in the market. They push, they push just couldn't get it to work. Okay. She did not get like sent back to do boring stuff. She was put on the next interesting. New product they were working on or one interesting ones was Google AdSense. Right. AdSense went on to become one of the biggest sources of profit for Google, right, in their core business model. So, they might not have found that without they weren't really willing to take the talent that had just been on a project that, that did not work in the market and reassigned them. So, you got to have that mechanism where the people who are working on it. If the project doesn't pin up, the venture proves out to be just proves the hypotheses. There's not a market for this. As long as that was managed properly. That's not a failure at all for the person. It's like as Vanessa Kallela when she was in city was talking to me about innovation. She said, it's distinguishing people from projects. The project is being shut down, not the people. So, you reassigned the people to the next interesting project. Doing this right makes shutdowns much easier and it overcomes all these biases that we have inside our organizations and it's so critical. For those people who have been following us from day one, from the first session, and for those people who have signed up for David Substack, you'll know that he's very generous with his tools. He's always releasing blogs on a regular basis. And if you're a pro member, you'll get these tools and the tools are available in the book. One of the tools that is absolutely core for governance is the innovation stack. And I'm going to share that on the screen now for you. And David's going to kindly take us through it. This is something this whole governance element that is so overlooked that we abandoned all my other notes for today's session. Because this is so important and I really want people. It's kind of like, I often think about David as I call it the Disneyland queue effect. You think you're at the top of the queue and then you realize, oh no, there's a whole other side over there and then it bends over itself and you're not your miles from the end or else you get to the end. Actually, it all tumbles down and you can what did I just spend the last year or two doing. So this happened to many of us so getting this part rice for the organization and this is why the whole organization needs to be involved is absolutely core. So over to you David take us through the corporate innovation stack. So the innovation stack. This is as you look at governance. This is a model a tool I offer to bring all these different pieces together. And if you're going to set them up inside your organization. And the first element of the stack is to just understand, there's really three layers you need to have here. Right. So first, the first layer as I would call it is the team. So the teams are the people who are actually doing the work of innovation. Each team at any given time is focused on one what I would call a growth venture that could be a product innovation. It could be a process innovation. It could be something external facing to your customers. It could be internal. Right. I was just working with a head of supply chain for major health care company and her whole focus was about digital innovation of their supply chain for internal stakeholder. But you've got a team who's working on a venture. The second layer is the board. So we talked about this. This is the innovation board, the growth board, or whatever you want to call it, but this is a small group that is overseeing a group of different teams. Right. So one board has a few members and they are looking at multiple teams, green lighting them, advising, counseling them, and then going through this iterative funding where they decide each time they meet with one of these teams. Do does it make sense to give you more resources and more time to keep going forward on this, or is it time for a smart shutdown. And then this all sits within what I call the third layer of the stack and innovation structure. And innovation structure is basically provides two things to the board and the teams. One is it provides a pool of resources. So this is the first question I hear when I tell especially CFOs. You've got to have this iterative funding model and so forth and then they say, okay, but where are they as they're making all these agile decisions on every every week or a month or so is there have meetings with teams. Outside the annual budgeting process. Where are they getting the money from? Well, you have to have a dedicated pool of resources. That's going to be money and it may be people who are full time working in this process of innovation and exploration. And then in addition to the resources, you need to have governance rule. Right, because different kinds of innovation opportunities are going to have to be managed differently within different within an established business. I talked broadly I think we touched on this in part one about three paths to growth. So the key here is first path. Right, this is the easy part. This is innovation within the core sort of low uncertainty well defined problems in your core business. You manage that according to your usual processes that's like go for it. Don't need to change anything don't if it ain't broke. Don't fix it as the saying goes. Right. But a lot of innovation cannot work with that normal business as usual management. So then you've got two different kinds that need to be managed differently and will require this kind of innovation staff. Path to is any opportunity that is part of your core business. Right. But the uncertainty is high. And then path three is things that are actually outside of your core business. So each of those needs actually somewhat different management support, as I recall it. In terms of path to the challenge here is you've got to actually well the broken model is just say let's give it to an innovation team. They'll go build this thing for us for the core business and then bring it back to us. Right. That's what in the IT delivery business is called build it and throw it over the wall. Right. Give us the specs, tell us what you want. We'll go off for six, 12, 18 months, build some digital thingy and then say here it is what you asked for. Right. This always fails. So instead you need a governance model where both the funding and the people actually doing the innovation have to be a mix of some representation and some funding from the core business. So they both have skin in the game, right. That's the money and their perspective of what is and is really not going to work in the core business is there. They're sitting on the team. That is part of the team that team doesn't have to go outside to get that perspective. And you plan from the very beginning that there's going to be a certain point, certain milestone where you've gone far enough and iterating the solution that you're going to hand it back to the core. Now it's ready for them to actually run with it and scale it up. You've taken out most of the uncertainty. Right. Then path three innovations. We different, they have different challenges. Remember, this is an opportunity, a growth opportunity that is outside of your core business. Right. You are a journalism business and newspaper business and you see an opportunity to spin out your games, which used to be crossword puzzles in the print edition. Now you realize this could actually be a separate app with a separate subscription and create a new revenue stream, right. That would be the New York Times, or you're a retailer doing pure e-commerce and you're rebuilding your tech, their own technology infrastructure. And somebody proposes, hey, this new system or buildings work so well. It's very scalable. It's resilient. Couldn't we sell this as a service to other people, right, go into a B2B kind of cloud computing services offering. Whoa, this is Amazon Web Services. First day it was proposed by Benjamin Black in Amazon. Way outside the current business. Current businesses retail. Right. So those kinds of ideas have to be managed differently as well. They don't need the core involved. The whole problem is there is nobody in the core to whom this idea would fit or own. They would be a natural home for it. And so you need to manage those differently and they need to have a different kind of oversight and bought from the very beginning about if this actually succeeds, if this really goes to scale. Where does that go inside the organization? How do we, how do we think about creating maybe even a new business unit for it, or maybe merging it back in eventually to part of the core business. So this is why we need that top level of the of the innovation staff. Innovation structures are set up to either manage. I suggest either the mandate should be path to. So this is tackling innovation opportunities in the core business, maybe one particular business unit of the core. Right, because you can have different innovation structures. And really working, hand in glove with the core business on every one of these ventures. None of them get started. No team gets greenlit without the approval of someone from that part of the business that business unit. Right. And people from that business unit are part of, maybe probably not all of, but are part of the team that goes out and it really builds the solution. And then you would have different innovation structures that are set up one or maybe more to go after ideas outside of your, your current core business. And these can take different shapes. Sometimes that's just through venture capital investing, or it's M&A, right? You've got a strategic M&A team that's looking for how do we opportunities to buy a firm that's going to give you an entry point into a new market or something like that. It can be startup accelerators. It can be innovation labs. It can be hackathons. Lots of different kind of processes, but all of these have what they should have in common to be an effective innovation structure is they've got resourcing attached to them. And they have governance rules that are specific that are suited to the kind of innovation that they're trying to do in that mandate. And then within that structure, they've got one or more innovation boards and they've got the ability to form innovation teams. And that's how these sort of three layers, you have to have all three layers of the stack coming together if you're going to have this really work on a repeatable basis in an established business. After much deliberation, but I had to almost run David's process to decide what not to do today to do priorities, which we're going to skip. So we're going to skip vision, which is absolutely core. We touched on a little bit in part one. We're going to skip priorities. We touched on that a tiny bit, which is so, so important, trying to whittle down where you actually decide where to place your energy. And we're going to go into validation of new ventures because this is the step that comes before scaling and such an important aspect. There's a case study David opens up with here much like we told to bet in part one about CNN plus and about New York Times. This is the great story of Walmart, a company that is doing a great job of validating new event new ventures and trying things iterating, et cetera, et cetera. Frugally as well, I might add. So we're going to open with that story. We've only got 10 minutes left, and then we're going to go into the four stages of validation. Great. So, so yeah, so Walmart is a great example of an established business and seeing a strategic opportunity. So that would be in the priority section. So one of the things they identified is really important to them was to innovate and really try to capture the space of online ordering of groceries. And a whole separate discussion why that is particularly strategically important for Walmart, but they did the thinking clear reasons to go after it. Now they were smart in that they knew they would not know what would work. Right. They did not try to go out and do a whole lot of benchmarking and business case writing and third party data and come up with a big detailed plan of how is Walmart going to do online grocery ordering. They said, no, we don't know, we're going to have to test. We're going to have to learn going to iterate. We're going to try different approaches. Right. They tried different things. They looked at different delivery models. Right. Do we form that up? Do we have a third party, an app, a delivery service like an Instacart or DoorDash or somebody they do delivery part we create the ordering experience and blah, blah, blah. They looked at, do we hire our own drivers? Right. They looked at who will be a Walmart force and people driving around delivering your groceries. They even tested a model where they had employees, you're checking out people who work in a store, you're leaving the store at the end of the day. And you check out your time stamp with your phone and you enter, where am I going to next? Right. The location. And you get a message says, oh, if you're going there, maybe your home, maybe someone friend's house. If that's where you're going, would you take this delivery on your way and drop it off at this customer's home and you'll be paid. You'll get a little bonus over time pay for doing that if you do. It was another delivery model. So they tried different delivery models. They didn't know which would scale which would work. They also tried different pricing. And this is critical. This is the difference between the Instacart, between the venture bat business that's expected to take seven, maybe 10 years to reach profitability, right? That's the name of the game with VC Capital. You're a Walmart. You're any established business. You don't have that long for the idea to prove out that it's actually not losing money, but making a profit, adding value to the company. Right. So they say, it's got to make money. It's got to make money, not immediately, not first quarter, reasonably soon. And before we know it's a scalable, profitable business model. And we don't know what's going to be the right path. Right. So they sent out and they said, we're going to try different things. We're going to be willing to try, is it different price points to order to pay for delivery. If you don't want to pay, they said, well, what if we offer different minimum basket sizes. They tested each of these things. Lots of different price points. They also tested a membership model. Right. Well, maybe people would rather pay one upfront sum for a year long membership than every grocery delivery order is free. One thing they knew they couldn't afford to do is just say, oh, it's free, any size order. So they tested all these things. And, well, one of the things they learned was there was a segment who liked the idea of the membership model, like Amazon crime, right, pay the annual fee unlimited delivery. And then there's some extra benefits that they added in as well to sweeten the deal. So they got some customers on that. They found that was actually a scalable, profitable model. But then there were other customers who didn't want to do that at all. They said, I don't want to pay. I don't want to pay per delivery. I don't want to pay annual fee and just don't want to pay at all. So they said, OK, what if you meet us halfway, so to speak, to the customer. We will give you a great online ordering experience, right, in the app that you can pull up and it's got your data. It remembers your past orders, makes recommendations, makes it very easy to put together your list of all the things you might need right now. Saves all your information, you just tap go. And then our people in Walmart will go up and down the aisles of the grocery section and we'll pull off all the products, we'll put them in the bags. Everything ready for you is just one thing you have to do. You have to drive to Walmart, right? Now part of why Walmart, this was a good strategy or why they were uniquely well positioned to deliver this particular strategy, is because one of the unique strategic advantages of Walmart is their close proximity to the customer in North America and the US, 90% of the population lives within 10 miles of a Walmart. So this is not such an unfeasible, ridiculous ask of the customer, OK, just drive by a Walmart, right? Now you don't even have to get out of the car, right? You park in a special parking spot, we bring the groceries out, we put them in the back of your trunk and off you go. That really hit with a different segment of customers who really like that experience. This was actually already in testing and deployment before COVID hit. Now, of course, when COVID hit, demand with quarantine, demand for online grocery ordering skyrocketed. The first model, they could not scale fast enough. You could not hire enough delivery people to suddenly meet all the demand. But the second model, what's called click and collect, by online pickup at store, was something they could scale. So that became really important to the business. Customer behaviors, expectations keep changing, they keep iterating and experimenting new things. One of the more recent models they tested, they found that there's a certain customer segment who will pay a premium, not just to have you deliver the groceries to them and leave it on their doorstep where the ice cream might start to melt, or if your me, your sorbet starts to melt. You'll pay extra to actually have a uniformed Walmart employee bring the groceries into your home, put them away in your cupboards, your freezer, your grocery, your refrigerator for you. They call this Walmart in-home. So they continue to experiment, try, see what works, see what does it, change, shut things down, start to do things up, continually learning from the market. So there's two final pieces we're going to have time to share. The first is the Four Stages of Validation that we mentioned, and then I mentioned all those tools that David has. He's worked on these for years through the scar tissue of experience with executives and also their scar tissue of failing with so many transformation efforts. So first up, we have the Four Stages of Validation, and then we're going to share the Roger's Gross Navigator. Over to you, David. Great. So the Four Stages really arose from a common problem I found, which is once teams and business leaders and corporate innovators really embrace the idea of experimentation, and that you don't know going in what's going to work, and you've got to test and try things and build iteratively in short cycles. And really, they embrace society of not writing a business plan, but writing down all your unknowns, your hypotheses, right? Your business model hypotheses. What happens is you've got a lot of unknowns at the start, right? They're like, wait, well, which feature should I build first? What price should I charge? Who's my customer? Who's my competition? Does anyone actually care about this problem I think I'm solving, right? Is the technology going to work? Well, regulators approve compliance and legal and so forth. So many questions you don't know. And so then the problem becomes at the start of the journey. It's where do we start, right? What do we do? How do we sequence all this iteration? You can't run a hundred different MVP tests in your first 90 days. So it's, well, what do we do first? And this is where I found it helpful to develop this model based on studying the innovation process of many, many different companies in different categories of what I call the four stages of validation, right? And the point here is all of these things have to be learned before you're going to have a repeatable, scalable, profitable business model, right? But you don't learn them all at the same time. So the first question you have to, this is very high level and there's a lot of details under each of these. But the first broad question you have to answer is, are we focused on a genuine problem for an actual customer? You have to go out and get data to confirm. And that is the stage I call problem validation. That is actually the one that is most commonly skipped over. People start just jumping to doing wireframes or building a working prototype or gaming out the, you know, pricing and blah, blah, blah. You got to confirm what is the problem you're solving? Who's the customer? Do they see it the same way as you? Next, as you start to get some confirmation, some data, a lot of conversations with customers and you're starting to confirm that. Okay. What do we need to learn next? Once we were getting some confirmation on the problem and who the customer is. Next is, does the customer see value in our proposed solution? And I'll underline the word proposed. You are not yet building a working solution for them. You're just sketching out, hey, we're thinking of building an app like this, a dashboard like this, creating a service like this, a training program like X, and you define what is expected. And you see what is the level of demand that generates is the customer knocking on your door and saying, how soon can I have this? What's the price send me the bill? Or are they saying, oh, that's nice. Keep me posted. Translation. I don't care. I'm too busy to worry about this thing. You're planning, right? This stage is what I call solution validation. Once you start to confirm that, you start to really show there's, there's demand from the market, classic sort of indicators or product market fit. They want it. They're willing to put even down at a deposit, perhaps. They're putting some skin in the game. Now you're ready to store what I call product validation. That's the third stage. And here what you need to discover is can we deliver a solution that customers use? So now this is an important shift in kind of MVPs or that you're building. So before it was things like wireframes, just illustrative mockups, explainer videos, things that sort of show what the thing would be. Now you actually have to deliver your very first just barely working product. I think it's Mark Randolph, co-founder of Netflix, who calls it the minimum unattractive or ugly or I forget MUP. Like, but really not a very attractive, compelling product. What I say is it gives that baseline value proposition actually has to give the most slimmest version of the benefit to the customer. Right. And then you actually see how do they really use it? It's very different often between what people say they want or think they want, and then you give it to them. How do they adopt it? How do they use it? Where do they use it? When do they use it? And can you deliver it? All sorts of operational issues start to emerge here. And you learn all kinds of things you will not know until you're actually in the market with a limited number of customers in a very first pilot where they're actually using it in the real content. Right. Once that starts to happen, and then you'll keep iterating and building it out from this really crummy, early, ugly, what I still call a functional MVP does actually do the job that gets better and more full featured and more polished and more scalable. Then you're ready for the last stage of validation, which is to ask, can we capture sufficient value from this innovation. Right. It's not just can we make money? Right. Can we generate revenue? This is corporate innovation. It might be a cost saving. It might be mitigating a risk to the company. There's some way you're capturing value. And it's not just enough you capture some. You've got to say, look, given the scale of our business, what matters to us strategically, what other opportunities we have to invest. Where our core businesses and so forth. Is this worth taking it further? Right. That's the question of business validation, the fourth stage. So these are all iterative. Each one keeps going. So they layer on and build on top of each other. It's not a stage gate. You don't finish one stage and then start the next. But you begin with common validation as you get some confirmation there, then you start up solution validation as you get good data there and know the path you're on, then you start product validation, and then you start business validation. And what I've seen an experience is this brings a lot of clarity to the process for teams and established companies. I'll show on the screen for those people who are watching us just the depth of these tools as well. And I'll show the Rogers grote navigator there, just to show how this builds on that. And again, by the book, these tools are in their sign up for David Substack. And he gives you these tools as part of that. But I just wanted to mention a couple of examples that you share. You mentioned Randolph there from Netflix. And how cheaply you can actually start the journey. So maybe we'll share just his example. So mailing the DVD, and then diapers.com, which is a great example. Sure. And I'll just say, since you've got on the screen, as you can see, if you zoom in that the growth navigator tool, it's just a visual tool to guide you through these four stages. And what I find is so helpful is everybody on the team, and also those sponsors, the board, the innovation board, you want everyone to have a shared set of facts. So this tool allows you at any given moment every week as you're iterating and pushing along further to have one place where you say, here are our business model hypotheses. This is what we are assuming we don't know. Here's what we data we have. Here's what we actually validated now up to this point. And here's what we need to learn that. Having that that visual tool gives you that shared viewpoint of, okay, where exactly are we on this learning journey, and where we're going to go next to iterate. Great point about these are 80 so iterative, you can learn so much very early on in some cases. So Mark Randolph and read Hastings, this is a very early days of Netflix. One of the things, remember their first business model, this is what they're trying to validate at this point, is the DVDs by mail, right, that was the original business model. And it's about that operation. Remember I said in product validation is not just the customer will use, but we can deliver it. Well, they had to figure out what's it going to take to be sending all these DVDs. One of the key questions was, can we just use regular US Postal Service, right, the cheapest rates available for sending, and will it go through without breaking, right, are we going to have to have lots of expensive padding which then adds weight and then there's a higher charge for everyone we send. All they did was they took, they didn't even actually take a DVD. They took a physical disc, it was a music CD ROM. It was Patsy Hot Patsy Cline's greatest hit, right, so they had on the in the car, they put it in a pink greeting card envelope that they bought at a store, and then they just took that and they dropped it in the mailbox on the street corner in their town and Santa Cruz and mailed it to themselves. And they just wanted to see, like, does it get there and is it broken or not, right. Super, super cheap test, super simple, 24 hours, and they learned something that was really critical to thinking about, okay, can we take this idea forward. The other example you gave diapers.com. So this isn't the earlier days of e-commerce. Amazon was already up and running, but Amazon started as a bookstore and they were gradually starting to move out into other categories of things you could order and have delivered. But they were not yet the everything store, right, so e-commerce is still growing. These two dads, Mark Lori and Vinette Barara, so they're new dads, they've got babies at home, right, they're both married. And they're thinking about all of a sudden they're buying all these diapers and other baby stuff, all this stuff they didn't buy until all of a sudden right now. And they're entrepreneurs and they're thinking, hey, there ought to be an e-commerce solution for this because there wasn't one of them. And so they said, yeah, it'll be like diapers.com and you can order the diapers, all the diapers you need and then we'll add on extra all the other baby products you need, but we start with the diapers because that's the thing everyone knows they need and you keep needing it. Frequency of purchase is always a key element in e-commerce, they knew that. So they said this could work, but I don't know, would it? So the very first MVP, the first test that they built was just this. The two guys, they posted on Facebook, that was the top social media at this time, poor accounts, they're two personal accounts and their wives two personal account. So just their friends and they just posted said, hey, Mark and Vinette are starting a new business. We are providing online delivery of diapers. If you'd like to save yourself your next trip to the store, just message us and tell us what brand you want, what model you want, what size you want in the quantity. And tell us the best price that you've seen in another store, we'll match it and give us your address and we'll follow to charge you over the phone and we'll get it to you. And they went to bed. They woke up in the morning and they had, I think it was 240 orders from just their personal network. So when you have babies, very typically you have a lot of peers or every babies around the same time. So they're like, oh my gosh, we got to get to work. So the two of them and their wives spend the next day driving around to every big box store in their area. Buying up on this list of all the different models and types that they needed and then taking it home and then getting boxes and packaging and packaging them all up and then driving in their minivans to the UPS or the FedEx, whichever it was getting all these orders delivered. Now, obviously, you don't yet have a scalable model, right? That's the thing about early MVPs. They work, but they're not scalable. You don't really know the economics yet, but they learned a lot in 40 an hour. A, most important, they learned there is a market, right? They weren't just smoking something. This isn't something they imagined or just they're the only ones who want it. Customers want it. But they even learned other things like which brands do people order? Which models do they like, right? Classic merchandising questions are critical to any retail business. But also, like frequency, if you give people this option, do they order diapers for a week or do they order diapers for a month, right? How large are they order size? So a lot of data, they got very quickly, very cheaply. And that's the mindset. When you're building these iterative MVPs, as I call them, you've got to shift, particularly in the early days, shift your thinking. You're not building a product, right? You are building a test. You're trying to learn the next most important thing you need to learn about this business opportunity. And that's really what this process of iterative validation is all about. I was just thinking about, if that was me, and we just had a baby, and I decided to start this business, and then my wife has to help me fulfill the orders, I can imagine her just staring at me going, "I'm going to kill you." Why are you doing this? Well, it was such a pleasure to spend time with you. I also spent a lot of time with you because I listened to the audiobook as well as read the book, which is a way just for me to get a second bite of the cherry on an understanding information even more. And David voices this audiobook, and does a great job of that as well. So I highly recommend that. David, where can people find you to find out more? You do executive training, you do keynotes, you are prolific writer and content creator and a sharer of that content as well. Where is the best place people can reach out and find you? So the best place to find me is just start on my website, it's David Rogers dot digital. So not the dot com dot net the usual. Now we can pick our own domain. So it's David Rogers r o g e r s dot digital. You can find information there about my services for companies advising keynote speaking, work with boards, etc. And then also, you can find right on the homepage, any page you scroll down to, you'll see a link to sign up or subscribe. And that will give you the option to sign up for my newsletter and that's a sub stack that goes out every week. And as you said, you sign up, there's a, you get a first chapter of the book. And if you sign up for the pro account, which is actually first, first 30 days is free, you get the bunch of strategic tools, you get additional chapter from my previous book and more information. But mostly, I'm writing there and publishing every week and sharing content, stories, case studies, interviews with executives and business leaders about really what it takes to do digital transformation that really makes a difference in your business. And it absolutely does it. I, as I said to you, write what I first read it, I was like, I wish I had this book two decades ago to join me on my journey. But it's been an absolute pleasure and thank you for spending this amount of time. I really appreciate your time author of the digital transformation roadmap. David Rogers, thank you for joining us. Thanks so much, Aidan. It's been a true pleasure.