What I learned about Pretotyping

Patrick Copeland from Google gave a facinating talk about a concept called Pretotyping (or Pretend-o-typing). His talk dovetailed nicely into the conversations we've had at work about design thinking and illustrated in a powerful way how to use design thinking to push you towards making the right it.

For me the biggest take away was that innovators beat ideas. Everyone talks about ideas, but ideas in an of themselves are worthless. We all have ideas, and, frankly, can generate them a dozen a minute (or faster!). It is not really as much about the idea as the person behind the idea, the innovator. Innovators are a much rarer commidity. Innovators do not need to come up with a new idea, but what they do is more important. They test, refine, and reject ideas until they figure out what works, what the "it" than needs to be built is. As the pretotyping.org site says:

Because the number of ideas is practically infinite while the number of innovators is very finite, the innovators to ideas ratio is – for all practical purposes – close to zero. That makes innovators incredibly valuable.

Thus, Mr. Copeland claims (rightly!) that "Innovators beat Ideas."

At Edmunds, we are about to embark on a Design Thinking approach to building products. With this approach, we will interview, ideate, paper prototype, iterate, etc. What hit me was a very simple idea:  use the paper prototype over and over to test if the idea flys, don't just test it once on a user, pretend to use it, pretend-o-type!

As you use the pretend application, Mr. Copeland stressed tracking usage and really finding out how much the prototype is used and what the return rate is for users. Taking this a step farther, even after a product is launched, one should measure the new vs. repeat vistor rates. If repeat users are falling off, the idea is probably not a useful one. Here is where the courage comes, if the idea is not working don't agonize over it, kill it and move on.

Kill it and move on, is a scary concept for most businesses. Even the greats at Google, I am sure, spent a lot of time agonzing over the failure of Google Wave. However, in the end, they did kill it and they are moving on. The learning here was to makc a flop metric and stick to it and don't be afraid to admit failure and move on!

A side note: one can over test. Mr. Copeland alluded to Google tesing 100 shades of blue, probably a bit overkill.

 Back to pretend-o-typing, how does one go about testing ides quickly? Mr. Copeland showed a picture of the andriod "prototyping" kit he handed out. It consisted of a pad of paper and a pen! Draw a quick UI for your idea and stick the paper on your andriod phone. Track how much you use your own idea. If you use it a lot for the first week, how much do you use it the second? The third? If you notice your usage drift towards zero, you probably need to move on. Total investment to find out if your idea was good? Almost zlich. Compare that to the normal working prototype and the time and engery spent in building it. With the investment in a normal prototype one becomes very attached to their idea.

The next step is to remember that ideas beat features. The original Gmail and Facebook had a lot fewer features than their competitors, however, they where better ideas and thus took off. If the Gmail or Facebook team spent the time to deliver what they have today they would have missed the boat and probably would have built the wrong features. Your users will tell you what they want, but without something in front of them they can't.

So here is what I learned:

1) Innovators are priceless

2) Paper + Data == Awesome idea killer

3) Don't be afraid to kill your idea

4) Get your idea out there and test it and refine it – don't try make something perfect…you will fail.

 

Next up, Infrastructure.

Advertisements
This entry was posted in Management, Process and tagged , , , . Bookmark the permalink.

One Response to What I learned about Pretotyping

  1. I’m so bummed I missed that keynote. I’ll check the infoQ site for the video later.
    You said, “if the idea is not working don’t agonize over it, kill it and move on.” I’ve always found it difficult to determine whether the idea itself is not working or some aspects of it aren’t. Is it the idea itself or how I’m prototyping it that’s not working? Is it the idea itself that’s not working or is it just outside what Steven Johnson calls the “adjacent possible”? Is it not working now but could be working 5 or 10 years from now?
    How do you distinguish “good” ideas that aren’t possible today for reasons A, B, and C from downright bad ideas? What do we look for to help us make that distinction?
    Apple was experimenting with what eventually became the iPhone for 6 years before the product first hit the market. I’m pretty sure the idea in its first iterations wasn’t really working but they continued iterating over it and now we have what some might argue to be an “indispensable” product. What made Apple continue its efforts and not toss the whole thing out?
    I’m not really sure there is a clear answer to this, but it might be worthwhile to compile a list of “signs that your idea sucks” to allow people to identify the telltale signs of really bad ideas that just won’t work. Ever.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s