Now it's time to try a prototype. We want to do something very small that will take that idea that we've come up with and to put it into action, to test it out and try it. This should be really, really simple. You can think of this as sort of the crepe paper, construction paper and Popsicle sticks type of prototype approach. It doesn't have to be fancy; it doesn't have to be electronic (in fact it shouldn't be). It should be just something as simple and "quick and dirty" as we possibly can to get at the hypothesis, to prove that out, to test the idea that we've settled on, at least for the first round.
Let's be clear here too, this is your plan. You need to come up with your plan. You need to put the pieces in place to test your plan. You need to evaluate the results of your plan. Own it.
You might also think about trying it with another team, maybe the line that's adjacent to yours or a team upstairs or across the aisle. You try their idea and they try your idea. Then you get somebody else's perspective on that prototype or that testing process, and that's how we can forward it for experimentation. Then we "run the experiment". Did you get the results that you thought, or somewhere near it, maybe the inverse? Okay. That's good.
We really hope and want that from time to time you'll get it wrong. We want to "embrace the fail". We want people to feel safe in trying something different. If you fail and you move the needle that you had in mind but you move it the wrong way, then we can say "Yes, we have found the lever. But we pushed it instead of pulling it". If we get it right, especially if we get it sort of right or mostly right, then we might not get as much of an advantage as if we got it wrong. Because we probably won't go back and reevaluate that, in which case we may have missed the opportunity for the real breakthrough.
This is a portion of the Appendix from "Standing On Shoulders: A Leader's Guide to Digital Transformation".
It is taken directly from a workshop I do on design thinking. It is lightweight enough to use for team retrospectives, and still powerful enough to use for product, service, or process development.