So how do you put all of this into practice? Your idea will likely have many different critical components and assumptions which could be explored through a prototype – especially if you are still in the early stages of product development. As reflected in Application Task #1, it is important to identify and address the most critical issues first. Resist the urge to waste time with non-critical assumptions, which might be fun to explore, but do not help you make important decisions about your product.
As described in the previous chapters, start the prototyping process by getting all relevant ideas out of your head and turning them into something that can be shared with and be experienced by others. As Youmans (2011) points out, prototyping works best in settings where physical prototyping is encouraged. In general, your early prototypes should be right, rapid, and rough:
Although these three principles probably sound simple and reasonable to you, implementing them on a daily basis is quite challenging. Especially the third principle of building “rough” prototypes often becomes tricky, when you are expected to test your “crappy” prototype. You have likely cobbled together your prototype over the last few days, and now you are expected to test it with actual live human beings who you potentially hope to turn into real paying customers one day? If you find yourself in that situation, just remember that even the best struggle with this. Or, as Reid Hoffman (co-founder of LinkedIn and former PayPal COO) put it in a great LinkedIn Pulse article: ”If you’re not embarrassed by the first version of your product, you’ve launched too late”.
If your idea contains a service-component, it is worth checking out the IDEO blog post “3 Tips to Help You Prototype a Service” by Melanie Bell-Mayeda. She highlights three fundamental aspects of designing services. First, in the prototyping stage, you should focus only on the details that matter most. Second, while thinking about a service, you also need to consider what happens before as well as after the use of your service. Third, designing services can be quite complex and involve many different stakeholder groups with different needs. This includes obvious groups which participate in the service, but also groups who solve tasks in the background and with which the customer might never interact face-to-face).