Hypozooming
The goal of hypozooming is to take a specific but broad hypothesis and zoom in until you have a version of that hypothesis that is actionable and testable right now. It’s a way to go from XYZ to xyz, a smaller, simpler, more immediately verifiable version of your Market Engagement Hypothesis. The idea is that if XYZ is true, then xyz must also be true—but xyz is much easier to test and verify.
Let me explain using the XYZ Hypothesis from the pollution sensor example:
At least 10% of people who live in cities with an AQI level greater than 100 will buy a $120 portable pollution sensor.
This is a well-crafted, say-it-with-numbers Market Engagement Hypothesis, but it describes a huge potential market: millions of people living in all the polluted cities in the world. As it currently stands, this hypothesis is too big a starting point. It’s not testable—at least not anytime soon, and definitely not by a handful of undergraduate students with midterms looming and no real budget. Time to hypozoom.
Target Market Zooming: Y→y
The uppercase Y from your Market Engagement Hypothesis represents your ultimate target market—all the people in the world who you think will want to buy your product once it is available. To hypozoom, take that huge market and zoom in until you have a small, local, but representative subset of it. I want you to go from Y, the entire market, to y, a small, manageable, easy-to-reach initial test market. Imagine one of those videos where the camera zooms from a view of our planet in space down to a continent, then to a country, and then all the way to a city or even a specific building. That’s exactly what I want you to do in your mind’s eye with your hypothesis.
Be aggressive with hypozooming, but make sure that you don’t zoom in so close that you are left with a sample size too small to be statistically significant (e.g., your two roommates, your mom, and that weird guy across the street). So what’s a good sample size? Something in the neighborhood of 100 to 1,000 people would get a nod of approval from most statisticians. But you have to make sure that the population you sample is representative of your target market (the type of people who might actually buy your product or service).
For example, 100 randomly chosen people from the 328 million US population is a good sample size to test a hypothesis related to a new type of pizza, since most people like and can afford pizza. But if you are planning to sell a $120,000 all-electric two-seater car (like Tesla’s original Roadster), you cannot use 100 random people to get your data, because most people cannot afford or would not choose such a car. In this case, the testing should focus on the target market of, say, young, “geeky” millionaires.
Let’s return to our pollution-monitor example and apply hypozooming to it. Many cities have poor air quality. But the students in the team who came up with the idea for the portable pollution sensor are from Beijing, China, one of the cities with the most dangerous levels of air pollution in the world. So the first level of zooming for them is obvious: zoom from the entire world to Beijing.
Y: all the cities in the world with an AQI greater than 100
y: Beijing, China
That’s a good first step, but Beijing is a huge city with a population of over 10 million people. They need to zoom in further. After a few minutes of discussion, the team determines that parents of young children might be an ideal target market. One of the team members mentions that his sister’s children attend Beijing Tot Academy, a private bilingual preschool in Beijing with about 300 students. He thinks that his sister would be willing to present the product at the next parents’ meeting to see how many of the parents would be interested. Fantastic. They zoomed in from the entire planet to a specific preschool with 300 children:
Y: all the cities in the world with an AQI greater than 100
y: Beijing Tot Academy parents
Since they’ve zoomed into China, they also change the currency from US dollars to Chinese yuan and now have the following xyz hypothesis:
At least 10% of Beijing Tot Academy parents will buy an 800-yuan portable pollution sensor.
This is great progress. They now have a say-it-with-numbers hypothesis based on a subset of the target market that they can easily reach. But they still have a big problem: they don’t have the product yet! At this point their portable pollution sensor is just an unrealized idea stuck in Thoughtland. Designing, developing, and manufacturing such a product will take at least one year and a lot of money. Even a one-off prototype will take a nontrivial investment and months to develop. They are stuck in a sort of chicken-and-egg problem. They need to validate their Market Engagement Hypothesis to make sure their product idea is The Right It before investing a lot of time and money to build it. But to validate their MEH they need to have their product already built. Or do they?
The only way to know—with 100 percent certainty—if our idea for a new product will be successful in the market is to develop it, manufacture it in quantity, run a proper marketing campaign, and see what happens. In other words, we go forward on the hope, “If we build it, they will come” (another inspiring line from Hollywood movies that, like “Failure is not an option,” sounds great but usually works against you).
This approach, however, is a very expensive and risky way to find out if an idea is The Right It—especially since we know that most ideas will fail in the market. But what alternatives do we have? After all, we’ve learned that we can’t depend on Thoughtland-based, opinion-driven market research—too many false positives and false negatives. We know that we need data and not opinions. But we’ve also learned that we cannot depend on OPD; we need to collect YODA. That makes sense, but how can we collect YODA until we have built a product to collect it with?
That’s where pretotyping comes in.
5
Pretotyping Tools
Pretotyping is a word I made up. Why would I want to do that? The best way to explain why we need a new word and why it’s relevant to our quest for The Right It is by sharing with you the example that led me to it.
The IBM Speech-to-Text Example
I first heard this story at a software conference a few years ago. I am not sure how accurate my description of the events is and I may get some details wrong, but in this case the gist of the story is much more important than the details. With that caveat, here’s the story as I remember hearing it.
A few decades ago, well before the age of the internet and before the dawn of ubiquitous personal computing, IBM was best known for its mainframe computers and typewriters. In those days, typing was something that only a few people were good at—mostly secretaries, writers, and some computer programmers. Most people typed with one finger, slowly and inefficiently, so companies depended on professional typists, who were relatively expensive and required things like bathroom breaks and once in a while free bagels and coffee to help keep up the morale.
IBM was ideally positioned to leverage its leading position in the computer technology and typewriter market to develop a speech-to-text computer. This technology would allow people to speak into a microphone and see their words and commands magically appear on the screen with no need for typing. By reducing the need for professional typists and eventually replacing them, the technology had the potential for making a lot of money for IBM—if the company could make it work and if the intended users were comfortable using it.
In Thoughtland everyone, with the possible exception of professional typists, loved the idea. Many people wanted to use computers, but none of them wanted to learn to type. Besides, along with flying cars, computers that understood human speech were what most people expected to see in the future. But before making what would have been a decades-long and very expensive R&D commitment, the company wanted to ensure that its target market, businesspeople, would respond positively to this technology, not just in Thoughtland but in the real world, after experiencing firsthand how it would work and what it could do for them. The best way to do that was to expose them to a prototype version of the technology. But one major problem
stood in the way.
In those days, computers were much less powerful and considerably more expensive than they are today, and a speech-to-text function requires a lot of computing power—more than what computers could provide at that time. Furthermore, even if adequate processing power were available, accurate speech-to-text translation is a very difficult computer science problem, which we are only now beginning to tackle successfully. In other words, IBM was decades away from being able to put together a proper prototype, but it needed something in order to validate a key hypothesis about its target market. IBM researchers came up with a brilliant solution.
They set up a mock workstation with a computer box, a monitor, and a microphone—but no keyboard. They told several potential customers that they had a prototype of a revolutionary speech-to-text computer. They then gave the would-be clients some basic usage instructions and invited them to try out the new invention. Skeptical but excited, people took the microphone and spoke into it: “Dictate new letter. Dear Mr. Jones, In reply to your letter dated . . .” After just a couple of seconds’ delay, the text of their letter appeared on the monitor.
All users were impressed. This was too good to be true, which—as it turns out—it was.
What users thought was going on.
What was actually happening, and what makes this such a clever experiment, is that no speech-to-text machine existed, not even a prototype. The computer box in the room was a dummy. In the room next door, a skilled typist was listening to the user’s voice from the microphone and typing the spoken words and commands into a computer using a keyboard—the old-fashioned way. Whatever the typist entered on the keyboard showed up on the user screen, leading the user to believe that what appeared was the output of an actual speech-to-text machine.
What was actually going on.
IBM learned quite a bit from this experiment. After being initially impressed by the “technology,” most of the people who (in Thoughtland) were convinced that they would buy and use a speech-to-text computer changed their minds after using the system for a few hours. Even with the fast, near-perfect translation simulated by the human typist, using speech to enter more than a few lines of text into a computer proved too clumsy and problematic in several ways. People’s throats would get sore after a couple of hours, so much talking created a noisy work environment, and it was not suitable for confidential material. Imagine dictating a letter saying, “We need to fire Bob from accounting,” as Bob is passing by.
IBM’s approach was ingenious, but what would you call it? The speech-to-text setup with the typist was not a proper prototype—not unless one were planning to create a breed of miniature typists, stuff them into computer boxes, and feed them cheese and crackers through a floppy-drive slot. IBM did not have a prototype speech-to-text system; it only pretended to have such a prototype. And it needed to pretend, because if the test users knew of, or even suspected, the presence of a person instead of a computer at the receiving end of the microphone, they would have acted very differently, and the results would have reflected that.
The first time I heard this story I was left—er—speechless. My first thought was: “Why didn’t anyone tell me about this before!?” Like most people, I had spent years working on projects and products that turned out to be The Wrong It. We had built some prototypes first, of course, but the primary goal of those prototypes was to see if and how we could build the product; we were working on the assumption “If we build it, they will come.” We often spent months and millions just on those prototypes. And once you’ve invested that much time and money to develop something, it becomes really painful to call it quits—even when the actual market response is negative. So you tend to keep going, adding new features and making tweaks, hoping that somehow the situation will turn around. It’s an expensive and dangerous spiral.
Pretotyping
As an engineer, when I think of a prototype for a new technology I imagine a clumsy, hacked-together, wires-sticking-out, not-ready-for-prime-time version of that technology. What IBM did, however, struck me as something different enough from our common notion of a prototype to deserve its own word. The first word I came up with was pretendotyping. I thought it was an appropriate term because the IBM team, years away from being able to put together a proper prototype, pretended to have one.
But, although evocative, pretendotyping proved awkward to say or write, so I simplified it to pretotyping. The word worked well for me because the prefix pre- suggests something that comes before something else. In this case, pretotyping comes before prototyping, and the noun pretotype describes an artifact that precedes a prototype. So pretotyping combines the critical elements of both “comes before” and “pretending.”
Over the years, I’ve learned (primarily through hostile tweets and snarky comments on various social-media platforms) that a few people really dislike the word pretotype. They think that the word prototype already covers all the bases, so there’s no need to craft a new word. I agree with their premise, but disagree with their conclusion. Prototype does cover all the bases—but that’s exactly the problem! The term is too generic; it can mean anything. As it’s currently used, a prototype can refer to anything from a 5¢ paper-clips-and-rubber-band contraption to a $5 million one-off working version of an idea. I’ve seen the term prototype used to describe five-minute experiments as well as five-year projects involving hundreds of people.
Furthermore, prototypes and pretotypes serve different functions. Prototypes are primarily designed to test if an idea for a product or service can be built, how it should be built, how (and if) it will work, what’s the best size or shape for it, and so on. Pretotypes, on the other hand, are designed primarily to validate, quickly and cheaply, if an idea is worth pursuing and building in the first place—a different objective that is best accomplished with a different set of techniques and best served by having its own vocabulary. In fact, in the rest of the book, I will not only use the word pretotype, but assign unique names to the different types of pretotypes. Is all this new nomenclature necessary? I believe so. Let’s see if I can get you to agree with me.
Is it necessary to have names for different types of insects? A bug is a bug after all.
In our pantry we have boxes of spaghetti, spaghettini, linguine, fettuccine, bucatini, ditalini, and tortellini. What’s the difference? Pasta is pasta. Someone should tell those pasta companies to stop confusing us with all those varieties.
What about karate, judo, jujitsu, kung fu, aikido, and tae kwon do. How many exotic ways can there be to kick someone’s butt?
And do we really need all those names for the countless ways we can fall ill? Do you really need to differentiate a cold from the flu? One type of infection from another? A stomachache from appendicitis? Food poisoning from radiation poisoning? One prescription pill from another? After all, sick is sick, and medicine is medicine. I will stop here, but you can see where I am going.
In many fields, including ours, the right words help us to work and communicate more efficiently and with greater precision. More important, the right terminology sets the proper expectations and influences how we approach a situation. I would prepare for and approach crossing a river very differently than I would a creek—even though, technically, a river and a creek are both flowing bodies of water. Similarly, a six-month schedule and $300,000 budget would not be out of the norm for a prototype, but it would be totally out of line for a pretotype because, as we shall see, the word pretotype implies schedules that are measured by hours (or days at the most) and budgets that rarely go above a few hundred dollars.
If you are still unconvinced about the need for new terminology, I hope you will not let that stop you from reading on and applying the tools and tactics I am about to introduce. I’d hate to lose you over a minor lexical matter. Feel free to replace pretotype with prototype, if you must. But please keep an open mind, because I am confident that, if you give it a chance, you will see that benefits of our more precise terminology are wel
l worth the minor cost.
* * *
In 2009, while I was at Google, I started explaining the terms pretotyping and pretotype to my colleagues in engineering and product management. Much to my surprise, almost all of them found the approach not only interesting, but applicable to most projects and potentially very useful in preventing investment in The Wrong It. In fact, many of them, after hearing the IBM speech-to-text example, said something along the lines of: “I wish we had done something similar with our last failed project. It would have saved us a ton of time, money, and embarrassment.”
That’s when I decided to see if I could uncover other examples of pretotyping.
In Search of Pretotypes
It’s a well-known phenomenon that when your mind is focused on something, you begin to see instances of that thing all around you. For example, if you are thinking of buying a Volkswagen convertible, you start seeing VW convertibles all over the road. Something similar happened to me with pretotyping. After hearing the IBM speech-to-text story and coming up with the term pretotyping, I started to notice and collect anecdotes and examples of techniques that, like the IBM example, could qualify as pretotyping.
I also started researching and collecting instances of ideas for new products that had failed in the market despite all kinds of optimistic predictions. I eliminated from that set all the failures that could be attributed to poor execution of the idea, so what I had left was a list of well-executed failures. These were ideas that FLOPped in the market not due to incompetent execution in Launch or Operations, but because the very Premise of the idea was off—the idea was The Wrong It. This is not only the most common failure scenario, but also the most costly and painful one: we work hard to build It right, only to discover that we have built The Wrong It. Ouch.
The Right It Page 7