Chapter 16 — Prototyping
16a. What is Prototyping
Prototyping is one of the main activities in the product development process.
Along with “Understanding Customer Needs” and “Divergent Thinking,” I’d throw it on the list of “Universal Topics” covered in basically all discussions of product development.
Let’s understand some of the basics before diving a little deeper into this universally important topic.
What is a Prototype
I personally don’t think it’s all that important to narrowly or specifically define the term “prototype.” I use the term broadly and I think it’s perfectly OK to do so.
Prototype — An initial or early construction of the product concept, less formed than a “final” product.
Prototype (definition #2) — a mock-up, rough draft, a version of your product meant to be iterated upon.
Pretty much everything made before the final product is a prototype. If you’re designing something that is constantly evolving, like a website, then to some extent, your product is always a prototype of some future version.
As an activity, prototyping is all about learning.
Different NPD methods have their own names for the cycle of building a prototype and learning from it. Some call it “Build Measure Learn.” Others call the cycle “Design Build Test Learn.”
If you want to get all fancy and advanced (trust me, don’t do it right now), there are some subtle distinctions. But we’re not there yet.
For right now, just know that prototyping is a catch-all term for building something in order to test a theory. It’s a term that describes a learning system.
What is the Purpose of Prototyping? (y tho)
Prototyping serves many purposes:
Learning. The first obvious purpose of a prototype is to answer the question “will this work?”
- Prototyping is an attempt to validate a hypothesis. That hypothesis might be super complex (e.g. our theory is that this system will do X) or super simple (e.g. I wonder if this taco will taste better if I put some tortilla chips into it? Yes, it does.)
Scheduling. Another great purpose of prototyping is to drive a project schedule.
- Completing one cycle of building, testing and then analyzing a prototype is a very clear milestone. Many product development teams use a series of prototype iterations as the foundation for their overall project schedule (i.e. we’ll make two prototype iterations and then launch).
Communication. Marty Cagen’s book Inspired purports that the best Product Spec you can build is a prototype. As opposed to writing a 50 page document nobody will read, why not just make a prototype and show people what the product should do?
- While this doesn’t work in all industries (tacos and software maybe, but not rockets), a prototype communicates a lot about the team’s vision for the product. It helps other people “get it” when words just won’t do the trick.
Ultimately, you’ll see that prototyping is the primary mechanism that product developers use to get from a concept to a finished product.
We’ll talk more about this subject in coming sections, covering:
- Types of prototypes
- The build-measure-learn cycle
- Learning systems
- As always, best practices and great resources
16.b Types of Prototypes
Not all prototypes are the same. There are different “types” of prototypes made to accomplish different things. Let’s discuss.
A “Looks-Like” prototype is something that — you guessed it — looks like a product or product concept. It’s a visual representation only. No function. Wireframes are typically “Looks-like” prototypes.
If you build some functionality into a “Looks Like” prototype, then it becomes a functional prototype. Some people call this a “Works like” prototype.
A “Functional Prototype” is a prototype that captures both the function and visual appearance of the intended design.
Functional prototypes don’t work perfectly and are often at a different scale (i.e. smaller) or lacking in some sophistication (i.e. made out of cardboard).
Sure, I’d call this a Functional Prototype. Pretty clever actually. Source.
Product developers also use simulation and modeling to prototype products. These are virtual or analytical prototypes, thus named because they are virtual and they help you do analysis.
Virtual prototypes also make pretty pictures for the Marketing department to use in advertising, and you gotta have those if you want to look cool.
A Virtual or Analytical Prototype. Racecars are cool. Source.
Other terms you might want to know include Internal, External, and Public Prototypes
- Internal prototypes — For your eyes only
- External — For key selected users
- Public — For everyone
System level, sub-system level, component level
In some cases, prototypes are described by the breadth of the final product they encompass.
That’s a fancy way of saying that you don’t have to prototype the entire car to test a new brake pad. If you hear the term “sub-system” or “component” prototype, that’s what it means.
Digital prototyping
These are often UX prototypes (user experience). They’re used to mimic how the digital product will respond when a user interacts with it. There are many tools to build digital prototypes; you don’t need to learn how to code to make them, which is nice.
Model
Even something as unsophisticated as a scale model could be considered a prototype. Below is an image of a scaled-down model of a Center for Children Who Can’t Read Good and Who Wanna Learn To Do Other Stuff Good Too.
What’s the Best Type of Prototype?
This is kind of like asking “what’s the best exercise to do in the gym?” It kind of depends on what you’re trying to accomplish. It’s a pretty stupid question, actually.
The best type of prototype is the one that most effectively accomplishes your goal.
It’s the tool that gets the job done most efficiently (efficient = lowest cost, fastest).
Product developers with a wide understanding of prototyping tools and best practices are best equipped to design prototypes efficiently.
Next we’re going to get into the topic of Build-Measure-Learn, which is the whole point of prototyping.
16c. Build-Measure-Learn
As said before, prototyping is one of the most important things in all of product development. It’s how you go from concept to product.
The essence of prototyping can be captured in three simple words: build, measure, curse learn.
If I had to summarize what a product development team is doing most of the time, it would be this: people are building shit, measure shit, and learning shit.
Build-Measure-Learn Distilled
Prototyping is about building something that might work, testing to see if it does work, and then learning from the result. Build, measure, learn. That’s it.
Some people change a word or two when describing this process. In general, everyone is talking about the same thing.
Build-measure-learn is ultimately a learning mechanism. Prototyping is a learning mechanism.
“…the basic cycle consists of taking the current thinking regarding the design, building a prototype that embodies the key aspects of that thinking, and then testing that prototype to determine where additional design refinements are and are not needed.” — Revolutionizing Product Development
Why is it So Important?
Product development is a process that involves hundreds or thousands of decisions.
In product development, we must go from a state of high uncertainty to a state of low uncertainty.
In order to make better decisions and to reduce uncertainty, you need knowledge. In order to have knowledge, you need to learn. How do you learn? Through prototyping.
Iterations
Product development — and prototyping in general — is highly iterative.
If we knew how to get the product right on the first try, we wouldn’t need prototyping…but we don’t know how to do that, ergo we need prototyping. (Not often you get to use the word “ergo”)
You’ll hear terms like “iterative” or “loops” or “cycles” or “spirals” thrown around in product development. In general, these are all the same thing — they describe the build-test-learn process.
You may also hear the term iteration velocity. It’s a fancy term, but a basic and important concept.
Iteration velocity — the speed with which a person/team/organization can build, measure and learn.
Iteration velocity will determine how many loops or spirals can be achieved in a given time period. If you’re constrained by a market launch target, which is often the case, then your iteration velocity will determine how much learning you can achieve before you go to market.
More learning, better product.
Faster iteration velocity, more learning.
Faster iteration → better product. (That’s the transitive property #logic)
16d. Learning Systems
At the risk of being too academic, I’m going to take a minor detour to talk about the fundamentals of learning very briefly.
This detour will illustrate why “Build-Measure-Learn” isn’t some “new” system invented in the last few years. It’s sort of what everyone has been doing everywhere to learn about stuff.
Learning System 1: The Scientific Method
Yes, this is the thing you learned about in middle school.
I don’t really know how to put this, but the scientific method is kind of a big deal.
It’s not an exaggeration to say that the Scientific Method is the framework used to make some of the most important discoveries in humanity — you know, things like the evolution of species, vaccines, DNA, and gatorade.
You can read all about the scientific method on wikipedia, but here’s the distillation: the scientific method involves making a hypothesis, running an experiment, and then comparing the observed results against the prediction.
Look familiar? The Scientific Method is a lot like Build-Test-Learn.
Learning System 2: P.D.C.A.
- Plan — what did you plan to do?
- Do — what did you actual do?
- Check — what was different between the plan and the do? Why?
- Action — now what?
P.D.C.A. is technically a control system, but it’s also fundamentally a learning system.
It asks “Why didn’t the thing that actually happened match what I wanted to happen, and now what do I do about it?”
Sound familiar?
Learning Systems
The Scientific Method and P.D.C.A. are both examples of learning systems. They are a codified process — a system — for learning. Just like the Terminator.
Machine Learning actually happens through a process not that different from Build-Measure-Learn or the Scientific Method. Cool, right?
Also…“the more contact I have with humans, the more I learn”…this is pretty accurate for product developers, not just robots from the future sent back in time to kill or protect us.
But I digress…
Build-Measure-Learn is System for Learning.
Build-Measure-Learn is the (pronounced thee) preferred system for learning in product development. There has yet to be a system invented that works better.
This is because Build-Measure-Learn is basically modeled after the Scientific Method. And since the Scientific Method has been around for centuries, I’m guessing Build-Measure-Learn is going to be popular for quite some time.
Last Point — Have a Hypothesis
In the Scientific Method, it’s critical to have a hypothesis. Scientists don’t just run random experiments — they test certain theories or assumptions.
The same should happen in product development. Think of a prototype as a hypothesis and an experiment.
Prototyping should serve to test specific assumptions or theories — from “will this two parts fit together” to “will people actually like this product.”
Here’s a great quote on this topic from a great book on Innovation called The Other Side of Innovation (capital emphasis mine):
“Before launching an experiment, write down what you plan to do, what you expect to happen, and why. Draw lessons learned by analyzing differences between what you thought would happen and what actually happened. Then, based on lessons learned, revise the plan….THAT IS THE WHOLE BALLGAME! If you can execute this process rigorously and dispassionately, your chances of drawing the right lessons learned from a business experiment go up dramatically. The crucial learning step is the analysis of the disparities between predictions and outcomes. Through this analysis, assumptions are either validated or invalidated. Lessons are learned. Predictions improve. The process of learning through experimentation is the scientific method.” The Other Side of Innovation.
16e. One Prototype Does Not Fit All
To wrap up this first section on prototyping (oh yeah, this is just the beginning of prototyping…there’s more to come), let’s compare how prototyping works in two of the most prominent NPD methods out there: Waterfall and Agile/Lean.
Waterfall
Recall that in Waterfall, product development flows in a fairly linear path, from voice-of-the-customer activities to the product spec to prototyping and then to final product.
The Waterfall method places relatively more emphasis on “learning about the customer up front” and relatively less emphasis on “prototype and iterate until it works.”
This is because Waterfall is typically employed for products that are expensive to create, or products which need to be built right the first time. Think satellites or rockets.
In some of the best books covering Waterfall methodology (Winning at New Products, Product Design and Development), the topic of prototyping is not central or even all that prominent.
Sure, prototyping is in those books — it’s not like they don’t discuss it — and it certainly happens at a sub-system level. But the emphasis for Waterfall is on learning about the customer/consumer up-front, and getting the product spec right through rigorous vetting/analysis earlier in the process.
Lean and Agile
These days, the Lean and Agile methods have become more prominent as more and more NPD efforts focus on digital products (software, or apps) as opposed to physical products.
Since writing code is “free” (other than paying that pesky engineer), the one-and-done linear approach of Waterfall is less applicable and relevant.
Books like The Lean Startup and Four Steps to the Epiphany and Inspired reflect this shift. They are great books, and they all contain some universal NPD lessons, but they are definitely most applicable to software or startups.
Prototyping is basically the most important NPD process for these types of products because it’s “free” — and highly effective — to just code up a prototype and test it with actual consumers. The general ethos of these books is to just “build something and start learning.” Less emphasis is placed on upfront voice-of-the-customer activities.
We’re going to talk a lot more about Lean and Agile in coming chapters, so more to come…
In Conclusion
Prototyping is pretty, pretty, pretty much a universal activity in product development (read that sentence in Larry David’s voice).
It is the best method we have to go from a concept to a refined product.
“Except for the easiest of problems, developers are unlikely to come up with a complete, effective design in a single iteration. Instead, developers go through several iterations, learning a little more about the problem and alternative solutions each time, as they converge to a final design and complete, detailed specifications.” — Revolutionizing Product Development
Still, there isn’t a one-size-fits-all approach to prototyping.
Waterfall and Agile methods put a different emphasis on prototyping. This is because the cost (time and money) associated with prototyping varies significantly depending on what kind of product being developed.
In other words, how and when to use prototyping depends on the nature of the product itself.
That said, prototyping is universally about learning. No matter what type of product you’re developing or what methodology you’re following, you ain’t gonna get it right the first time.
Prototyping is a way to iterate forward, gain knowledge, and make better products.
Key Points on Prototyping
- Pretty much everything other than the final product is a prototype.
- There are lots of different kinds of prototypes — from “looks like” to “works like” to sub-system prototypes and wireframes.
- The goal of prototyping is to learn. It is a learning system, like the scientific method.
- The essence of prototyping is the Build-Measure-Learn cycle.
- Prototyping and product refinement is iterative: cycles, spirals, loops.
