My undergraduate advisor at University of Florida, Dr. Eric Schwartz, strongly believes in the idea of Version 0.1 First, and he would iterate to his design teams that it was important to prototype quickly. Rather than focusing on the nitty-gritty details to make it perfect early on, it was essential to take a step back from the drawing board and start prototyping and initial implementation. During creating this so-to-speak 0.1 version of whatever you're making, you can realize a slew of things that would have delayed you exponentially had you not discovered them early on:
- Your design approach was completely incorrect (e.g. your web interface relies on horizontal scroll wheels, which most users do not have)
- Assumptions you made were wrong (e.g. the turbulence from quadcopter blades at low altitudes are negligible for light-weight quadcopters)
- Your target market doesn't want to use (or pay for) your product, and you better pivot before investing more
- It's not all bad stuff either, you may realize the missing component to your design problem you've labored over hours figuring out (a.k.a. The Lightbulb Moment)
- and much, much more
Ever since working with my professor, I have been a strong advocate of the policy. I have found it instrumental to making my successful projects...well, successful, but even more so vital to avoid spilling too much time, effort, and money into the unsuccessful projects.
It's not quite the same as Fail Fast, Fail Often, but Version 0.1 First follows a similar mindset: the principle lies in that you learn more when you start implementation and experimentation, so why not do it as early as possible? Of course, theory is very important (and many times necessary) before implementation, but getting to a prototype quickly is imperative to developing a product quickly.
Fail Fast, Fail Often focuses more on the process of developing something quickly, learn your mistakes, figure out how to overcome them quickly, and move on. Version 0.1 First stipulates that getting to that first iteration quickly is super important; it means to not dig too deep into the details or not to postpone implementation because you have a gut feeling it might not work.
I tried to give some examples above to demonstrate, but it's important to know that this concept is not specific to any type of project. Almost all products involve making a product, developing a service, or fine-tuning a process. You have a goal to have this polished...thing, and it will take some time to figure out how to best make it. There is some thought into how it should be built; I'm going to call this your design phase. But ultimately, you must get to the construction/implementation phase where you start executing your design. More times than not, it helps to start the implementation before for the design is solidified; it often even helps secure a better long-term design saves time, money, heartache, etc.
Being technical does not mean that you need a scientific degree. Technique is the Art of Doing and it is not acquired from theory. You can get it from the willingness to learn and the perseverance to iterate.
- PocketConfident in Get Your Hands Dirty
I guess what I'm saying, to get to your final goal, you should consider "getting your hands dirty" and start making it. Implementing Version 0.1 First is about determining feasibility, discovering future issues, realizing design flaws, avoiding incorrect assumptions, and getting closer to what we're all trying to get to: a polished product. So if you have a great idea, and it's in your means to just get started, take a break dreaming, pause planning, and start doing.