Table of Contents
What if there was a set of step to use rapid prototyping to build great products? How great would if you could solve any problem. Innovation would no longer be an accidental. It would be a result of precise and predictable process. In this mini-series, you will learn about six steps process of rapid prototyping. This process can help you make this a reality. Stop wasting your time, energy and money on something that may never work. You can develop a golden touch!
Steps 4-6 are in part two.
Find a problem
There is some chance that you are about to try rapid prototyping for the first time. And, you may not have any idea to prototype. Well, without the initial idea, raid prototyping hard to do. It is similar to a writer staring at the blank page, or an artist with an empty canvas. Does this sound familiar to you? If not feel free to skip this step and move to step number two, maybe number three. For now, I will assume that you don’t have any solid idea for trying out rapid prototyping.
In that case, the first step of the rapid prototyping process starts with searching for some problem. However, this doesn’t mean that any problem is the right one for rapid prototyping. There are at least two conditions the problem should meet. Sure, you don’t have to follow this two conditions. It is only up to you. You can apply rapid prototyping to anything. It can be physical thing or it can be just ones and zeroes. It can also be also more abstract, like a philosophy or a lifestyle change.
The general rule is that if you can think about it, you can use rapid prototyping to test it. What changes is the environment, tools or metrics. The only thing that really matters is the process. This is probably the best thing on rapid prototyping. Once you learn and master the process, your options are basically endless. However, we are going too far. There are some things we need to talk about first. So what is the first condition?
The first condition
As I mentioned, I like to test every idea for rapid prototyping on two conditions. The first condition is that it must be problem worth solving. Although rapid prototyping is about moving fast, you will spend some time on the problem. This six-step process usually requires about seven days. Therefore, it should be some problem you can work on for a couple of days. Imagine waking up for a week knowing that you will be working on something you either don’t care about or even hate.
Sure you may not have the opportunity to always work on problems you are really excited about. This probability my decrease if you are working for someone else and not yourself. Let’s say that you are not the person in charge. Then, you may have to deal with less interesting rapid prototyping projects. The same is true in case of team. Then, projects are usually picked on the basis of common agreement. Still, there is usually someone determining the direction.
Whether you are the person in charge or not, don’t avoid problems that re not interesting. The truth is that first impression may not be the best for making the final decision. Just think about all the things you had to try for a couple of times before you liked them. Many things in are quite strenuous at first. Only after some time of practice we start to like them. The same thing with choosing the right problems for rapid prototyping.
My suggestion is to give the problem at least a couple of hours, one day may be even better. You know what they say about sleeping on it. And, if the problem still doesn’t feels right, leave it behind and find another one. Work is full of problems to solve.
The second condition
Since there is almost abundance of problems, it may be difficult to choose the right one. Your time is limited and you can solve all problems all at once. This bring me to the second condition. One thing that can help you choose the right problem is its scalability. In other words, how many people have to deal with this problem? How many people can benefit from your solution? This is one of the metrics that can make this decision easier.
Related to this condition is the viability of the problem. It is usually true that problem nobody cares about is not worth solving. For example, creating another photo sharing app would not make such a difference. App stores are already full of these apps. Therefore, if you make new one, chances are that it will be left unused. In addition, the problem should be big enough your solution will be self-sustainable. It should make enough money to cover the expenses and potentially break even.
Sure, t is great if your solution benefits the public. However, this alone will not pay your bills or buy you a food. And, you should focus on problems that can. There will be a lot of people who will want to discourage you from pursuing profits. You should ignore them. The truth is that money can be a great indicator of usefulness of your solution. Imagine you are on a desert thirsty, without water. How much would you pay for a bottle of water? If your life depends on it, probably a lot.
That’s because the problem is painful enough. Otherwise, you may not want the solution even for free. Therefore, don’t neglect the financial side. Use it as indicator of a good problem. If people are willing to pay for the solution, it is at least worth thinking about it.
Assemble your team (or skip this)
This second step is voluntary. Rapid prototyping can be applied to both, teams and also individuals. The only difference is in this step. So, if you are the only person in your team, you can skip this step. Otherwise, let me give you a number of ideas or tips that will help you assemble the right team. It is possible that rapid prototyping will work with every team. Well, unless the members are doing their best to fight against each other. Then, your chances are close to zero.
Keep your team small
Otherwise, the main difference will be in the speed of your work. Also, the result may be a bit different. What I mean is that you can make certain steps to optimize your team. The first thing is to keep your team small. We discussed this topic in the article about how to optimizing meetings. Smaller teams are usually more flexible and people are more willing to share their ideas. When people are not willing to voice their opinion, you are on the track to the dead end.
The bigger the group is, the higher is the chance that its members will agree with each other to conform to group values. This psychological phenomenon is also known as groupthink. The main idea behind this phenomenon is that people usually want to avoid going against the group. We don’t even have to go to the office or corporate world to see this phenomenon in action. Take a look at the people standing on traffic lights. Think about two situations.
In the first situation, there is a bunch of people waiting for the green light. In the second situation there are only two people. What do you think? In which situation will some person decide to cross the street on red? In most cases, it will be in the second situation when there is smaller number of people. The reason is that it is easier to go against the opinion of few than of dozens. We saw this in times of revolutions. As the group grows, fewer people are willing to stand out.
This is good if you are a dictator who wants the people to follow the same idea. If you are looking for new and innovative ideas, you want the opposite. You want the people to challenge the status quo. So, what is the best number of people to have in a team for rapid prototyping? I would suggest keeping in your team in range between five and 12 people. This will allow you to assemble team that is diverse and yet still not too big.
Flatten the hierarchy
For this reason, it is also useful to make the hierarchy as flat as possible. People on your team should feel that their opinions are equal. Although there should be someone determining the direction, everyone’s opinion should be welcomed. When people will feel that their opinions don’t matter they will soon lose interest in sharing them. As a result, team morale will go down and all your effort will be wasted. This is why small teams with flat hierarchy are best.
When team lacks any hierarchy, and people feel equal, they are more willing to challenge ideas of each other. Think about it for a minute. Would you be more willing to question your colleague or the manager, or CEO. I think that we all know which answer is more favorable. This doesn’t mean that you should exclude CEO or managers from sessions of rapid prototyping. You just need to make sure that during these sessions all people are equal. No one is superior.
Focus on diversity
Another useful thing is keeping your team diverse. You want to gather people with experience and knowledge from different areas. Doing so will help you find a solution you may overlook otherwise. The reason is that these people can look at the same thing from different angles and perspectives. This is also why innovations usually happen in the intersection of disciplines. In addition, it is why innovation often happens when two or more people discuss their ideas.
In these moments, you combine perspectives of two or more people. As a result, what one person may overlook, the other one can see. Also, another person doesn’t know the rules. She doesn’t even know these rules exist! Then, it is much easier for her to break them. This is why many inventions were created by people who were completely new in the industry. Also, this is why many companies create shared environments. They want different people to bounce to each other.
By the way, when Steve Jobs was hiring people for Apple, he was not hiring only programmers or designers. He hired people from disciplines such as biology, psychology, physics, music and mathematics. I think that there was also some artists. His goal was to build large “library” of knowledge, experience and ideas. You should do the same when you build your team for rapid prototyping. So, remember to include people from as many areas as possible.
In addition, don’t ignore some disciplines just because they are not related to your problem. Remember that dancer can be as helpful for solving your problem as programmer or designer.
Set a deadline
This third step of this rapid prototyping is very important. It can even be the most important. The goal of rapid of prototyping is to come with solution quickly. I mentioned that seven days are a good limit for one iteration of rapid prototyping. I don’t know why, but starting each week with new project is just better. It is just better than ending the iteration in the middle of the week. Week is something more tangible. Also, it is time interval accepted across the world.
The issue with setting proper deadline
There is one possible issue with seven-day rapid prototyping sessions. Some people don’t like to work from Monday to Sunday. Many people like to spend their weekend days doing something else instead of working. So, when you propose that one session of rapid prototyping will end on Sunday, not Friday, you may have to deal with resistance. Then, there are three possible solutions. First, you can insist on seven days. This is can be seen as aggressive and your team may not like it.
The second option is to increase the number of days for each session of rapid prototyping. For example, you can use nine days instead of seven. Then, the session will end up on Tuesday, at least for the first time. The problem is that you can’t dedicate specific days for specific step in the process. This can make the whole process less predictable and more chaotic. Then, there is the third option. You can decrease the number of days. So, instead of seven days, you do five.
Less can lead to more
This is also the number that Sprint used by Google uses. Every sprint starts on Monday and ends on Friday. The upside is that these sprints are predictable. Potential downside is that you have less time. Although, this might be an upside. There is something called Parkinson’s law. This law states that the work will fill time you dedicate to it. So, if you think that something will take one week, it will probably take one week. The same is true if you give yourself a tighter deadline.
One good example is when a student has only a few days to finish his dissertation. Somehow, he is able to achieve this feat even though it takes months to other students. How long would it take you to build a boat? A week? A month? Or, would you need more time? Now, imagine that you are on desert island and you have food only for four days. How long would it take you to build the same boat now? I think you could get it done in those four days.
The magic behind Parkinson’s law is the sense of urgency. You either feel something is too important to be postponed or you are under pressure. In both cases, the result is that you are much more productive. You can finish week of work in just two or three days. This is also why the default limit for rapid prototyping is seven days. Well, I think it is already too much. However, this depends on the kind of project you want to tackle.
Cut down or add?
Still, I would recommend that you cut the time down instead of adding more days. One of the keys to successful rapid prototyping is that kind of urgency or pressure. When, you increase the number of days, you are risking that it will negatively impact this sense of urgency. It can make rapid prototyping more relaxed. This can also result in breaking the deadlines. You know what I mean. Someone on your team doesn’t meet the deadline. So, you decide to extend it.
The problem is that this is the beginning of downward spiral. It can become a habit. You move the deadline once, you can move it again. Why not? You already did it in the past. Your colleagues could think that you are biased. Another great way to kill team’s morale, productivity and drive. I don’t want to say that shortening the time is the way to avoid this. You can get into this spiral whether you increase or decrease the time. Still, the second will make the project look important.
Think about it when something is important, and it has to be done quickly, would you increase the time? If there was some person dying on cancer, would you take another week? My bet is that you would drive your time nuts to make every deadline. Even more, you would probably want to finish before the deadline. Adopt the same mindset for every session of rapid prototyping. You want to get the solution out to the world as soon as you can, not later.
Even if you are not motivated by something so serious as cancer, remember that every day costs you time and money. The longer it takes to create the solution the more expensive it will get.
Closing thoughts on rapid prototyping
These are the first three steps of rapid prototyping process. I believe that these steps are the foundation of every successful rapid prototyping session. Sure, you can skip some one or two and still come up with solution. However, it may not work as well or no one may use it. In both cases, the result is that you didn’t use all the potential. There is still something you could do better. The last thing I want to mention is that the second step (assembling a team).
Even if you are a one-man team, you need to think about what other skills and knowledge can you implement. Don’t get me wrong. I don’t want to push you into assembling the team. Instead, think about skills, experience and knowledge can you learn to supplement it. You don’t need to hire a designer or developer. You can learn that on your own. The same is true for every discipline. Think about Elon Musk. He even taught himself rocket science! In other words, there are no limits.
Just because you are one person doesn’t mean that you must have only one point of view or opinion. Even one person can question her own ideas and assumptions. Even one person can be master of many disciplines, to be expert generalist. Remember, it is up to you to decide what you believe is possible. Have a great day!
If you liked this article, please subscribe so you don't miss any future post.
If you'd like to support me and this blog, you can become a patron, or you can buy me a coffee 🙂
Become a Patron
