As entrepreneurs we have this habit of looking at an issue as “one problem with one solution”. This is know as red line development.
When you don’t look at a situation broadly enough, you end up defaulting to conduct A/B testing — testing one factor, then another, and so on.
This is a direct result of looking at the world through the “problem space” as opposed to the “function space.” What’s the one thing that will solve our problem? It’s the notion of testing one factor at a time. Results are not typically reproducible because they are isolated, aimed at finding the “one” root cause that made the problem.
Whereas another way to look at it is to look through the lens of green line development.
This assumes you design experiments that change many variables at once to learn how the system works, assuming nothing. This understanding allows you to reduce costs while solving problems because you can see the whole. You find the “root causes”—the sets of things that work together to make the system work.
On the green line, you’re focused on learning. Whereas on the red line, you are testing to prove a hypothesis, to verify, and then when it doesn’t work you point fingers at everyone else.
I worked on a project back in the day 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 of prototyping to learn, I’ll walk you through below, I could confidently approach problems just like this one.
If reading isn’t your thing, listen to Bob talk about Prototyping to Learn on the Make Things That Matter podcast.
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.
Want to learn how to develop your prototyping to learn skills? Register for the latest Learning to Build class.