There’s a healthy debate among those of us who mentor startups at Rev. Some mentors believe startups need to understand their customer’s pain inside and out before the founders write a line of code or solder a wire and that any attention to prototyping is premature. While others of us, especially the hardware enthusiasts, see customer discovery and prototyping as a symbiotic process–each informs the other–so we intentionally experiment with that simultaneous action.
BUILD TO LEARN
We see prototyping as a form of agile thinking that we liken to sketching. An artist sketches just as purposely to explore an idea as to perfect the details (those sketches come later). Similarly, some writers scribble the first draft of a book in pen or pencil just so that they have some initial content to work with, not because they are married to its content and outline.
Designers use common phrases such as “Think with your hands” or “Build to learn” or “Show, don’t tell.” In product development there’s a deep culture of making because designers and engineers learn by moving beyond talking and abstract thinking to engage in an iterative process of “build, test, learn.”
PROPS FOR UNDERSTANDING
When we sketch out prototypes, we make “props” that help us test hypotheses. Last year, for example, we had a team that identified and verified the following problem for their customers: “For parents with small children, getting out the door in the morning is a time management nightmare.” The team talked to parents and noted the solutions that parents had hacked together – handwritten schedules, clocks, charts, and timers. Once the team understood that pain, an interesting question emerged: “What ratio of control : autonomy do parents need to give kids in order to change morning routines for the better?” Now, our team could ask that question to parents and kids, but they’d get much richer feedback by building a test that would reveal the answer. They could build a system in which a parent can dial up or down the amount of control the child is given, then test how those settings correspond to outcomes.This kind of system could be built in a day and tested over another two or three days. Building a prototype to find this information is in line with these words of wisdom: “When you really want to understand a customer’s pain, don’t listen to what they say, watch what they do.”
A common trap that we help our teams avoid is termed “The Endowment Effect,” which is defined as “the hypothesis that people ascribe more value to things merely because they own them.” It can refer to both physical things and abstract ideas. If designers and engineers place too much value on the ownership of their prototypes–both the ideas they embody as well as the physical objects that embody those ideas–we know we have a problem. For example, if in week one of the hardware program teams are asking about intellectual property (IP), we know that the endowment effect has taken hold.
If the teams value their ideas and prototypes too early in the process, then they are unable to hear customer feedback that may lead to a necessary pivot. And in product development, that inability to pivot to a new idea is costly and time consuming. It can even end the process by having depleted the team’s resources. A famous quote by Frank Lloyd Wright comes to mind regarding this trap: “You can fix it now on the drafting board with an eraser or you can fix it later on the construction site with a sledge hammer.” Be agile with your early prototypes; be willing to use that eraser. Be fast and loose.
FAST AND LOOSE
In order to model for our teams how to work fast and loose, we kick off the program with a series of short exercises. On day one, we build, test, and revise a product concept in just three hours, and with only $20 of gear. So what’s important here is that we remain true to the spirit of rapid prototyping. We need to work fast and cheap and loose in the early stages of a project. We build only what we need in order to test an idea, and then we learn and grow.