So far, we've explored user prototypes—which are pure simulations—feasibility prototypes for addressing technical risks, and live‐data prototypes designed to be able to collect evidence, or even statistically significant proof, as to the effectiveness of a product or an idea.
While these three categories of prototypes handle most situations well, a wide variety of hybrid prototypes also combine different aspects of each of these in different ways.
One of my favorite examples of a hybrid prototype—and an exceptionally powerful tool for learning quickly in product discovery—is today often referred to as a Wizard of Oz prototype. A Wizard of Oz prototype combines the front‐end user experience of a high‐fidelity user prototype but with an actual person behind the scenes performing manually what would ultimately be handled by automation.
A Wizard of Oz prototype is absolutely not scalable, and we would never send any significant amount of traffic to this. But the benefit from our perspective is that we can create this very quickly and easily, and from the user's perspective, it looks and behaves like a real product.
These types of hybrids are great examples of the build things that don't scale philosophy of product discovery.
For example, imagine that today you have some sort of live chat–based help for your customers, but it's only available during the hours when your customer service staff is in the office. You know that your customers use your product from all around the world at all hours, so you would like to develop an automated chat‐based system that provides helpful answers anytime.
You could (and should) talk to your customer service staff about the types of inquiries they routinely get and how they respond (a concierge test could help you learn that quickly). Soon you will want to tackle the challenges of this sort of automation.
One way to learn very quickly and test out several different approaches is to create a Wizard of Oz prototype that provides a simple, chat‐based interface. However, behind the scenes it is literally you as product manager, or another member of your team, who is receiving the requests and composing responses. Soon we begin to experiment with system‐generated responses, perhaps even using a live‐data prototype of our algorithm.
These types of hybrids are great examples of the build things that don't scale philosophy of product discovery. By being a little clever, we can quickly and easily create tools that let us learn very quickly. Admittedly, it's mainly qualitative learning, but that's often where our biggest insights come from anyway.