Less Powerpoint, More Prototypes

I’m a big believer in hacking together a working prototype to demonstrate product ideas. Powerpoint mocks basically put a shiny gloss on a paper sketch and because it’s not real, generate endless debate where no one is really speaking on authority because the product doesn’t exist.

Once you have a prototype the debate becomes substantive.  Prototypes trump PowerPoint every time. Building a quick prototype is a way of sketching an idea – the emphasis should be on quick on dirty – get the pieces working with real data to see how things move, that’s it. Expect reactions and expect that you’ll need to tear it apart and redo things, that’s ok – expect that people might hate it and you’ll throw it away. Because of that, don’t invest too much time or ego into your prototype either, it will change, guaranteed. In this sense, churn is good.

This is why I really enjoyed Paul Buchheit’s post Communicating with Code where he writes about how both GMail and AdSense came together.

Of course none of the code from my prototype ever made it near the real product (thankfully), but that code did something that fancy arguments couldn’t do (at least not my fancy arguments), it showed that the idea and product had real potential.

The point of this story, I think, is that you should consider spending less time talking, and more time prototyping, especially if you’re not very good at talking or powerpoint. Your code can be a very persuasive argument.

GMail & AdSense were born from working prototypes, not PowerPoint.  Whenever possible, try and avoid PowerPoint for product design, unless it’s for art.