Prototyping is probably the most effective way to discover great new product ideas, and technical solutions to challenging problems. Building a simple demo lets you explore your ideas outside your own mind. It allows you to find new possibilities and creative directions.
Unfortunately these days I see engineers are often bogged down churning out feature after feature, in sprint after sprint with little room for creativity. These feature factories exist in Agile teams that function as modern day waterfall teams without realizing it. There is very little exploration and experimentation. The result is mediocre products and missed opportunities for real innovation.
Yet if you look at any great product that you use daily, most are a result of a deliberate experimental mindset and culture.
Take for example the touchscreen keyboard on the iPhone. In one of my favorite books, Creative Selection, Ken Kocienda, former Principal Engineer at Apple talks about his creative journey in building the virtual keyboard for the first iPhone. Back in those days I was working at Blackberry and we were known and loved for the full Qwerty keyboard that was ubiquitous part of the experience. Getting the keyboard on glass right was critical for the iPhone. The magic of the multi-touch experience would have been moot if people couldn’t type text seamlessly on a virtual keyboard as they could on a real one. Typing is a very fundamental feature.The early iPhone team knew this and at one point paused all development of the iPhone OS to have every team focus on building dozens of keyboard demos. Each demo was tried hands-on before Kocienda’s version was picked for further development. It is this explore-exploit technique of producing useable prototypes and demos that underpin much of Apple’s success.
When you are trying to innovate and do something completely new that hasn’t been tried before, your one big challenge is uncertainty. There is no guarantee of success. More importantly, it is hard to figure out what success even looks like. Demoing different versions of your idea and trying them out increases the odds of finding the path to a solution. This path may not be a straight line. There will be detours, false turns, great promises that fizzle out and simple ideas that rise to the occasion. In essence your first ideas may not be the best, neither are your simplest ideas the worst. So it’s important to explore options and try out ideas before dismissing them on paper.
This brings me to the other aspect of prototyping that is important: development speed. Speed enables you to quickly try different ideas and iterations to see what sticks. The goals is to explore as widely as possible to identify the few ideas that are worth exploiting deeply. It’s a process of elimination. When building an app, that means having a good set of tools and technique at your disposal to build useable pieces of code quickly. This approach will often be very different from how you would generate features for production. And this is a very important distinction. Processes and techniques that help build production features are often too slow for building prototypes. To build demos quickly you have to give yourself permission to be scrappy. There will be plenty of opportunities for refinement later. Also there is no point in perfecting a new concept that doesn’t work out in the end.
How do you decide what ideas are working and worth pursuing further, and the ones that need to be dropped? Simple, to evaluate a prototype, use it! Use it yourself, share it with others who’s feedback you trust. Pay close attention to how you feel when you try things out. This is the part that requires some degree of imagination to look past the rough edges and envision how the fully baked version of the prototype can be. It is certainly a judgement on future potential, but one that is anchored on the reality of something that you are able to see, “touch” and “hold”.
To summarize the key techniques for great prototyping:
- Explore a wide range of options, before iterating on a select few.
- The prototypes have to be useable. (This means it has to be more than just storyboards)
- Evaluate the prototype by putting it to use and trying it out
- Pursue what works, eliminate what doesn’t
- Repeat!
In recent weeks I have started working on a slate of different prototypes for some ideas that I have had for a while. These range from web apps to iOS apps. Here’s some specific techniques I am using to work on them:
Stick to a familiar set of technologies
As a general rule of thumb, work with a tech stack that you are familiar with, and avoid technical learning curves. Avoid any shiny new technology. Remember that the goal is to learn more about your idea and bring it closer to reality with a prototype. This in itself can be challenging, and attempting to do so while learning a new technology can become distracting. Some demos can be built with no-code tools such as Notion or Airtable. I personally prefer whipping up quick HTML/CSS based demos with a simple Python Flask backend.
Build the core concept first
Develop the core concept and feature that underpin your idea. When starting development on a new app it’s tempting set up a user account system first. I have embarrassingly made this same mistake. You want to know if your product or feature idea at it’s core is viable and worth pursuing. So start with the core first and build some simple support structure around it to enable you to use and play around with the prototype. A lot of the infrastructure around your prototype can be simulated in some way. This is where great tools coming.
Build tools to prototype fast
Build a suite of automation tools and scripts that make prototyping quick. As you build more and more, you will have an accumulation of scripts and tools from each iteration. It pays to curate and organize them to make future prototyping faster.
Don’t worry about clean code
The underlying code in the demos don’t have to be clean, but there has to be some general structure to ensure you can rapidly iterate and experiment. For web applications, the prototype itself can transform into the final product, and therefore a clean structure to the code can provide a path towards the final product. Alternatively of course you can throw away the prototype and start fresh for the final product once you know clearly what to build and experimentation is done.
Eat the dog food
Actually use your demo! Dog-fooding, as its called, is the best way to get a feel for what you have built. I don’t see people dog-food their work anymore. The pace of feature factories simply leave no room for it. Yet the whole point of prototyping is to get a direct feel for the idea and that can only be achieved by actually playing around with demo and sharing with others. Suspend your ego and be open minded about the feedback you receive.
It’s not enough to analyze and judge ideas in the head with all our biases. Doing a prototype and demoing it brings the germ of the idea alive. It is finally outside your head and in front of you. More importantly it can be placed in front of others to get some unbiased feedback. Bad ideas can be weeded out and eliminated. Good ideas can be protected, nurtured and improved. It’s a practice that produces real innovation.