Prototypes are a large R&D expense that product development teams mismanage. Learn how a prototyping strategy can improve your NPD budget, schedule, and ROI.
Prototypes are an invaluable tool in product development…and a large R&D expense that project teams often mismanage.
It’s difficult to comprehend how project teams can debate the best way to shave weeks off a schedule, but they gloss over the prototypes that account for ten to thirty percent of an R&D project budget and timeline.
Furthermore, concept prototypes are often more expensive than planned because they are made more complex or refined than required. And to compound the problem, putting in that extra, unnecessary detail takes longer and causes the prototype release date to slip, which teams make up for by paying expedite fees.
Prototypes are used to confirm a project assumption or reduce development risk. However, unless there is a strategic reason behind each prototype made, you are likely wasting valuable development time and money.
To start, a good prototype strategy begins with a clear understating on the question(s) you are trying to answer with each prototype. Next is determining the most efficient way to visualize the concept to get the answer. Going through this process will improve project performance by getting concept feedback quicker than normal, which in turn reduces your product development costs and schedule.
Frequently project teams make production-equivalent prototypes too early in a project. They do this because they’ve either always presented polished solutions to their customers or are stuck in the mindset that all prototypes must go through production-equivalent processes.
Another area where project teams often blunder is how they unveil a prototype to a stakeholder. When done poorly you will lose your audience before you are able to get the information you are seeking.
Let’s review three common development questions and how your team can quickly and effectively use prototypes to answer them:
Once the intent of the prototype is clearly defined, the next step is to identify the quickest, cheapest, and most efficient way to fulfill that purpose. So stretch beyond your established mindset and define the MVp to answer the development question.
Based on the questions listed previously, here are some suggested MVp’s:
1. Will the current market accept a revolutionary new product in this category?
New and emerging concepts are hard for some users to envision. It takes a leap of faith to see the potential uses of a new technology or offering. In these cases a simple sketch or illustration of the concept can go a long way. And providing a visual representation of a potential product in context using a “day in the life” storyboard or a video showing the mock usage will help users suspend reality and imagine the future.
Or…you can develop the concept into a fully functional prototype that appears to be ready for production. Hint: don’t do this. You risk missing a critical user need or piece of information and therefore forcing the development team back to the drawing board along with all of the time and expense associated with such a setback.
2. How will this new product idea fit within a user’s existing environment and workflow?
As a kid you may have built living room forts using sheets or cardboard to transport yourself to a magical place. When recruiting users for early concept testing consider expressing your inner child and creating a mock-environment in a conference room. You can build the environment using office furniture and cardboard props with printed graphics. Establishing the setting will make users feel like they have been transported into an operating room or inside an aircraft. Using props and other prototype mock-ups, users can set-up their unique work environment configuration and explain how a new product idea would fit within their workflow. Alternatively, you can go 100% virtual and build the environment and concept in virtual reality (VR). In a few days you can get information from to 10+ users, individually.
Or…you can spend multiple weeks in the field to meet with the same number of users while jumping through hoops to gain access to their work environment. Hint: this is not an efficient approach.
3. Have we proven the technology or science behind the product idea to achieve the desired functionality?
Development teams can fall into the trap of making a single prototype do everything. Similar to breaking down complex problems into smaller subsystems, you want to follow a similar path with prototypes. Don’t burden early proof of concept prototypes with aesthetic or usability constraints until the technology or science has been proven. Otherwise you may be wasting time packaging technology that doesn’t work into an expensive usability model.
Once the team has confidence in the technology, you might find that it quicker and cheaper to develop separate prototypes: a functional prototype to evaluate performance, and a series of non-functional foam and 3D printed usability models to evaluate overall workflow and usability.
How many times have you given a person a present and realized they have completely stopped listening to you as they are opening it? The same thing happens when you present prototypes to your customers.
How you describe a prototype before unveiling it is just as critical as the prototype itself. Your team should be well versed in setting the customers’ expectations about what they will be asked to evaluate. Never allow prototypes to be out in the open before your customer walks in. They will immediately begin interacting with them as you frantically try to get them back on topic. Or worse, they could break the prototype assuming it was fully functional when it was not.
Place your prototypes in a box or under a sheet so your customer will stay attentive until the appropriate time. Explain what they will soon see and the feedback you wish to gain before you unveil the prototype. And when you have multiple prototypes to evaluate, resist the temptation of unveiling all concepts at once.
The day prototypes arrive is like Christmas morning for any designer. But take heed. Instead of fulfilling the designer’s desire to open a “present,” make sure the prototype has a well-defined strategic purpose for the project.
The objective of great R&D leaders is to guide their development teams toward smart project decisions. If you can gain user input more quickly by using a cheaper/faster prototype, shouldn’t you? Avoid spending the time and effort to make a polished prototype until you are doing final acceptance testing of the product.
So the next time there is a desire to build a prototype, make sure you understand the reason for it. Clearly define the questions you intend to answer and guide your team to identify the optimal method to get these answers. With this prototype strategy, you will reduce budget overruns and improve your NPD schedule and ROI.