As so often happens, two different people in the old blogroll talked about the same general topic the other day. This time, prototypes:
- Steve O’Grady:
The net net is that most of the pitches I receive with respect to software are about telling me something, rather than showing me something. It’s one of the reasons that I love firms that ship me the bits; I don’t get to install everything I’d like to, but I play with as much of it as I can. Unsurprisingly, those experiences tend to be infinitely more compelling than anything that can described to me in a Powerpoint deck. And if that’s true of an analyst, how do you think a developer might feel? You think they’d prefer to see how they can use your product to mashup Google Maps and NIPP RSS concerts feed, or look at a couple of slides describing generic web services?
…
What do I mean? Let’s take databases, as an example. If I said that Derby can be used as a backend for offline, persistent browser based applications – how interesting is that really? No matter how I dress that up in PowerPoint or wordsmith it, it sounds dry and rather boring. But what if you showed that capability, live? You just might impress some very sharp people.
So the lesson in all of this is probably rather obvious: if you want to interest new audiences to your product – think about showing it to them. Or better yet, letting them show it to themselves. Because PowerPoint and press releases should be the fallback position, not the default option.
- Godin, via Cauvin:
“Too many times, I’ve gotten excited about an idea and created a conceptual prototype. And almost every time, people, smart people, didn’t get it.
Here’s my new prototype rule of thumb: your prototype has to be better (better build quality, faster interface, better lighting, whatever) than the finished product is going to be. That’s what people expect anyway–they see your prototype and take off 20% for reality.”
