My first prototype was a failure. It took two weeks and $130 to build. My second prototype was a success. It took two days and $45 to build. When you look at the two prototypes, you’ll see that they are almost identical. So how is it that the first failed while the second succeeded? More importantly, what did I learn from these two prototypes? In this post, I aim to clarify the differences so that you can learn from my mistakes, and prototype more successfully.
I am currently experimenting with building a physical product that aims to solve a simple problem: how might we design a side table that helps you munch better while watching Netflix/ TV? It all started when I moved in to my new apartment. I started watching more TV…while eating. I do have a dining table, mind you. But I rarely use it. Let’s just say that it’s the result of modern behavior and media consumption. What ended up happening was me having to pull my bulky coffee table closer to me in order to put my food on it while sitting on my couch. Unfortunately, the coffee table was too low. I had to cross my legs while sitting on my couch, bend forward to have a bite, and peek my eyeballs upwards so that I don’t miss a minute of Suits (The TV show I’m currently binge-watching).
Long story short, I ended up with the idea for a modular tray-table.
In an effort to follow everything I’ve learned from Running Lean and other books I’ve read, I decided to systematically test all assumptions involved in this idea. I wanted to mitigate risk and avoid launching a product nobody wanted.
Now that the backstory is done with, let’s discuss the 3 lessons I’ve learned from my first two prototypes.
Test one thing at a time
With my first prototype, I thought I could make shortcuts in testing to move quicker from idea to launch. So what I ended up doing was testing a couple of things simultaneously. I wanted to test whether or not I would end up interchanging multiple trays (usability) and what materials I wanted the trays/ table to be made of. That resulted in quite an expensive prototype. The trays were made of oak wood. This wasn’t necessary. With my second prototype, I didn’t care what the materials were. I simply wanted to test usability. Would I end up switching trays? This question could be answered whether the trays were oak or cardboard. It didn’t matter.
A prototype of a physical product doesn’t have to be a physical product
Going back to the topic of testing materials: I could test for materials through a brochure. The reason I wanted to test for materials was to see which ones people valued or cared about. Did they care if the trays were made of oak? Would they be willing to pay more for premium materials? This could be answered with a brochure or a landing page. Not every aspect of a physical product has to be physically prototyped.
Make sure you have a metric in mind to verify your assumption
With prototyping, the aim is to test an assumption and learn something about your product, market, or business model. The problem with my first prototype was that I didn’t set a metric (either quantitative or qualitative) to verify the assumption I was testing for. After I had the prototype built, I started justifying my idea (solution bias) because I didn’t set a metric beforehand. It is very important not to fall in love with your prototypes, and in order for you to avoid that, you need to be disciplined with your tests. One way to do that is to set a clear hypothesis about your product and assign a metric for it accordingly. For example, let’s say I wanted to test whether or not I interchanged trays. My metric would be a clear yes or no. There is no maybe. And you don’t want to get into a position where you’re justifying a “maybe.”