Prototyping Real-World Problems

Innovation and entrepreneurship are not one and the same, although aspiring innovators often think of them that way.

They are told to get an idea and a team and to build a show-and-tell for potential investors. Luis Perez-Breva PhD ’07 describes another approach in Innovating: A Doer’s Manifesto for Starting from a Hunch, Prototyping Problems, Scaling Up, and Learning to Be Productively Wrong (The MIT Press, 2017).

A serial entrepreneur, Perez-Breva has honed this approach during his decade at MIT as originator and lead instructor of the Innovation Teams Program jointly operated by the School of Engineering and MIT Sloan School of Management. In his book, he shows that to start innovating does not require an earth-shattering idea. All it takes is a hunch, which you then give the structure of a problem. As Perez-Breva writes, “Innovations accrue their novelty as you innovate. They are more easily deemed innovations in hindsight than at their beginnings. In hindsight they can be judged by how they ultimately empower others—a community— to achieve new things.”

In this excerpt from Chapter 2, Perez-Breva discusses how to get started on solving a big problem that initially may feel out of reach.

Making the problem tangible

The problem you are proposing to solve very likely lives at a scale far beyond your immediate resources. So, you need to find an easier or more accessible version of your innovation problem to solve. Put another way, you need to scale the problem you want to solve down to a scale at which it corresponds to the resources you have to understand the problem.

For a mathematical problem, a figure would help you turn something otherwise abstract into something tangible that helps your intellect and senses work together. Blueprints or models serve the same purpose for practical and engineering problems. For entrepreneurship and innovation, you might use a slide-deck. But that can help you only so much; a lot remains abstract. If you’ve brought your problem to a resource-friendly scale, though, there are other things you can do to realize the same value that figures offer in solving mathematical problems. You can physically prototype any aspect of your problem, or, as [Hungarian mathematician George] Pólya puts it, you can build a prototype that “assumes the condition of the problem satisfied in all of its parts.” That, of course, might include a gizmo, but it can also include an organization, distribution, marketing, manufacturing, and so on. At that scale, you don’t have to limit yourself to prototyping form alone. You should strive to prototype function.

So, you can generalize problem solving to innovating if you work on bringing the problem first to a resource-friendly scale, and work at that scale to make the problem tangible, prototyping all aspects of your eventual solution—and, in so doing, implicitly outlining all areas in which innovations may be required. After that, your task will be to understand your problem at one scale and work toward scaling up successive demonstrations of the problem.

The final problem you’ll solve will likely differ substantially from the problem you thought you were solving at first. That is because your first expression of the problem was, with high probability, ill informed if not outright wrong. That’s all right; the purpose of your first hunch was to get you started. You’ll discover how wrong as your innovation prototype evolves toward scale.

Scale

The objective of bringing a problem to a different scale is to enable quick and tangible experimentation on the aspects of the problem most critical to move forward. It is also helpful to begin separating the nature of the problem from the magnitude of the impact to which one aspires.

There are many ways to work on the scale of a problem. A common one is to change the size of the community—for instance, “Let’s start with five people and then ramp up to twenty.” But there are other, more effective ways to bring a problem to a scale that is more amenable for quick experimentation—for instance, introducing assumptions to extract the most knowledge and impact from the resources at hand.

Let me give you two examples of the interplay between resources and scale.

In class, a group was interested in devising a system to detect infectious diseases quickly. To realize their initial vision, they would have needed a lab with biosafety level 2 or 3. The stage their hunch was at, though, did not justify the investment in resources and skills required to access and use such a facility.

They could have stopped at that. Instead, they introduced an assumption of scale: a strawberry is a bacterium. The effect of this particular assumption of scale was (a) because of how easy it is to extract DNA from a strawberry, they could forgo dealing with the complexity of establishing what constitutes a good enough sample of bacterial DNA for their experiments; (b) they didn’t need the extra resources of a biosafety lab right away; and (c) getting out of the straitjacket of thinking in terms of the biosafety lab freed them to think about a simple device with which to experiment on the problem. After that, it took only a week to bring together the parts and knowledge they needed and come up with a plan for how to move forward. They were able to articulate their plan by building on conversations with industry experts and a demonstration of a small working device.

More generally, working on the scale of the problem also introduced a very convenient change to the sequence of proofs of concept. Once their device was ready, the knowledge they would need next would transcend their assumption of scale. At that point, they would need access to the specialized lab only to test for that specific knowledge, and they could either contract out the testing or rent the lab whenever they were ready to move forward.

In a different setting, during a lecture in which I challenged students to think about how to prototype their ideas (form and function) all in one day, a team complained that their idea could not be prototyped. They were thinking about a pill that would emit a signal when dissolved in the stomach and help measure patient compliance. Their main concerns were miniaturizing the electronics to fit in a pill, any regulatory unknowns that might exist, and what a safe signal strength would be.

On that occasion, the answer to the question of scale was to assume a much bigger human. In other words, miniaturizing electronics and inserting them in a pill were considerations for down the road—considerations that might indeed require significant innovations. At that day’s stage of their thinking, though, the team needed to characterize the problem. Coating the necessary electronics in cereal, choosing a recipient of the right size to simulate a stomach proportional to the size of the pill, coating the simulated stomach with material that had a density similar to that of a human body, and then developing a number of test scenarios would at least give their questions the next level of specificity they would need to outline all the manufacturing steps, regulatory measurements, and reasoning about the mechanisms by which they could actually measure compliance.