Table of Contents
Rapid prototyping is a process that can help you build great products faster. You don’t have to spend months in the garage or factory hoping people will buy your product. Instead, you can learn how to prototype your idea in just one week! Then, you can test it and see if people are willing to pay for it. In the end, this is the best way to prove your concept. In this second part, you will learn about the last three steps to make rapid prototyping process work for you.
Steps 1-3 are in part one.
Gather the data
We closed the first part of this series about rapid prototyping by talking about the setting a deadline. The next step after setting a deadline is gathering the data. Usually, I would suggest that you gather as much data as possible. However, I don’t think is very useful. There is some point where you will see almost no benefit taking in more data. In a fact, when you pass this line, more data can be harmful. It can distort the data you gathered before. So, more is not always better.
Another problem with having too much data is that it can be overwhelming. As a result, you might have to deal with something called analysis paralysis. I saw a lot of people and teams stuck in this place. You can move forward because your data tell you contradictory things. Also, you can’t move backwards because there is no place to move. In this situation, some people will start to gather even more data. They think that data alone will help them find a way from this dead end.
This might be true in some cases. However, these cases are rather rare. It is more likely that doing gathering more data will make everything worse. It is very much like the paradox of choice. You have a number of options, but you don’t know which one to choose. So, you decide to add one or two more. You hope that this will help you. It will not. It will make you more miserable. When you want to extinguish the fire, you are not going to douse it with gasoline. Data can be this gasoline.
Gather the right amount of data
So, the question is, how much data is sufficient? Gather data until you have the smallest dose necessary to start rapid prototyping. Usually, I push myself and team (if I work with other people) to be comfortable working with very small amount of data. This usually means knowing about the problem we want to solve and talking to group of people having this problem. This group is relatively small. The number of members can range from 10 to 50.
Does this mean that you not do rapid prototyping if you have less than 10 people? Well, in that cases, I would suggest looking for different problem. If you can’t find enough people having that problem, it might not be a good problem to solve. You have to spend resource on every session of rapid prototyping, this might not be worth it. We discussed this in the first part. So, if you can’t find more than 10 people either question your way of searching for people or the problem itself.
So, make sure to interview at least 10 people to gather the data necessary. Then, forget any excuses and move on. Rapid prototyping is about moving fast, not studying the problem for years. It is also not about learning how to interview people. Remember, data itself will not help you solve the problem. Execution is what makes the difference.
Rapid prototyping for the first time
If this is your first rapid prototyping session, chances are that you will want to look for more data. You will want to delay creation of the first prototype. The reason is that you want to avoid complete failure. It is your time, money, product and confidence. I understand that you want to nail it on the first time. However, this is not the goal of rapid prototyping. The real goal of rapid prototyping is trying ideas and iterating in short intervals. There will be some failures on the way.
In addition, don’t be afraid of making your prototype perfect. First, perfection is not achievable because there is always something you can improve or add. Also, you will always find someone who will find some issue. Usually, you will find this person in the mirror. Second, rapid prototyping is about moving fast in order to find what works and separate it from what doesn’t. So, creating a perfect solution is not the ultimate goal. Third, perfection will cost you some time and energy.
Every time you try to make your solution perfect, you are burning your resources. And, you can’t use these resources elsewhere. Remember that your priority is finding solution that works. You aren’t looking for the perfect one. Find it. Then, test it with real people as soon as you can.
Find the smallest effective dose
This brings me to the next phase of rapid prototyping. You need to find solution that is easiest to prototype. Again, you don’t want to invest more time in creating the prototype than necessary. Chances are quite high that your first prototype will not be the last. You will have to create a number of them, maybe a few dozens. This is part of rapid prototyping process. You build one solution. Then, you test it with potential customers and find what works and what doesn’t.
The next step is to either fix what doesn’t work or remove it. Usually, it is better to stick with just one or two things that work. This is also how many companies built their products. Think about Apple, Instagram, Snapchat, Twitter or Tesla. Although not all these companies are the result of rapid prototyping, all of them focused their effort on one feature. Instagram focused on how to take a beautiful photo every time. Apple on building computer regular people will love to use.
In case of Twitter and Snapchat it was about connecting with people you know or you may want to know. Tesla? Electric car you would love to have and use. And, car you would want to talk about. There were some electric cars through the last decade or two. However, you would never talk about any of them. Also, think about Facebook. When it started, it was social network only for students attending Harvard University. Only when Facebook reached a critical mass it expanded.
So, the takeaway we can learn from this and other examples is to start small. We should find out what works and then double down on our effort. This seems to be one of the paths leading to success. It is also fast. And, depending on the problem, relative cheap.
How to find the right dose
So, is there some way to find solution that is easy for rapid prototyping and it also passes the minimum effective dose test? The easiest thing is the wallet test. What does it mean? Ask people if they would buy your solution. Even better, let them make the purchase before you build your product. Let their money speak for them. Let’s be honest. Imagine you have a problem you really want to solve. Then, you will be willing to pay some amount of money for it.
I’m talking about real pain, something that makes your life worse. If you are sick, you are willing to pay for cure. When you are hungry, you are willing to pay for food. When you really want or need to use some product, you are willing to pay for it. This is why so many apps end up being unused. These apps are not solving any painful problem or need. As a result, people are not even willing to use them, not to mention to pay for them. Most of these apps are nice-to-have, not must-have.
So, if you want to avoid this trap, focus on viability. This is one of the best metrics that will help you find the minimum effective solution. Remember, it is a solution people are willing to pay for. When you get into the streets, you can sell it. Otherwise, there is some problem you don’t see. Maybe, you focused on the wrong feature or function. Who knows? Well, your customers do. So, if you ask someone to buy your solution and they reject it, ask why.
Many people are afraid of asking this question, not just in the terms of rapid prototyping. This is a big mistake. You should think about it as a chance to either prove your solution or learn. Well, you will learn in both cases. Think about every rejection as a feedback. Someone is telling you that your solution is missing something. Now, you just have to understand the message and execute on it.
And this brings us to the last step of rapid prototyping process. This step is about iterating. There are two situations when you should consider iterating. The first one is when people are continuously rejecting your solution. You ask 50 people, who have the problem you want to solve, to buy your solution and most of them reject you. Then, you have to think about iterating. It is obvious that something is not right. However, iterating doesn’t mean throwing the idea to the bin.
Iterations on small scale
Depending on the situation, you can iterate on multiple scales. First, there is a small iteration. You found that some feature or function is not viable. So, you decided to iterate. In other words, you will create new prototype that doesn’t have this feature or function. This is the idea behind rapid prototype. If something doesn’t work, create new prototype without that one thing. Then, test it to see if you get a better results. It is common that you will do more than a few small iterations.
The idea of finding the perfect solution on the first try is just not how rapid prototyping works. Think about this approach like about Edison trying to invent the lightbulb. He wasn’t successful after one try. He wasn’t successful even after ten iterations. Different sources provide different numbers, but we can say that he needed at least few hundreds iteration. Sure, this is an extreme example. However, it is still better to use this one instead of buying into the idea of just one try.
When you think about it, you have nothing to lose if you assume the worst will happen. Let’s say you start rapid prototyping with this “long-term” view. Then, you will have more stamina to endure for a long time. And, smaller setbacks will not stop you that easily. S, assume the worst and hope for the best might be the right thing to do. Whether you like this idea or not, just remember to take small iterations part of the process.
Iterations on larger scale
The second type of iteration can actually come earlier in the process of rapid prototyping. For example, you will find that you chose the wrong problem. Usually the one that is not viable and only a few people have it. In that case, you should iterate – find another problem to solve. Another type of situation is when you picked the right problem, but the solution is wrong. There is a large group of people having that problem and they are willing to pay for the solution.
The only issue is that these people are not willing to pay for your solution. So, you can choose between two options. First, abandon the problem and find another one. Second, stick with the problem and try different approach. In the end, there is potential customer base and solution is viable. Therefore, sticking with the problem might be a good idea. Conclusion? Throw away your prototype, get back to the drawing board and start from scratch.
Never stop learning
This brings us to the last thing we must discuss. There is a big similarity between rapid prototyping and lean startup. In a fact, these two can be sometimes even used interchangeably. The reason is that both methodologies share the same philosophy and approach. You start small, learn on the go and adjust as you get new data. From this point of view, rapid prototyping and lean startup are basically the same thing. One difference is that the later is focused on building companies.
Another difference might be the metrics you use. However, you can use whatever metrics you want. Therefore, this argument is not very plausible. Anyway, the important thing is that both these methodologies focus on continuous learning. Sure, rapid prototyping and also lean startup both start with some assumptions. However, they are willing to question these assumptions. And, if they find these assumptions invalid, they abandon them.
This is why gathering feedback is so critical. In the beginning, I told you to gather data only until you can create your first prototype. This doesn’t mean that you should not continue in gathering any feedback. In a fact, you should do the opposite. It is in your best interest to look for feedback everywhere. As a result, you will be able to move faster. Don’t try to avoid feedback because it could hurt your feelings. Your feelings are not relevant at this moment.
Your goal is to create solution that solves specific problem. This is and should be your top priority. For this reason, any feedback is golden. So, my final advice is to never stop learning. Meet with potential customers with every prototype. Let them play with it and test it. Then, shut up and listen to their feedback. Finally, use that feedback to improve your prototype in the next iteration. Follow this process and your sessions of rapid prototyping will lead to success more often.
Closing thoughts on rapid prototyping
This is basically all you need to know about rapid prototyping. Is this all there is about it? No, not at all. You can find hundreds of articles and probably dozens of books about this subject. However, do you really need all that? Do you remember what we discussed in the part about gathering the data. That you should not strive to find as much data as possible, just enough to start? Well, the same is true with the process of rapid prototyping. Find the smallest effective dose and start.
This is the place where many people fail. They want to make the starting conditions perfect. Again, perfection is very expensive. Focus your resources on the process itself rather than on “preparation” for it. This will be more beneficial than spending hours reading books and articles. In the end, no amount of reading or watching beats deliberate practice. So, this may not be the most comprehensive article about rapid prototyping. However, you don’t really need all that.
The last words … Keep your eyes on the deadline, move fast and never stop learning.
Do you have any questions, recommendations, thoughts, advice or tip you would like to share with other readers of this blog, and me? Please share it in a comment. You can also send me a mail. I would love to hear from you.
Did you like this article? Please subscribe.