Innovation Series Part 3 - Viability

ABOUT THIS EPISODE

You’ve done the hard work, analyzed the statistics, garnered the support necessary to implement a big vision, and then… 

“I really appreciate you pushing the envelope, but… do we even know that this is a problem?” 

No worries! You’re prepared, because you have implemented a viable strategy that incorporates a tried and true approach to company wide buy-in.

Kurt Baumberger, EVP, Strategy & Innovation at Shadow-Soft, and Nick chat about bringing that good idea to fruition and out the door in the last part of this special 3-parter. 

Join us as we discuss:

  • Handling resistance in the organization 
  • The importance of company adoption
  • Utilizing power users - collaborators ready to implement on day 1
  • Figuring out what is desirable, what’s feasible, and making that idea viable.  

For more of Kurt Baumberger, check out his book Innovation Navigation: How To Get From Idea To Reality In 90 Days.

You're listening to application modernization, a show that spotlights the fullward thinking leaders of Highgro software companies, from scaling applications and accelerating time to market to avoiding expensive license and costs. we discuss how you can innovate with new technology and forward thinking processes and save some cash in the process. Let's get into it, all right. Welcome back everybody. We're going to do part three of the innovation series of the application modernization podcast. We've got Kurt here again. Excited to jump into viability. Kurt, what do we need to know about viability and why is it important when we're innovating? Viability is how you actually go to market. So you know, you can describe it as G T M and there's lots of different ways that you can do it, but ultimately what you want to do and recognize is that taking your idea to market means getting early adoption and then getting really strong, enthusiastic support throughout the organization so it becomes adopted and people recognize it as being a transformative idea and innovation that you've brought to the forefront. But there's gonna be some resistance. That happens along the way. So what I thought we might do is go through what the typical objections are and then how you might be able to handle those, and in doing that I'll explain to you a several different techniques. So if you are sitting around and have, you know, a piece of paper and can drop these things down, I might be helpful. Or you can just replay the podcast over and over and over again until you've memorized every single word that I've said. Subscribe, like review, all nice reviews, all nice reviews.

I'll man you do that. Thank you exactly. You know, typically what happens when you're pitching an idea is you've gotten all this feedback from people, from figuring out what's actually feasible, because now you've figured out what do we have to build and what can we build given the assets that we have and the resources that we have. But ultimately, before you go to market, you'RE gonna have to get some support. To Take it from his M v P, and truly M v P is minimum viable product to make it a commercially viable product, and by that it doesn't necessarily mean that you're gonna go sell. It just could mean that you're gonna go roll it out within the organization and oftentimes that comes along with a meeting where you're presenting your idea. And when you present your idea you'll have a group of people and within that group there will be one or two people who will play the devil's advocate. So, Nick, if you we're playing the devil's advocate, what might you say in this whole process, as we're just talking high level at this point. But it's it's more I think the devil's advocate is always just looking for the one little thing that doesn't make sense or they don't understand and they go well, why would that work? I don't think it's particularly helpful in most cases. I think you know, playing devil's advocate is uh, I don't know. Maybe maybe there is a place for it. I don't prefer it because I think usually we're self critical of the things we're designing and building on our own. I don't think I've ever had someone do the I'm gonna play devil's advocate here and say that your product sucks and it be useful. So I'm curiously curious of what you've you've seen and observed over the years. Let me ask a different question. Um. When does that devil's advocate usually...

...speak up? In the beginning of the meeting? The very yeah, it's always at the very end, when all the work has already been done, decisions have been made. Um. And I think sometimes it's a hippo. I don't know if that's that's common across this this process, but the devil's advocate tends to be the person with with the checkbook. Um. So I don't yeah, I don't think that's particularly helpful. I think we need to be looking for ways to succeed and not ways to go. Well, this doesn't work. So interesting observations that you just made their Um. Yes, the devil's advocate tends to wait to the very end, and there's a there's a method to the madness. They want to wait so that you don't have time to respond and so they can kill the idea. So that's ultimately what they're trying to do. Um, and at that point all of the enthusiasm and the momentum that you have comes grinding to a halt. The other thing that they usually do is they usually mask it. So they'll say something like, you know, hey, I appreciate your excuse me, Hey, I appreciate you really, you know, pushing the envelope and stretching our thinking and, you know, being creative. And then what's the next word? But, but, and then that's where the objection comes in and kills the idea. So recognize that this is going to happen. Always, always, always, always, that's a declarative. Always, okay, and sometimes it's the person's job to do that. Sometimes they're the CFO and their job is to make sure that they don't make risky bets. Sometimes it could be a compliance...

...officer. That's their job, or legal that's their job, you know. So it's going to happen and if for no other reason, it will happen because it's their job to make it happen. So just recognize that it's going to be there. I mean, that's the first thing. The second thing is that the questions that they're gonna ask are all gonna be fairly straightforward and they're all going to be predictable. And so now I'm going to tell you what they are. All right, so here's number one. One of the devil's advocate questions is, how do we even know that this is a problem? Well, if you listen to podcasts. Number One, you know that you can respond by saying well, because, like anthropologists, we went out and we observed. Our customers are end users in their own environment and we identified that these things were really problematic for them. Okay, objection number two, well, how do you know what's causing the problem? I get that it's a problem, but how do you know? Well, because we mapped out what their customer journey is and their experiences and we identified what the root causes were because we looked so closely at what they were doing. We did journey mapping to show exactly what was happening and where things were breaking down. Objection number three, well, what makes you think that these stresses are really bothering customers? While this is what we talked about before in podcast one, we learned that our customers have to compensate for our shortcomings and we understand that they are really in pain, because pain is roof positive, that we need...

...to do something different. Okay, so now you've addressed the desirability things on multiple dimensions. So now everybody should be shaking their heads saying, okay, I get that this is a problem. Okay, I get that people are suffering, they're in pain and there's an opportunity. Then it kind of shifts a little bit into the feasibility part of it. So how do you know that this is the best solution? And what you want to say as well, we use t shaped thinking to look at all kinds of industries and all kinds of ideas and then went deep on a couple of them, and that's what we talked about in podcast number two, where we generated scores and scores of ideas and then mixed and matched them to come up with a holistic solution. So when I say t shape thinking, the generation of all those ideas is the upper part of the tea and then mixing and matching them together is the lower part of the tea, and then we went deep on these things. So then they might ask, okay, so how do you know if your solution will work for everybody? Well, you respond. We got feedback along the way because we weren't sure which things worked and which things wouldn't work, and so by going through three iterative Um Adventures in our development, we now know that this is absolutely going to work for everybody. All right. Well, who do you have wind up to go use this solution. Well, as it turns out, as we got feedback from people, we have person A, B and C who are willing to be power users and who...

...are ready to pilot it as soon as we come out with it, because we collaborated with them. So we collaborate, we don't dictate. MM HMM. All right. Well, how do we know that people are actually going to use this? You know. How do we know that this is gonna resonate with people? Well, it's because we went out and got their feedback to make sure that every single thing that we're doing is creating value that's worth them changing their behavior, investing more time or investing budget to go make this happen. And so, through that collaboration, what we learned was that they will buy and they're ready to buy. How much did you spend on this thing? Well, we spent ninety days to produce multiple working prototypes that were vetted by the people who are going to ultimately use it, because we believe that speed matters and that's more important than the budget, and so we moved quickly and we kept our costs low. Okay, uh, I see that it doesn't have this feature x feature. Why? Feature Z feature? Why not? Well, because we built a minimum viable products, emphasis on minimum, and so we tried to solve the big problems and not every single problem, because we had to move quickly and we had to create value, because less really is more when it comes to innovation. All right, so when you're gonna break even on this? Well, we model our costs over a year and then we did it over a three year time frame and we expect...

...that we're going to break even in x time because we understand that this innovation is going to take three years to go from idea to full adoption across the organization. So you'll see improvements happening right away, but they're going to happen at a compounded, exponential level before we actually have made a transformation within the organization. Okay, and how exactly are you gonna launch this product? Well, we've already got our people on board who want to be power users and we're going to leverage them and their successes to go get the next wave of people coming on. So once we have the power users going and they see the value, we're sure that the next business unit is gonna want to take it on. So that's the dirty dozen of objections that you're gonna hear and you're gonna hear all of those all the time. You just have to be prepared. Yeah, because it seems like the the objective, the objections from the devil's advocate Um, are often not well thought out objections. Right, if you're talking about a team that's gone through and done done the research, done the prototyping, picked a sustainment model, found it away, how do we make this? You know, worked for the enterprise, the you know, a lot of times, when you have all that information together, it's like a bad defense attorney, you know, trying to get someone off from murder. Right, they're just not gonna have the answers. Um. What...

...what I've found specifically in technology is that when you go a building, and this usually comes comes with platforms, when you go build a platform, the biggest challenge you're going to run into eventually when you want to go to production is security, cyber INFOSEC, whatever whatever fancy words they want to apply themselves. Um, as a group, and I know it's a giant frustration for lots of people, but those that have tackled that that challenge with grace include security in the innovation team so that they can get their their concerns around design in early so when the security leadership goes hey, um, we need to put this through cyber review, you go well. Well, Jan has been a part of the process the whole way and she actually took all the policy and we designed around the policies that you've put together. And here's your report that says we are compliant with the standards of the organization based on what you guys have put out, and then all of a sudden you're going to production. It's so true, and I think you mentioned earlier with you know, the importance of having a cross functional team, Um, for the diversity of thinking, but it's also, you know, the diversity that you need in order to get it organizationally accepted. So you need to have everybody on board up front. So we talked, I think in the first podcast we talked about the what do you want and what don't you want, or rather what don't you want, because those things are so close to the surface. You...

...can articulate that and then flip it to say what you do want. So the example that you're giving is, you know, working with security. They know exactly what they don't want. You know, they can write that very easily. So then you flip it over and now you say so, if it does this, that and the other thing, then we're okay, that's correct. Yeah, that's correct, and then that helps you. You've already gotten the buy in way up front and as things have been iterated and you go from a quantum leap one to two to three, he or she has been part of that whole process and so they've seen, oh well, we have something that's different here because they need it differently. So we may need to amend our policy, right, you know? So, Um, that's happened in a lot of techno aology situations where they say in Kubernetes, as we mentioned before. You know, the whole idea of having data that then suddenly disappears. What do you mean it disappears? Well, it's it's rendered and then it doesn't sing and then it's gone. Well, that doesn't fit with the existing policies that are in place. Um. So if somebody is involved with that, then they say, oh well, we have to change the rules, you know. Right, we have to modify the policy. We have to build a process that allows us to capture Um, that container that's housing some of that data, because we want to have a record of it living and dying. Right what you can do in a log which is totally fine, but that's a pain to have to go back and try to implement when you're ready to go to production for the product perspective, but you...

...don't have the buy in of, you know, another team. I mean that. That's what I think that's the most defensible piece around this is you want to have cross functional teams so you have people fighting the good fight for what you're doing within their teams exactly exactly. That's why it's so important to have representation across all these different functions, and it's not just um within I t. You know you're gonna have Um, although that usually a critical component of this is to have representation from all the different functional groups within I t, but you also have to have, you know, different end users and stakeholders um because ultimately they're going to make the business case and why this has to happen, which is what's going to get you the money, the people the time that you need. And if they're not involved in the solution, then they're just gonna say, you know, why isn't it done. Yet, you know, and how many times has that happened? Well, organizations make investments surround things for for one or two reasons. Right two, create more revenue or new revenue or to save money, right and and those and those functions can look different based on whatever the tool or the project might be. Sometimes we spend five thousand dollars on a monitoring tool to look at our applications and infrastructure because it cost US millions of dollars. If we go down right and and I think even an I that concept can be difficult because we equate five thousand dollars to three or four or five six people. You a...

...tool. Actually just had this conversation with the customer yesterday. It's it's not all. It's never really about the money. It's about the opportunity, costs or loss that comes with are you prepared, do you understand what it may cost you if you don't have this type of feature, if you don't have this type of observe ability, if you do not have this type of safety net in place? So you spend money to keep money, spend money to make money, and if you're not hitting one of those things, you don't have the business involved supporting that. Guess what's not getting funded right that? Well, and you have to look at it sometimes as catastrophic. You know, so Um there was one company that was providing data um in real time to retail stores all across the country in the telecom world. And you know, when somebody goes in there and they're trying to open up a new account, if you don't have their credit information in real time and they can't open the account, that's a lost sale. That's right. And you look at that lost sale not as the one time transaction that's lost, but the long term value of that customer, because all of these things are, you know, discounted cash flows going back. So if the average customer stays with a t and T or verizon for five to seven years, how much are they paying over five to seven years? And discount that back and say, okay, that one transaction ended up costing US ten thousand dollars. And how many times is that happening across our ten thousand stores every day? You get to the numbers that are really high really fast, and it's not unreasonable when you break it down in terms of a single transaction. And so this gets into...

...the storytelling part of how do I make it viable? You need to develop a story. The good thing is that by doing the work and the desirability and then also in the feasibility, you've got the story to go tell. Simple story. You know, we went out and we looked at end users. They were really struggling with X, Y and Z, and so we created a solution and then vetted it not once, not twice, but three times to make sure that we took out as much idea risk, concept risk and execution risk as we could, and then we then, Um got some actual results from the M v P to show what the business value is. And so what we're able to do is transform people from having to spend forty and hours to do this task to having it being automated, which freed up the equivalent of x number of dollars in I t resources, and so kind of gets back to your question of yeah, you can look at the cost, but you if that's against the opportunity of getting three, four or five people, you also have to be able to say, okay, if we do this and we end up cutting out costs or inefficiencies in the system or other things that are slowing us down. Then what's the time savings there? Because it could be ten x of your investment, and honestly, it should be ten x, because people don't make changes unless it's ten x are greater. And so you have to do the math. Now. You won't know the math until you get it to this last section of viability, because only...

...then will you know what your product is and will you know what your cost structure is. Only then will you know what your savings are or what your growth is going to be. So, to your point, you either are driving the top line or you're driving the bottom line. You know, ideally you drive both. You know it'd be great if you've got some economies of scale as you sold more, that your costs are dropping and then you reach Nirvana and may maybe we all work in a business that's got a business model like that. But Um, that's kind of the case. Is We just have to figure out what's the math and that's the important thing, is to look at the math, but not from the downside, from the upside as well. What you'll find, and this happens time and time again, is that if you take reasonable as options, the number is gonna end up being so big that people aren't going to believe it. And so then you say, well, okay, let's say that we're wrong by half. Right, then it still matters. It still matters. And let's say you think that I am just now smoking something that's illegal in most states. Um, then it's gonna be even, you know, even lower, but the number is still going to be bigger than what the invest still going to prove out what we're trying to do. Why it matters? Yeah, I think it's. I think it's tough, especially when you're when you're in the weeds and you know a potential solution may impact your day to day it's tough to see what it could be. And you know, you're not thinking about things, you're not seeing the forests of the trees. You're you're going, well, this,...

...this solution is gonna cost me a million bucks. But you know, that's that's a whole new department and that's new things. We could do so much with that. But it's not getting into efficiency. It's not getting into Um, like, how long does it take to hire five people these days? Holy Crap, I mean it could be months, and then you gotta train them and then once you get them trained. You know, that's three to six months, and then they'll start operating their job and they're gonna be average at their job until they become good at their job. You're looking at twelve months before someone is like a reasonable contributor on any team, and your competition is running right by you. Yeah, it's so true. There used to be a saying that for every ten thousand dollars that you're spending in salary, it takes you a month to find that person, so to find really highly qualified in person. So if you're making sixty it's gonna take you six months. If you'RE gonna make a twenty grand, it could take you a year to find somebody that's really good. And then, to your point, it's you know, the data shows that for anybody coming into the organization, it takes them six months to get oriented. It takes them another six months before they're actively contributing in some small way, and so it's not until the third six months, or that eighteen month time frame, then they're actually playing a big role in your organization. And that's, you know, honestly, that's why people turned to consultants like I don't have that time, so if you've got somebody who's been there, done that and can get me up to speed quickly, then great, that makes sense right, because you know, this is specific to the lens of I t. In eighteen months, if...

...you're not the most phone organization that's ever you've ever worked for, people are starting to look at other opportunities. Eighteen months in and they haven't done their best work for you exactly. I don't know why anybody builds a staff. It's it is an interesting question. But Um, there are three reasons why people leave jobs today, Um, and this is in in most service jobs. So think of technology and I as a service job. One is that they don't feel like they're making a meaningful difference and so if you think about that, it means that you're just doing incremental improvement. You're not really making a difference. Two is that they don't feel like they're valued and related to that is that they're not working on things that are interesting enough or challenging enough to them, Um, so that they can feel like they're valued and get the Kudos. And then three is they don't have enough growth opportunities. So if you don't deliver those three things in the market that we have today, and I would argue that you should be delivering those three things each and every day that you turn the lights on in the in the office or in your organization. Then you're going to have a mass accidence of people. Um. The good thing is that innovation addresses all three because it allows them to work on something that's meaningful, it allows them to feel valued and it allows them to grow. And so if you do that, you think of it as...

...a retention tool of all of your people. And so innovation, I believe, is the lifeblood of every organization. And it's not only because it drives the top line and drives the bottom line, but it it drives and motivates the people who create that top line and bottom line. And so you know, I'm obviously biased, but I clearly believe, and hopefully everyone does as well, that if you figure out what's desirable, if you prototype rapidly and get feedback to figure out what's feasible, when the devil's advocate shows up, when it comes time to talk about what's viable, you'll have them dead on the spot. That's great. I think that's very helpful. We'll drop Kurt's book in the show notes. Go buy it. I'm sure it's on all the well, the only way we've by things today. Right, it's a good old Amazon on Amazon, so good old Amazon. Yeah, it's available, Um, and uh, please leave a positive review. I did get one negative review, a one star review, from a student of mine who I taught, Um law school student, who, Um, I gave her a three point seven and she didn't think that that was good enough and so she went out on Amazon and gave my book a bad review. Was He really like? Is this the way we're gonna play? I don't know. I don't know, but hopefully she's Um, you know, practicing law now for some underworld character. That's what I would expect her to do. But but maybe she's innovating. She could be innovating or she yeah, she could be prodding to get me to do something that's even more desirable, which is actually do all the work for her. Yeah, we're a good grade.

Oh Man, well, let's let's try to fix that for curt Um, go leave a five star review. There you go. Thank you again for the time. I hope our listeners enjoyed this. Thanks for joining application modernization podcast. Application modernization is sponsored by Red Hat, the world's leading provider of enterprise open source solutions, including high performing Linux, cloud, container and kubernetes technologies. Thanks for listening to application modernization, a podcast for high growth software companies. Don't forget to subscribe to the show on your favorite podcast player so you never miss an episode, and, if you use apple podcasts, do us a favor and leave a quick rating by tapping the stars. Join US on the next episode to learn more about modernizing your infrastructure and applications for growth. Until next time, moved.

In-Stream Audio Search

NEW

Search across all episodes within this podcast

Episodes (29)