Design and Innovate Solutions That Achieve the Desired Performance by Prototyping to Learn

The following is adapted from Learning to Build.

Many years ago, I was brought on as an advisor at a major cookie and cracker manufacturer. My job was to help them speed up their production line for two popular cookies, but as I rolled up my sleeves and got to work, people kept saying, “You should visit the chip guy; he’s struggling with an issue.” So I went over to see if I could help.

“I’m just having a little fragility problem — they break too easily,” he told me as he brushed aside my assistance. “I’m redesigning the formula, and I just have to run one more test to confirm it, then we’ll be ready to go.”

“Okay,” I said. But about six weeks later, people started prodding me again: “You really need to visit the chip guy.” So once again, I went over to see if I could help. “What seems to be the problem?” I asked.

“Well, I fixed the fragility problem, but now it’s too thick, and the crunch went away when you bite into it, so I’m fixing that now; I almost have it, just one more test,” he told me as he sent me away.

Fast-forward six months and, guess what: the chip guy was still struggling. After hundreds of tests, he was still no closer to a solution. Every time he solved one problem, he just created another. I felt for the man, because I had been there myself in the past. I knew the issue wasn’t the chips — the issue was that he wasn’t thinking about the problem broadly enough. In other words, he wasn’t prototyping to learn.

Look at the Problem as a System

Far too often, we as innovators and entrepreneurs look at an issue as one problem with one solution. That’s what the chip guy was doing. When you don’t look at a situation broadly enough, you conduct A/B testing — testing one factor, then another, and so on. You are always one prototype away from solving the problem, but you never get any closer to the solution.

Rather than frame the problem and search for the solution like a needle in a haystack, you need to look at the problem as a system. What are the systems that are not performing the way that they should? Then you need to unpack those systems into control factors (parameters of a system you can change that impact the system’s performance) and noise factors (parameters that you can’t control, choose not to control, or are too expensive to control).

By the time the chip guy and I sat down, he had already conducted almost 300 samples (or experiments, I would like to say). He never planned to do so many, only one more. Together we prototyped using an orthogonal array, testing less than 20 samples that strategically represented a space of thousands of possibilities. We weren’t trying to find the answer, but trying to understand how it worked: what were the limits of the current system and the tradeoffs we needed to make?

Ultimately, we solved the problem in just weeks, offering up a process and recipe that could be launched in multiple plants faster than any product before. That’s the power of prototyping to learn. You figure out how something works in context, where it doesn’t work — its failure points and its limitations — and then use that knowledge to synthesize and optimize a solution that meets the desired performance and tradeoffs.

Prototype to Learn

Let’s break down the process of prototyping to learn by walking through a project I worked on designing dish soap for a company operating out of a developing country. The company had been developing the soap for about a year, and they were stuck.

Every time they got a status update from the chemists, they’d hear the same thing: “We’re almost there, just one more thing to fix.” And each time they’d fix the problem, something else would break.

“We don’t know why it’s not working,” they said, exasperated. Then they started to list the litany of issues that they’d run into, including costs. Now let’s be clear. I didn’t know what to do; I knew nothing about dish soap. But, using the step-by-step process I’ll walk you through below, I could confidently approach problems just like this one.

Understand System Design

My first step was system design. How does dish soap work? Obviously, dish soap cleans dishes; that’s not what I mean. I needed to figure out how dish soap does the job of cleaning dishes. What’s the mechanism by which the soap works? And how does the customer know it’s working?

So I learned about the cleaning system, which involves surfactants that attack both fat and carbohydrates, breaking them down into smaller pieces. Then I realized that the soap needed to create foam. Without foam, the customer wouldn’t get the feedback that it’s working.

You can actually make dish soap without foam that does an excellent job of cleaning, but people won’t realize it’s cleaning and keep adding more and more soap. I also found that the majority of people use dish soap with a sponge; therefore, if it’s too thin, the soap runs straight through the sponge and down the drain.

Next, I needed to consider smell and color. Finally, the dish soap needed to do all of these jobs while staying within a competitive cost structure. As you lay out all the systems, you suddenly realize that there are six different functions for dish soap.

Prioritization and Functionality of Systems

Next, I needed to prioritize those functions. What are the critical systems that drive overall performance and cost? For instance, the fragrance and color are fairly independent and not where you’ll spend a lot of time and money. However, the bubbles, thickness, and cleaning system are critical components.

After prioritizing the functions, I broke down those functions into parameters with control factors and noise factors. How could I change the things I had control over to make me less sensitive to the things I couldn’t control? How could I set the control factors so that the noise factors no longer affected the output?

For example, the detergent had to work on very greasy foods like olive oil, and on carbohydrates like rice that get caked onto pots and pans. This was one of several noise factors that influenced the system. We needed to play with the chemical makeup of the cleaning mechanism — our control factor — to determine how it impacted the outputs in the system: foam, thickness, etc.

Test the Critical Systems

Next, it was time to build a method for measuring the critical systems. To test the foam, we invented a method using a George Foreman grill where I put a specific amount of dish soap on the grill with a set amount of water. Then I would measure how many times I needed to wring the sponge in the grill before the soap started to foam and how long that foam lasted.

We measured the thickness of the soap in a tube and then looked at the length of time the soap stuck to the top of the sponge rather than just running through it. We also measured the soap’s ability to break fat and carbohydrates into particle size.

Then I played with the chemical formula. There were different actives in the surfactants, so as I adjusted the percent of actives, I looked at the impact on the overall cleaning mechanism as well as changes to foaming and thickness.

I knew that I did not have control over the context in which the customer would use the soap, so those were the noise factors that I tested each of the control factors against. They included hard versus soft water, hot water versus cool water, and grease versus caked food.

Measure Multiple Factors Simultaneously

Once I understood how many factors I was playing with, I knew how many tests I needed to run by simply plugging the numbers into one of Dr. Genichi Taguchi’s arrays from his book Taguchi Methods: Orthogonal Arrays and Linear Graphs. These arrays allow me to measure multiple factors simultaneously and understand how a thing works over sets of tests, within sets of conditions: the opposite of A/B testing or solving one problem at a time. And the tests are fully balanced.

With the dish soap, for instance, nine tests were performed with the color yellow, and nine with blue. We didn’t expect the color to have any impact at all, but as it turns out, blue is an oil-based color and yellow is a water-based color. Therefore, the blue didn’t work as well because the surfactant used some of its power to break down the color rather than clean the greasy dishes.

Taking this approach — prototyping to learn — did not rely on my theory of what the “best” dish soap was. That’s what makes it so powerful. I had no idea how the experiments were going to turn out; I let the dish soap tell me which one was the best. It was based entirely on empirical data.

Find the Tradeoffs

We ended up building 18 prototypes that we measured against these different dimensions. In doing so, we answered a ton of questions: how well did it stay on the sponge? How well did it cut grease? If the water was dirty, did it still foam? What was the foam height? What was the cost?

By the end, I had a whole understanding about what made the best dish soap. For instance, I knew that when I increased the magnesium chloride, it increased foam height without adding to the cost, but it made the soap thinner. Prototyping to learn allows me to see these tradeoffs.

Whenever I prototype, I know that some things are going to work, and others will not, but all of it helps me learn. Too often, people get singularly focused: “I want to make a dish soap with the most foam.” Prototyping will show which dish soap has the best foam, but it will also detail tradeoffs like cost.

When you follow this approach, you start to realize you can’t make the “best” product because you will lose money. You are able to make the tradeoffs in real time, which ultimately allows you to design and innovate solutions that achieve the performance you want.

For more advice on how to prototype to learn, you can find Learning to Build on Amazon.

Bob Moesta is a builder, teacher, entrepreneur, author, and co-founder of The Re-Wired Group, a design and development firm based in Detroit, Michigan. Early in his career, Bob received an education in building and launching new products from renowned innovators Dr. Clayton Christensen, Dr. Genichi Taguchi, Dr. W. Edwards Deming, and Dr. Willie Hobbs Moore. The worldview he gained has enabled him to work on and launch thousands of new products over the last thirty years, be the founder of ten different companies, and become a mentor to the next generation of builders and problem solvers. Bob is an adjunct lecturer at the Kellogg School at Northwestern University and a guest lecturer at Harvard Business School, and MIT’s Sloan School of Management.