Jeff Standridge (Intro):
Are you ready to change the trajectory of your business and see massive improvements? Each week we’ll share strategies and practices to generate sustained results and long lasting success in your organization. Welcome to the Innovation Junkie Podcast.
Hey, guys, Jeff Standridge here. Welcome to another episode of the Innovation Junkies podcast. How are we doing?
Oh, we’re doing good, it’s Jeff Amerine here. I’m glad to kind of continue the conversation from last time where we talked about the challenge sprint aspects of what we do and typical engagement as part of an innovation program. And today I think we’re going to talk more about Design Sprint. So give me a little bit of that contrast. What is that transition from challenge to design?
Yeah. So as we’ve talked about the challenge just in a high level summary, we’ve clarified or we’ve identified a problem statement, a specific problem statement that solves a big problem. We’ve quantified it with credible facts and statistics, and we’ve also made it relevant to our target customers or stakeholders by doing some customer discovery and perhaps pivoting as we’ve brought data on board. And we’re really sure now that we’ve got the right problem, now we’re ready to move into the actual solving of that problem by infusing some elements of what we call human centered design or design thinking into that. And kind of the hallmark of this human centered design is the fact that we we’re willing to walk a mile in the shoes of our customers or the shoes of our stakeholders, this empathy for what our customers experience.
And so, you know, it’s interesting, the single greatest competitor to a new product, service solution, innovation, or invention is the status quo. And so we have to create this mindset or we have to come to this design mindset or this design process with the mindset that we’re going to create massive value with this new design or this new way to solve this problem so that it helps us overcome the inertia of the status quo. So that’s kind of the starting point, is this massive value.
Yeah, I mean, and it’s important too. It’s important. It’s one of the things that keeps the energy up and keeps the activity going in the right direction. If it’s just a small amount of value or it’s just incremental, sometimes it’s not worth the effort. So I like the way you frame that with massive value being the desired output.
A lot of times this is the stage where you quantify what is that massive value adding even more detail in terms of what’s the ROI going to be, what’s the impact the customer is going to be, etc.
Exactly. So we might brainstorm, you know, multiple solution ideas with our team and again then then run them through the massive value filter, perhaps go and get some additional customer or stakeholder validation too, as part of that process. So we can quantify some of that massive value through more empirical kinds of terms or at least assumption based terms.
And then we can go and qualify that massive value by running it through some of our customer filters and our stakeholder filters. But we’re constantly asking the question, is it real? Can we win? Or is it going to be worth the effort? Real, win, worth. RWW is kind of that filter that we’re going through and in reality what we’re doing is we’re trying to deliver a solution or design a solution that sits at the intersection of a Venn diagram. If you can imagine on the bottom of that Venn diagram is the technical feasibility. Can it be done technically? And most times the answer to that is yes to that. These days, most things are possible, technically. Then we ask ourselves, does it produce enough of a benefit for enough people? And then finally, can we do it at a cost that makes it sustainable?
So do we impact enough people at a cost that allows us to to actually produce an ongoing profitable product, solution, or process? Is it real? Can we win? Is it going to be worth the effort in terms of the outcomes?
This is also a stage where we’ll typically have an element of the sprint that will if you have technology people involved, and you typically would, where you’ll get a minimally viable product or a proof of concept put in place so that it’s more than just a PowerPoint presentation. At this point, you’ve got something tangible. It can be as rudimentary as like wireframes.
We’re talking about technology, or it can actually be some kind of a semi-functioning prototype that you can show to internal stakeholders so that they get more of an idea of how it’s going to look and feel and how it’s going to operate in a more of a sense of the feedback you get once you get through that stage is a whole lot better because people can visualize what it is and you continue to get feedback on it at that point during that design.
Sprint, yeah, you know, when I ran a technology shop within a large company, you know, the customer always wanted to jump. You know, we would, we would have to redefine a process before we could create software. You know, the solution might be software, but we would have to redesign the process first and my approach was always, let’s run this new process in a spreadsheet four or five times. Let’s run it manually, run it in a spreadsheet, and let’s use that as our working prototype to define the requirements before we actually start writing code as such.
It’s such a good point. People, in startup-speak, they say do something that doesn’t scale initially to see if it’s going to make any sense at all. And you use existing tools. People a lot of times get caught up on why I need these developers. I need this much money. And it’s like, No, I mean, think about what you have that’s readily available that you can kind of MacGyver together to demonstrate something and that can, you know, that could be a really cost effective way to validate the concept before you commit all those resources to actually build something.
You know, this design process can be done as a jog or it can be done as a sprint. We have seen some pretty remarkable results by at least launching this phase with a 72 hour sprint. Talk a little bit about your experiences there and some of the things that we’ve seen over the course of a 72 hour sprint.
Yeah, And the thing about a sprint is and it’s going to sound kind of strange, but it’s almost like a quantum event in that you compress time, you compress time stuff that when you have people that are at disparate locations are spread all over, is very difficult to accomplish. When you cram people together over a three or four day period, sometimes over a weekend, and there’s kind of working continuously with breaks in the evening.
The amount that they have, particularly if it’s a multidisciplinary team, the amount that they can actually build and validate with customer discovery while they’re building some tech is pretty spectacular. It comes out and it’s like, Wow, I really get it. They’ve gotta functioning prototype there that can take us through all the screens. A lot of the UX and UI work well, they may even have some stuff on the back end that they’re connected to this readily available. So yeah, as an example for a large health care system we work with, they started out with three challenges. I think we had six teams that focused on that. By the end of that, the vast majority of those teams, five or six over the course of the weekend had stuff that was demonstrable that they could show more than just, you know, PowerPoint or Canva. It was actually software that they could demonstrate. So it’s pretty spectacular. What can be done in a short period of time.
And the cream rose to the top. There were you know, there were two or three really spectacular. And the remainder really, really good. And, you know, it’s really a it’s really a combat to Parkinson’s law that effectively says that the work will expand to fit the time that you’ve allotted for it. Right. And so if you if you allot two months for someone to do the design phase, they’re going to do it in the last 72 hours anyway.
So rather than waiting till the last 72 hours, our experience has been, let’s move that 72 hours up to the front. Let’s let’s still establish two months, but let’s put the design sprint at the start for 72 hours. Let’s get some really, really good prototypes and then let’s continue to refine it over the course of a weekly basis of that team coming together for 2 to 4 hours at a time weekly throughout the remainder of that two month period. And what you get at the end far surpasses what you get when you just you know, when you don’t start with that kind of a sprint, you don’t put that initial inertia on the process.
Well, and it does. Yeah, absolutely And it locking people together to where there’s there’s you can’t avoid collaboration it tends to speed things up in a dramatic way as well and so and actually as kind of an aside in general, I think now that we’re coming out of the sort of post-pandemic world, you’re going to find that there will be remote hybrid work. But because of the productivity gains you you enjoy through these sprints, people are still going to come together frequently to do the kinds of things we’re describing in this designed sprint phase of innovation. What comes next? What are we going to talk about next time?
Well, next next episode we’re going to be talking about, okay, you’ve defined your problem. You’ve got the right problem. Now you’ve got a working solution and maybe even a refined solution. And you’re ready to start talking about implementation, either commercialization into the market or you’re talking about implementation into the organization. And so we’re going to be talking about the execution phase of innovation.
This has been another episode of the Innovation Junkies Podcast. We appreciate you for joining.
See all next time.
Jeff Amerine (Outro):
Feedback from listeners like you helps us create outstanding content. So if you like this episode, be sure to rate us or leave a review. Also, don’t forget to subscribe to get the latest growth and innovation strategies. Thanks for tuning in to the Innovation Junkies Podcast.