Thinking big, acting small
Prototyping, experimentation and lean validation are popular terms these days. We also apply these principles in our product development at the Jumbo Tech Campus — and we are definitely not alone. So where is this buzz actually coming from? Why it is so important to break down big ideas into more manageable pieces? And how do we do this in the first place? A little guidance based on real-life examples.
Firstly, what does thinking big and acting small mean? For us this has to do with validating assumptions before making bigger investments. And with designing experiments based on the bare minimum you would need to validate those assumptions. We recurrently see one or more of the following rationales popping up, explaining why this approach can be so valuable:
- To reduce risk — which comes down to not building stuff nobody is asking for. By continuously validating your assumptions you inevitably trash ideas, concepts and/or prototypes that do not work. Which is fine. Trashing no more than a prototype prevents you from disregarding fully fledged solutions that have consumed ample valuable time and resources.
- To reduce complexity — which helps you to accelerate and to focus on what is most important. Validating your assumptions requires a lot less development effort than you would assume. Building quick (and dirty) prototypes forces you to focus on the end user experience rather than on technical perfection, and thereby wards off the risk of losing yourself in all kinds of complexities.
- To maximise impact — which basically is a summation of the above. If you reduce the risk in your solutioning by taking small steps and validating continuously, and if you reduce complexity by focusing on what is most important for your end user, you are more than likely to maximize the impact and value of what it is that you are developing. With each and every step you obtain a better understanding of your end user’s needs and a more clear picture of your solution.
Example #1 — Self scan devices
We’ve challenged ourselves to come up with ideas on how to increase the impact of our in-store self-scan devices. After ranking our top seven initiatives, we invited customers over to our head office to discuss these ideas on how to improve their self-scan experience. What did we use to validate our assumptions? Basic sketches. Nothing more. Was this enough to test all our hypotheses? Not nearly. But it did reveal the initiatives with the biggest impact on end user experience, which is what we are now further exploring. And how much time did we spend on development? Zero.
Example #2 — Virtual assistant
How might technology help to improve the customer service experience, and at the same time reduce pressure on customer service? Would a virtual assistant be capable of handling requests in a customer-friendly way? To find out, we we designed a Wizard of Oz experiment and decided to focus on a single customer request type: refunds because of a missing product in an online order. In just a few days we created a fully working front end for our virtual assistant, but instead of integrating with various back-end solutions we relied on customer service agents to actually effectuate the refund. This allowed us to validate our main assumptions and, interestingly, pointed us to a completely different solution direction with far better experience for our users. How much time did we spend on development here? No more than five days.
Experimentation is not your end goal, is it?
Fair enough, a little criticism seems justified here since experimentation and prototyping are not the end goal. Don’t you require development effort after all to get this working in production? Yes, we do before we can ship this to our customers. But this is not the point here. By breaking down big ideas into smaller chunks and by validating along the way, we now know what works and what doesn’t. We can start developing solutions with a better chance of making actual impact and creating actual user value. And this in fact should be our end goal.
