In How to make products that people love, Marty Cagan had tons of good advice for rapid product discovery, including the importance of finding the fastest, cheapest way to validate ideas. Chief among this toolkit is the rough live data prototype.
For teams working primarily with digital products, this type of rapid prototyping in software is easily accomplished. Add a hardware component to your product and suddenly, the assumption is that the problem just got harder and more expensive to solve. But as Google’s Tom Chi demonstrated at Mind The Product 2012, you can achieve much and learn more using everyday materials and a bit of ingenuity.
From zero to HUD in two hours flat
Chi’s team prototyped a fully working heads-up display on Day 1 of the Google Glass project, constructed from a coat-hanger, a piece of plexi-glass that happened to be lying around, a sheet protector bought from the local convenience store, a little wire harness and a netbook.
As with any minimum viable product, there is the demand for a minimum viable interaction. This simulate a working experience to test first hand, experientially, whether the idea is any good. Without physical input devices, the team’s next logical leap was to attempt to prototype the gestural interface as seen in Minority Report.
It took a mere 45 minutes to throw together a working prototype using the sort of stuff you’d find in any office; a coat-hanger, a whiteboard, fishing wire, a couple of hairgrips, a chopstick and a presentation clicker.
This Rube Goldberg-esque construction worked like so: Chi taped the coat-hanger across the top of the whiteboard, which created two little indentations. Over those indentations he ran a little piece of fishing wire, so that the indentations acted like little pulleys. He attached the hairbands to the ends of the fishing line.
To test the interaction, someone would put their hands through the hairbands. Any movement in the hands created tension on the line and pulled the wire upwards, activating the sub-assembly beneath which involved the chopstick as a lever to push down on the presentation clicker, effectively pushing a button that controlled software on the netbook.
In another hour, Chi pulled together some software examples that would be easily controlled by this interface, including an image gallery and an email app.
“We were working with the HUD literally on my first day at work. And learning a tremendous number of things that you couldn’t possibly just guess or estimate, or print out on a spreadsheet, or a project map, and that sort of thing.”
Two hours of playtime vs 10,000 hours of engineering time
The final example of rapid hardware prototyping came from the team’s attempt to find a comfortable form factor for the eventual product. The trick is using things like modelling wire, clay and paper, or as Chi describes them, materials that move at the speed of thought.
This time, Chi cut the clay to size, making sure it weighed the same as all the different electronic components that they were expecting to put into the product. He wrapped the clay up in the paper so it didn’t get too messy, and then using the modelling wire, he shaped the entire little bundle into some glasses.
“Using this process, I could prototype a new sort of morphology for the glasses in about 5 minutes. Maybe 10 minutes max. So in an hour or two, I could have done dozens. Now, the really critical thing that I discovered, and you see it in the product today, is that if you can put weight behind the ear, it makes the ear into a fulcrum, like a lever that actually removes the perception of weight in front of the ear. The other thing that I learned is that the perception of weight is mostly driven by how heavy something is on your nose. Turns out that your ears can take a lot more weight than your nose.
“So if you can create a system where the ear becomes a fulcrum, then the perceptual weight disappears. This took me about two hours to figure out. You go back to [other designs] — nobody figured it out. This is not just one team, this is dozens of teams. This is not just two hours, this is dozens of teams doing 10,000 engineering hours. And somehow they didn’t figure out something that’s very basic about the comfort of the device. Or maybe they were expecting that the product would only be used for 10 minutes. Either way, there are so many opportunities early on to avoid all these missteps and create something that you can wear all day.”
Rapid prototyping success lies in rate-based goals
Chi says: “We’re all pretty smart people here but the truth is that no matter what we start working on, there’s maybe a 5% chance that the thing we’ve started working on is the right thing, based on the first idea that comes out of our head.
“Now, if you end up having some startup idea and you chase after it and it has a 5% chance of success, you end up with a success rate of most startups. Less than 5% end up having a useful product or a great exit. But, here’s a little bit of math. By the time you try 20 things, even if each individual thing only has a 5% chance of success, by the time you try 20 things, your chance of success goes up to 64%. By the time you try 50 things, it goes up to 92%. It’s almost like you can’t fail!
“The most important phrase here is not ’20 things’ or ’50 things’ — it’s actually the phrase ‘’by the time’’. Because time is this thing that we can work with. What you do is you try at a test level to maximise the rate of learning by minimising the time to try things. Ergo, things that move at the speed of thought, things like clay, like fishing wire, things that take the shape of your thought really quickly.
“Now, you still need to be creative abut how you parlay something that moves at the speed of thought into an experience that is representative of what you’re trying to test. Like, if I used clay and fishing wire and didn’t actually feel like a Minority Report experience, we would have learned nothing. So try to find materials that move at the speed of thought and reduce your time to try things dramatically in order to maximise the rate of learning.
“Don’t ever guess. Just learn. It’s a waste of time to guess, and actually, most meetings are a guessathon.
‘Oh, I think in three weeks we can do that.’
‘I think this will work.’
‘I think users will prefer this over that.’
“These are things you probably hear a thousand times every day, at work. Stop it, basically. Don’t do that anymore. Just make the thing, just make it work and start to learn things.
“Also, I don’t believe in failing fast, because failing is just an approximation of learning. You can fail a lot without learning at all. And you can learn a lot without failing at all.
“So the whole point is about learning; it’s not about failing. But failing fast is a good enough approximation that it got us somewhere, but you don’t need that, it’s really just about learning.”
Reach for the stars from research to development
Chi’s advice for making breakthrough products is to allow enough space and time for a broad and shallow research approach before you dive into the narrow and deep headspace of development.
“In any hard problem, you’re starting with the complete unknown. If the thing is completely known and you’re just going to play through something and you’re just going to lay down a Gantt chart from the beginning to the end, then that’s called franchising, that’s not called invention.
“I think what is really confusing to the world is that engineers, and most product people and actually most people in business get trained on the development half of things. We actually don’t know a thing about research; we do it completely wrong. Development is all about narrow and deep; I want to be as efficient as possible with the resources that I have to build a specific thing in the shortest time possible. Let’s not waste a bunch of time. Research is the opposite. It’s broad and shallow. And if you go narrow and deep too early, you’re effectively wasting time.
“One great and terrible artefact of the broad and shallow approach is that you come up with tons of ideas that are amazing and could work. I call these things stars — because we will literally star them on the board. Now at the end of the broad and shallow process you end up actually with too many stars. Let’s say you do this and you might end up with 50 stars at the end of a 4-week rapid prototyping process. The truth is if you tried to fit all 50 stars into a product, it would be a Frankenstein product; it would be a disaster.
“This is where product management is so critical. You’ve got to make those hard decisions about what the product is going to be and it’s just as important to say what it’s not going to be as to say what it will be.”
“Most of the processes that we learn as product managers are actually pretty detrimental to the research side of things. So if you want to make a breakthrough, you need to create a space for something like this.”
Watch the video of Tom Chi’s talk!
We’ve also posted a full video of Tom’s talk on Rapid Prototyping.
Tom Chi’s slides from MindTheProduct 2012
Comments 4