I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the Moon and returning him safely to the Earth.
– John F. Kennedy, May 25, 1961
President Kennedy’s vision of going to the moon was possibly the largest engineering challenge ever faced up to that point in time. The journey was full of unknowns and risk. The stakes were extremely high. Loss of life was a strong possibility. Nothing like it had ever been attempted and the engineers who were going to work on the program probably felt completely overwhelmed. So how did they accomplish such a complex endeavor as Project Apollo? One step at a time.
When creating a breakthrough product, teams may feel a bit like the engineers challenged by the moon mission: Where do we start? How do we even approach the problem? On challenges such as these, often the best approach is to break the problem into manageable pieces and test those pieces one at a time.
No matter how good your calculations are or realistic the simulation is, eventually a prototype must be built to validate the concept. In this paper we’ll discuss how building prototypes actually saves your product development projects time and money while increasing quality.
The Apollo schedule was extremely ambitious, to say the least. The team had 8-1/2 years to meet their goal and much of the technology required did not yet exist. This meant that new technology would have to be developed for problems that hadn’t even been discovered!
The tight schedules and impossible requirements may have tempted the team to minimize the prototype process. After all, it added precious time to the schedule when the team could be accomplishing other, more important tasks, right? Why not wait until the entire design was complete before testing that Saturn V?
It may tempting to bypass prototyping during your product development project. Why not just jump to production and start cranking out product? While lives may not be at stake as they were on the Apollo project, budgets and schedules are still worth saving from catastrophe, right?
Solving the Impossible: Giant Leaps from Small Steps
Neil Armstrong famously stated “One small step for [a] man, one giant leap for mankind”. During product development, it takes many small steps accomplish the “giant leap” that moves the initial concept to the final result.
The Giant Leap
Every visionary project involves a “giant leap”. The moon mission leap was definitely “giant” and required proportional effort. But what if you’re creating a best-in-class medical product instead? While the magnitude may not quite be the same as a trip to the moon, don’t underestimate the effort required to reach your goals.
Small steps solve the larger problem
Apollo required many systems working together to successfully reach the moon and return safely. These included the launch vehicle, the command module, the lunar module, space suits, and high powered communications devices. Each of these systems required prototyping to work out their technical challenges to arrive that the final solution. There was probably no illusion that the number of prototypes would be small.
Similarly, product development projects require many small steps to get from the first paper concept to the final product. Much will be learned along the way, and while the end result may be elegant and simple, getting to that point is paved with blood, sweat, toil, and tears. And did I mention prototypes?
During Apollo, technology had to be created to solve problems such as surviving in a vacuum and living in a small spacecraft for extended periods of time. Similarly, creative solutions need to be developed to solve challenging product development requirements. In each case, conceiving an idea is only the very start of the journey to the solution. At some point on that journey it will be critical to create prototypes to validate that idea. In the case of the moon mission, prototypes were used to independently validate solutions to components of the larger problem before testing the system as a whole.
Eliminate bottlenecks by breaking down functions
One of the most useful and common types of prototype is the functional prototype. Functional prototypes are used test a technical feature or function, refine it, and validate it. Whether the concept works or not, valuable knowledge is gained and needs to be recognized and documented. A prototype that doesn’t validate the concept is not a failure. There are many documented failures of concepts and prototypes during the moon mission, but even those helped progress to the end goal. Remember the images of Neil Armstrong ejecting from that prototype lunar module right before it crashed and exploded?
A common mistake is to put too many features into a single prototype and treat it as a slimmed down version of the final product. Other features that were included because it “seemed like a good idea” suddenly makes the prototype bloated and features that were to be tested can’t be validated. This makes isolating and identifying any problems much more difficult.
A common directive in product design is this: Break your product down into its least common denominators. What this means is that products are composed of fundamental features that define functionality. Validating these features in isolation is best accomplished by Functional Decomposition. Going back to Apollo, the lunar module certainly needed to be mounted to the booster rockets in the final product. However, NASA likely did not try to test the lunar module mounting hardware concurrently with developing the optimal rocket design. This wouldn’t make sense and would greatly increase the risk of one feature affecting the other without any gain in cost or schedule. Similarly, trying to add features into a single prototype likely won’t save any time or money.
Let’s investigate a common product and apply Functional Decomposition. A portable insulin pump can be decomposed into just a few systems as shown below:
- User Interface
- Power management
- Human interaction
Using functional decomposition, the team creates a prototype for each system and tests them independently. There is no reason to make a pump prototype fit into a wearable form factor when all you are doing is gathering the pump’s volumetric dispensing data. Similarly, a usability prototype to evaluate how a user wears the insulin pump doesn’t require functional internal components in order to gain useful information.
But isn’t it cheaper to combine functions?
Trying to reduce cost and schedule is an important component of product development. However, it doesn’t work when dealing with prototypes, and here’s why.
Going back to the insulin pump example, we have multiple teams working on the various systems.
- Pump – Mechanical and Electrical Engineering
- User Interface – Industrial Design, Electrical and Firmware Engineering
- Power management – Electrical Engineering
- Human interaction – Industrial Design and Mechanical Engineering
First, when testing these systems with prototypes the same disciplines and team members are not involved with all systems at the same time. Industrial Design is probably not deeply involved with the pump selection and testing and Electrical Engineering is not directly involved with human interaction tests. Therefore the resources that create these two separate prototypes are not being shared between those efforts. This results in a shorter prototype development time because those disciplines can focus on their specific tasks and begin validating each system as soon as they are ready, instead of waiting for the development of all systems to be completed.
Second, when trying to fit multiple functions into a single prototype, the functions inevitably start to affect one another. For example, battery life is impacted by the pump architecture in the final product, but trying to test that when evaluating pump dispensing repeatability is not helpful. By separating these tasks, each test can be narrowly focused and is ultimately less expensive. Why spend the extra time and money to build specialized circuitry to power the pump during repeatability testing if the final pump hasn’t even been selected yet?
Looking back at one of the most complex and famous development efforts in human history, it’s clear that it required many small steps and prototypes to achieve the “one giant leap for mankind”. While product development may not be quite as ambitious as project Apollo was, we should not lose sight of the fact that it still requires a significant team effort to achieve our end goals. This effort requires prototypes to be built in order to learn from them as well as to validate and improve the products we design. And while it may seem counterintuitive, decomposing functions into multiple prototypes can often save time and cost in your development schedule. Onward to Mars!
Tony Gatica, P.E.Senior Mechanical Engineer
M3 Design, Inc.| P: (512) 218-8858 | F: (512) 218-4107
575 Round Rock West Dr. Suite100, Round Rock, TX 78681