A few years ago I was working on a massive client project. It was going great until it wasn’t…
I look back on that project as the biggest mistake and failure I’ve ever made with my business (I’ll share more on this in detail in a bit).
However, this failure propelled me to spend the next few years completely redefining my work approach on projects. Over time this has solidified into a formal process called Prototype Driven Development.
Iterative prototyping
Instead of gradually building one version, you should rapidly iterate four. Only building one version of your final deliverable guarantees a slow pace and a limited impact.
In 2011 NASA had an exciting initiative called the Space Launch System (SLS). SLS consists of a super heavy-lift rocket that is capable of launching spacecraft into the cosmos. The goal of all of this was to accomplish deep space missions, starting with the moon but ultimately going all the way to places like Mars.
The first program that would use the SLS had a goal of launching an uncrewed mission around the moon and back in 2016. When 2016 came around the project was delayed and not ready. The launch date was pushed back again and again. At the same time the budget tripled from $10 billion to an estimated $30 billion.
By 2021 they were finally able to do a full test of the system but it would face more delays after this and did not launch until 2022. After 11 years NASA completed their first launch. In contrast, the original Apollo mission in the 1960s took 8 years from JFK’s speech in 1961 to putting the first man on the moon in 1969. 50 years later and NASA had taken 3 years longer than that just to do an uncrewed launch.
If we unpack NASA’s approach, we see that with SLS they gradually built one full version. The first version they built was the version they used in 2022 with their launch. NASA and traditional aerospace is known for this approach and the delays and budget increases associated with it are common in the industry.
In stark contrast SpaceX is known for rapidly prototyping and creating many versions of their rockets. If you want to accomplish unimaginable amounts of progress in a short amount of time, aim to imitate their approach by creating four versions in the time you would normally allot for creating one.
In 2017 SpaceX announced development of an ultra heavy rocket for deep space missions (similar to SLS) that would eventually be renamed to Starship. While SpaceX had revolutionized the aerospace industry with their earlier rockets, Starship was on a completely different scale. They were attempting to take on (and fund themselves) the development of a rocket the size of which only the US and Russia had previously attempted.
The history of Starship’s development shows how radically different their approach was from NASA. After one year, SpaceX was already doing low altitude “hops” of a test vehicle version of Starship. After two years (2019) they had already iterated through 3 different versions and prototypes of Starship. 2020 would start with their fourth version exploding during ground testing. Any other rocket company would see this as a colossal failure.
SpaceX instead saw it as part of the process of rapid iteration and learning. By the end of that same year they would be all the way up to version 8 of Starship. This prototype pioneered a mid-flight flip that allowed the rocket to return and land back on earth. It is hard to express how unprecedented a milestone this was.
SpaceX has continued to iterate since then. By 2024 they were catching the rocket after launch with a gargantuan pair of robotic arms. This was a historic moment that allowed them to land the rocket back on the launch pad. By catching the skyscraper of a rocket it allows them to reduce the weight of it. It also allows for a rapid turnaround for them to launch again.
By solving impossible problems such as catching a rocket that is taller than the Statue of Liberty and making it reusable, SpaceX has brought down the cost of launching a Starship to under $200 million. Some estimates place it as low as $50 million a launch with SpaceX explicitly saying their goal is to get the cost down to $10 million dollars. In contrast, the estimated cost of NASA launching the SLS (which is expendable and cannot be reused) is estimated to be up to $4 billion dollars.
SpaceX has mastered the process of building and testing multiple versions early. Their entire system is set up to enable this to happen. In contrast NASA is stuck in a system that revolves around gradually building one perfect version. SpaceX therefore gets to a deep understanding of the problem as each version and the testing done to it reveal unexpected challenges and reams of insights that could never have been accessed in theoretical models.
While NASA will do testing of individual components, SpaceX pushes to test end to end prototypes that imitate the entire spaceship as early as possible. SpaceX has also worked to create a culture where failures are viewed as essential learning steps that lead to not only a refined and resilient design but to amazing technological breakthroughs in very short time spans.
Rapidly doing four versions creates unimaginable amounts of progress in a short amount of time. Aim to create four versions in the time you would normally allot for creating one.
Speed of iteration > quality of iteration
Speed of iteration is more important than quality of iteration. In other words, you want to focus on rapidly prototyping instead of perfecting.
Pixar is known for its pioneering computer animated movies. Ever since the groundbreaking success of their very first film in Toy Story (1996), they have had the pressure of consistently bringing out top notch movies.
With an animated Pixar movie costing upwards of $200 million dollars, they cannot afford to have one not do well at the box office. With hundreds of people and resources committed, there is a huge pressure to make sure you get it right.
You would think the focus would go towards perfecting the film to make sure you avoid mistakes. However, Pixar instead follows an iterative storyboarding process. They very much do not focus on the quality of the iteration, especially in the early stages. Quick sketches get thrown together into a scrappy video called an “animatic” which is just a sequence of storyboards sliced together.
These rough versions allow the team to catch weak story elements early before investing in high-cost animation. By watching the low fidelity animatics they catch pacing, character, or emotional issues early. By refining the story multiple times in rough form, they ensure the final film is rock solid.
Speed of iteration is more important than quality of iteration.
The value of prototype driven development
You want to avoid gradually building one version.
As I mentioned at the start of the article, a few years ago I was working on a massive client project. I had done other smaller projects for this client but this was my first chance to tackle a large and important project for them.
The project consisted of updating two 4 hour workshops that were at the center of my client’s main offering. To complete it, I would need to do some user research to make sure I understood the pain points and issues of the current setup (which led to them wanting to update it). Then I would need to design a new outline/overview, a detailed agenda, a set of exercises, a slide deck, and a series of walkthrough videos explaining all the materials for the entire 8 hours of workshops.
Due to the fact that I had never tackled such a large and important project before, I committed to putting extra hours in to make sure I did a great job. I had 12 weeks before it was due so I set myself internal deadlines to make sure I would not fall behind or get distracted by other projects.
For the first 4 weeks I would do the user research to uncover the main issues with the current workshop to understand how it could be improved. I would then allot 1 week to design a new high level overview/outline that improved on the issues from the current approach. By the end of the week after that my goal was to have a detailed agenda of what would happen over the course of the 8 hours. Next I allotted 3 weeks to design and test the set of exercises used in the workshops. Then I had 2 weeks to create the slide decks for each workshop. Lastly, the final week was for creating the walkthrough videos of all the materials I created.
As I started working on the project, I sent regular status updates related to the completion of these milestones to the client. The last 6 weeks of this project ended up being a hard sprint to the finish line. At the end of the project I was pleased with the result and relieved to have finished it.
The client was pleased with the result and even took time to congratulate me for what an excellent job I had done. However, this project still haunts me as a failure because the workshops never ended up getting used by the client. I had fully executed the project brief. But it drove me crazy that it had zero impact.
It was inconceivable to me that I could be so organized and could work so hard and then the final product could never be used and not actually move the needle for the client. While previously proud of my work approach, this result caused me to entirely reevaluate how I worked on any project and led me to retool my entire approach.
I took time to reflect in detail on what had gone wrong and how I could improve things in the future.
This resolve led me to enter a focused season around examining my work approach and led to what eventually became Prototype Driven Development.
As I journeyed I found that prototyping solved many of the things that I had reflected went wrong with the failed workshops project. I found 5 key benefits to prototyping that emerged from my reflections on that project.
Benefit #1 – Early prototypes clarify the problem
The first thing I wanted to improve on from the failed workshops project was finding a better way to tackle the problem space of a project. With the failed workshop project I had allocated almost half of my time to deeply understanding the problem before starting any work on the solution deliverables.
With reflection I realized that I had given great project updates in this problem phase of the project to key stakeholders. However, these updates had not generated any meaningful engagement or useful feedback. I had solid documentation of the user research along the way but I waited until the end of the phase to share any ideas around what I thought the final solution would look like.
This led the problem definition (despite concrete user data points) to be somewhat abstract. This meant the problem could be solved with a multitude of solutions.
I had always considered this best practice until I started experimenting with rapid prototyping earlier in the process. With a product design project I took on, I did something very different from the failed workshops project. I scheduled a call with the key client stakeholder 3 days from the start of the project.
I then spent the next three days creating a rough low fidelity prototype of the potential solution. However, at this point I cared nothing about what the solution would look like. I knew there was no way my prototype would come anywhere close to the final solution. The entirety of my focus was on properly framing the problem space by using the prototype to make explicit how I was viewing the problem.
When I met with the stakeholder I was astounded by how much valuable feedback I was able to gather so early in the process from them. The stakeholder ended up pointing out some flaws they saw with the design which led to some big shifts to how I ended up framing the problem.
I had been nervous going into the meeting as I was intentionally sharing what I knew would be a horrible solution just for the purpose of better understanding the problem. I worried that I would be perceived as a fool for such a shoddy solution but the amount of progress I made convinced me to never question this approach again.
In the past I had only used prototypes as a tool to improve the solution. From this point on I started using them much earlier as a thinking tool to clarify my problem understanding. All of the problem assumptions I was making were instantly recognizable through quick low fidelity prototypes. This moved early stakeholder conversations from abstract discussions to clear feedback on tangible examples. It also greatly increased my confidence that I was solving the right problem.
While I still regretted the failed workshops project I was grateful it led me to have realized the principle: Use early prototypes to bring clarity to how you are framing the problem.
Benefit #2 – Prototypes remove ambiguity and create clarity
Building on the first benefit – the second thing I wanted to improve on from the failed workshops project was improving the ability for key stakeholders to be able to easily and rapidly give feedback.
With such an important project in the failed workshops project, it was not going to be adopted and used unless there was full trust in the solution. What I found upon reflection was that I was not able to bring people along the journey of navigating the problem and solution spaces. It was not until the end that they saw and understood the final solution. Due to this, there were aspects they did not have complete trust in as they didn’t understand the 12 weeks of reasoning that had gone into the final design.
The way in which I had split up my milestones for that project made it very easy for people to track my progress. However, it did not make it easy for folks to understand the tradeoffs I was making or why I was making them.
As I experimented more with different work approaches and specifically prototyping I found ways to overcome this. By sharing quick low fidelity prototypes along the way, I found ways with future projects to bring stakeholders into tangible discussions around tradeoffs and constraints. I no longer waited for things to be perfect but instead shared ugly prototypes that jumpstarted feedback sessions.
I started actively seeking and rooting out potential misunderstandings as early as possible. With crystal clear feedback from stakeholders, I would then incorporate their feedback and credit them with future iterations for their contributions. I found this to be an invaluable way to lead key stakeholders to take ownership of projects. My future projects then brought people along for the entire design journey and led to final solutions that people inherently trusted and that they believed in as they had wrestled with the tradeoffs that got there.
Again, while I still regretted the failed workshops project I was grateful it led me to have realized the principle: Prototypes create clarity by making things tangible and concrete. Ambiguity is gone, leaving no space for misinterpretation.
Benefit #3 – Uncover problems early
The third thing I wanted to improve on from the failed workshops project was that by the time I realized that the project was not going to have any impact, it was far too late. I wanted to find ways to surface difficult problems like this much earlier in the process so I would have time to address them.
With the failed workshops project I never shared early drafts or prototypes but instead wanted to wait until things were fully “ready” before sharing them. Due to a desire to do a good job I focused on perfecting what I had come up with and feared making mistakes.
A key distinction I realized upon reflection was the difference between finishing a project and getting users to successfully benefit from the project. With the failed workshop project I had done an excellent job executing on finishing the project. However, the real goal should have been getting users to successfully benefit from the project.
This caught me off guard as I thought I had been implementing and practicing best practices. I did user research when many did not. I designed exercises and tested them with users to make sure they were effective when I knew this step could easily be skipped. But this all still was not enough.
Moving forward, I never wanted to finish a project without having confidence it would make an impact with users. Instead of slicing up projects into a series of milestones/deliverables, I instead experimented with creating multiple end to end prototypes that I iterated off of.
When the original iPhone was being developed they could not afford to release a product that did not make an impact.
They therefore prototyped two completely different versions of the iPhone to determine which one would have the most impact. At the time it wasn’t clear which version they should pursue and the favorite early on was a modified iPod version of a phone.
Apple made hundreds of this new proposed iPod phone design to test. These prototypes were functional and you could even make phone calls from them. But after much deliberation it became clear, no matter how much they tried to improve it, the iPod format was too difficult to use as a phone for common tasks like typing or dialing a number.
This is the power of prototyping. You can quickly build and test early versions to uncover issues before they become big problems. You gather outcome focused feedback throughout the process instead of only at the very end.
Again, while I still regretted the failed workshops project I was grateful it led me to have realized the principle: Rapidly iterating uncovers difficult problems early and gives you time to improve and refine your design.
Benefit #4 – Prototypes accelerate progress
Building on the third benefit, the fourth thing I wanted to improve on from the failed workshops project was the speed of the project.
In the past I had liked the idea of prototyping, but it felt counterintuitive to think about creating multiple versions of something. That felt like it would lengthen the timeline and increase how long something took. With the failed workshop project I therefore instead gradually built one version and tried to do each section perfectly in order to be efficient.
But now I was questioning what true progress really looked like. I went 12 weeks working hard until I realized there was feedback, in the form of it not having enough buy-in to be used, that came to light. What if I could capture that feedback within the first week?
I wanted to figure out how I could systematically capture key information such as that faster. This led me to bring prototypes into the process earlier and earlier to allow me to gather the feedback that could truly move the needle on projects.
When Apple was developing the iPhone and had retired the iPod approach, they had in parallel a touch screen prototype they then focused on. But this was all brand new untested technology. To explore the touch screen idea, it started with rigging a Macbook to a projector pointing down over a ping pong table that had been turned into a huge touch screen prototype with tons of wires coming out of it.
Prototypes such as this might have felt like a world away from what the eventual iPhone became. But a series of prototypes is what gave Steve Jobs the clarity to know this was the direction to now move iPhone development into. It brought an entire team together with complete clarity of what they were trying to accomplish.
Abstract discussions and overthinking does not lead to rapid progress. Instead you need to make ideas tangible. To bring them to life so you can anchor team conversations and produce feedback that drives development forward.
Again, while I still regretted the failed workshops project I was grateful it led me to have realized the principle: Prototypes accelerate progress with the fast, clear and useful feedback they generate.
Benefit #5 – Prototype your way to success
The fifth and final thing I wanted to improve on from the failed workshops project was the fact that it did not create an impact. From this I wanted to find a way to overcome any hesitation around negative feedback and to instead actively seek it out early.
With the failed workshops project I wanted to be the hero and to look great. This inclination led me to try to perfect things in isolation so that everything I shared had a refined polish to it. A huge assumption in my work was that stakeholders would be aligned once they saw the finished product.
I worked in a bit of a silo and presented polished solutions late in the process which protected me from negative feedback but which prevented stakeholders from journeying with me during the design phase and buying into the decisions and tradeoffs that were made.
Jumping back to SpaceX again, it is powerful to view what they have done in the development of their Raptor engine. With this engine, and their approach in general, they did not take a “get it right the first time” approach. They instead focused on learning and refining through multiple cycles and iterations.
There is nothing more unforgiving of a feedback loop than rocket design. But SpaceX does not shy away from the literally explosive feedback they can get when things do not go according to plan. They expect and plan for weaknesses, critiques and feedback. They seek to expose it early and then version improvements as fast as possible.
This was a powerful lesson for me to learn. If I plotted out the journey of the failed workshops project it would look like the picture below.
Everything was going well until it was not.
But by pressing into rapid prototyping, the equation changed. I spent the first half of my time during the project unhappy with the half polished, unrefined prototypes. But by the end I was happy because of the massive progress I was able to make.
Again, while I still regretted the failed workshops project I was grateful it led me to have realized the principle: Rapid prototyping invites multiple rounds of tough feedback but results in an aligned team and a refined winning solution.
How to get started
Rapidly iterating and prototyping has become an invaluable part of projects I do in the product design space and in the development of training programs.
One lightweight and practical way to engage in this is to iterate on small pieces of work with rapid design iterations.
Everyday we need to create solutions to problems no matter the discipline. When this is the case, we can bring an iterative approach to it. Whether it’s a visual for social media, a paragraph of text, or an agenda for a meeting – don’t try to gradually create a single version. Instead aim for 9 rapid iterations/versions. Try to make an intentionally wrong first version in 30 seconds and then immediately iterate to the next version.
I always find it difficult to get over the mental block of creating that first one as it will inevitably be wrong. But once I get started I usually find that by the 3rd or 4th version I can stop as I am pleased (and surprised) by the quality of what I have.
If you want to apply this mentality to larger pieces of work and projects, I recommend creating an iterative prototyping plan.
You want to plan from right to left by starting with the final deliverable and then working backwards to determine the prototypes you can build along the way to get there.
For example if I were to redo the workshops project, I might create a prototype of just one section of the entire workshop as version 1. This could allow me to gather feedback quickly and incorporate any of that feedback into how I built out the rest of everything with the next versions.
The key to remember as you plan is to aim to create four prototypes (instead of gradually building one version).
*this article is a potential chapter for the book “How to be insanely productive”
Leverlo: Simple, practical methodologies 