Build with a Question

Prototyping Practices Part Two of Ten

When you first start building out an idea you may be overwhelmed with more questions that answers. Our minds are exceptionally good at giving us the impression of an idea being detailed and complete. This impression falls apart as soon as you start to assemble tools and materials. The sheer quantity of unknowns to manage can leave you too paralyzed to build anything or repeatedly building out the areas you are most comfortable with. To avoid this, you need to add structure to your learning. Thankfully, while your idea may be unique, the types of questions you need to answer, and the order to address them in, have been studied for years.

All projects that require the design and development of a solution follow roughly the same pattern. The optimization of this process has been explored heavily in management consulting and design research, with many schools of thought adding their own unique take. These are general models that can map to the activities of a single entrepreneur or the resources of a global corporation. I use the relatively simple version (shown below) in my classes and writing for hardware entrepreneurs. Each of these stages has an overarching question to answer, which can be broken down into dozens of smaller questions to drive the creation of specific objects of learning.

SEARCH: Where is there a need?

The ultimate success of a product hinges upon its ability to supply value to its user, whether that be the removal of pain or the creation of new opportunity. Finding good “needs” like this that can be met with a financially viable product is not easy. Obvious needs that are simple to solve in a profitable way generally have a product or service already meeting them. Simply asking a surgeon, fast food worker, or expectant mother what they “need” rarely results in clear, actionable information. Instead, you need their responses to environmental cues, their physical interactions with existing products, their internal thought processes and a full range of other data that is very difficult to collect over the phone. This is where tangible objects can be invaluable.

Sometimes it can be as simple as having the physical tools handy when asking a test subject to describe their work processes. I was once investigating an assembly line where only a single technician was producing successful product. About two thirds of the way through their work, I watched the tech unconsciously swap a small tool between their right and left hands to improve access to a part feature. He was the only ambidextrous individual on the team and his workaround was completely unconscious.

Since many needs have strong emotional or social elements, tangible objects can be used to reduce barriers to communication. In healthcare, where we often need to explore potentially embarrassing anatomy in detail and at length, anatomy dummies provide an acceptably neutral discussion aid. My closet holds a foam head, a female torso, a life sized one-month-old infant doll, and a variety of other more specific anatomy models. I have a highly realistic breast model (complete with its own little modesty blanket) that has been invaluable in describing the mechanics of infant feeding to all-male design teams.

When investigating complex social behavior, environments can be critical to observing candid interactions. Walgreens partnered with IDEO to create a full-scale prototype pharmacy to evaluate how their customers would respond to different store configurations. While a custom building is beyond the capabilities of most start-ups, careful selection of rooms, furniture, lighting, and other spatial elements can promote authentic behaviors.

DEFINE: What is the exact nature of the need?

Broad observation and research can highlight points of opportunity: the door that is avoided because it slams shut so loudly, the frustrated shoppers whose clothing sizes cost more than others, the device the doctor’s all hate because it adds 20 minutes to all their procedures. These are starting points that need to be explored in depth to find the ultimate source of an effect.

Maybe you realize that the doctors keep running over their procedure time because the device they use will frequently fail unless handled in a painstaking manner. Why is that? Was a part designed too thin? Did a manufacturer change materials? Was the physician trained differently, or the patient anatomy different from what was studied in the clinical trials? The result may be the same (a broken catheter and an annoyed interventionalist), but the ultimate source of the problem can lie in a dozen different directions, each of which would drive a different solution.

Reverse engineering of existing products, test apparatus to recreate failure conditions, and material sample test swatches are just a few of the tangible items used to find the critical challenge to solve. Finding and clearly communicating the exact nature of the problem is vital before moving on to the solution stages.

IDEATE: How could we solve this problem?

Ideation is about finding as many ways to solve your problem as possible. What you are learning at this stage is not necessarily your winning idea, but just how wide a field of potential solutions are out there. To map this space out as systematically as possible, I use an extensive list of questions as a source of inspiration.

Questions I have asked to stimulate discussion include:

“How have other industries solved this problem?”

“What would happen if we swapped A with B?”

“What if we used (insert latest massively popular headline tech here)?”

“What is the cheapest way we could solve this problem?”

“How would we solve this if money was no object?”

“What would be the least satisfying way to solve this problem?”

“How could I solve this problem only using items from a hardware store?”

“How would I solve this problem if I only had 5 minutes?”

Many questions are answered with Google, expert interviews and thought exercises, while others can (and should) be built out. To allow for a high volume of ideas, objects used at this stage should be low cost and emphasize “found” rather than “custom-built” materials. The bare minimum prototype will still add a lot of detail and nuance to initial ideas. I have bins of what I call my “brainstorming materials” that include samples of common medical device materials and components, Legos, playdough, duct tape, tongue depressors and more. In a workshop, these objects simultaneously supply inspiration, communication and (when photographed) documentation of potential solutions.

SELECT: What is the best way to solve the problem?

I often tell my workshop attendees, “Brainstorm as if you can do no wrong, assess as if you can do no right”. This is the dual discipline of turning off all judgement during ideation, then turning it back once you have a fertile field to apply that judgement to. Just like in the pairing of problem finding/problem definition, solutions go through a similar round of broad exploration followed by systematic selection and refinement.

Object builds can help you winnow down your field of solutions to a focused concept you can feel confident about developing. Start with questions about the broadest classes of solutions: “Should we solve this with a consumer product, an app, a service, or a combination of these?” Mock-ups and simulated images allow you to gather input on how potential customers feel about different options for solving their problem. Each class of product has its own challenges and opportunities, which should be explored when considering them as a solution.

After settling on an overall solution, builds can be used to work out the details, starting from the most general aspects on down to individual features.

“How big/small should this be?

“How much should it weigh?”

“Where will it be stored/used/disposed of?”

The ultimate output of this stage is to generate a fully defined set of solution requirements whose implementation can be explored in the next stage.

BUILD: What is the best way to make this solution?

This stage is for working out the “how” of the “what” you confirmed in earlier stages. This stage can become endlessly extended if earlier objects were not used to create a set of solution requirements you are confident in. It is where prototyping costs can sky-rocket. “How” questions require very precise, detailed builds that require extensive engineering and manufacturing knowledge.

“How tightly do these gears need to mesh to minimize noise?”

“How many fasteners do we need to assemble these 18 parts?”

“What setting should we use on the laser welder to optimize the strength in this joint?”

Using this level of detail and expense while still working out whether your product should weigh 4 ounces or 10 ounces (something you can work out with a handful of fishing weights and duct tape) is wasteful. Similarly, details of individual elements should be worked out on many small, rapid builds before jumping to fully integrated prototypes of the complete product.

TEST: How do we know the solution solves the problem?

By this stage, you have likely developed a near complete version of your product. While there may still be cosmetic details left to work out, what you have produced should be capable of meeting the solution requirements you set up at the end of your ideation stage and be well on its way to solving your original problem. The challenge at this stage is building objects that help you prove you have solved the problem.

While some tests require the use of an unmodified unit of your final product, others will allow for simple modifications that will greatly reduce the costs and difficulty of testing. You can build special instrumented units with sensors and data loggers to record performance data while it is being used. Replacing an opaque plastic housing with a clear one can make debugging an electro-mechanical assembly far easier. Moving beyond the test units themselves, you can create test apparatus that simulate human interaction very precisely for 1000’s of cycles, without wearing out test subjects. Even deciding which tests can be performed on parts or subassemblies, instead of your precious few complete units, is a great way to keep costs down at this time.

When you should NOT Build

“Don’t Reinvent the Wheel” is the prayerful mantra of every lean design team. This can be hard to do as a first-time entrepreneur. It is a struggle to differentiate between one’s personal lack of knowledge, and whether that knowledge does not exist somewhere in the wider world.

Iterations or improvements on existing products can safely assume that most of the “Build” questions have already been answered. There is no mystery in creating a box to put electronics in or sewing a shirt. These product teams should rely heavily on research (design guides, industry standards, material technical specifications, and trade events) to answer their implementation questions, and focus their building on the critical stages of problem definition and solution selection.

Entrepreneurs working in truly open spaces, however, will have little or no available data that they have not generated themselves. They will be building heavily to answer their design and engineering questions, but will also need to answer questions about business, law, fundamental science, and other areas best answered through research and analysis. Choosing which questions to prioritize and how best to answer them will be explored in the next blog.

Reflection Two of Ten

Looking at the design process diagram, where would you place your product or idea? Did you find clear, actionable answers to the questions of the earlier phases? Did you build expansively, then select down, or did you find one idea and run with it? Looking at what you have built so far, was there another way you could have learned the same information?

About this Series

This is the second installment of a ten-part series on prototyping strategy. This is not about how to pick a 3D printer or get a nice finish on your painted parts, but a deeper reflective dive into the why and how we go about building the things that help us design better products. The points I focus on are not just to better align your project with some design "ideal", they are a way to manage the very real problem of every entrepreneur or program manager - build it fast, build it right, with as few resources as possible.