Google's product development mantra and the Tipping Point

I've been thinking about when and how to release and push out Linkspank's new toolbar / Firefox extension, which is really cool and quite well received by its small number of users so far. The question is “when and how to launch.”

For at least a few years, Google has advocated an approach to product development whereby you release your product at an early stage and then “iterate” - make improvements as users demand them and improve the process. Google has been voicing this mantra for a few years. This approach to designing a piece of software works best when you're building something simple and you can change it easily (the web is good for that). The philosophy is not too far off of the ideas espoused by 37Signals.

But also taken as a truism is what Malcolm Gladwell has to say in The Tipping Point. Small changes (say, in an Internet site) can make a big difference. Tipping-point thinking implies that your average cool website with a couple thousand users, like Linkspank, may be just a few crucial changes away from explosive growth.

Google's product philosophy and the tipping point meesage have something in common: tweaking. When you iteratively develop a product you have released, you're making pretty small changes. And in searching for the tipping point, you are trying to find the devilishly minor changes in your product that can take it from zero to sixty. You can think of iterative development as a way to search for the tipping point.

Here's a flipside, though. Part of the underlying message of the release-and-iterate idea is that people overestimate the risk of release. “If you get fairly close to the right product,” Google means, “your users will help you close the gap more efficiently than you would have done otherwise.” IF, that is, the customers know what they want; but as traditional marketing does a good job of showing, customers generally don't. And as the tipping point argues, it can be tough for anyone (designer or user) to identify that the small changes that are going to be crucial. That's in contradiction with Google's idea.

Moreover, the mere fact that small changes are critical according to the Tipping Point undermines one of Google's messages: that there is a low cost to release. Who are we kidding? Releasing a product always has a risk. Any potential user who turns away from your product may not turn back, so any time you to go them there is a risk.

It's easy for Google to proclaim iterate-and-release now that the company has a huge user base and a pervasive brand: they can easily tap into pre-zealous users, and if they alienate some users on some products, there are still billions of Google users out there for the following iterations.

The early days of Google – the development of search – was similar to release-and-iterate in some ways, and different in others. The founding duo was informal and agile when it came to making a product and trying it out. Nevertheless, the “releasing” they did in the early years was pretty cautious.

Release-and-iterate is not an answer in and of itself; you have to think about the risk of launching in terms of your resouces, and what you hope to find or achieve in your iteration (perhaps the tipping point).

Beware of mantras - Wittgenstein taught us that.

Anyway, the toolbar is coming soon and it's sweet!

Jason Fried and 37signals

I trekked to Providence to hear Jason Fried of 37signals speak this week.

Random picture of Jason Fried from somewhere else

I'll quote here:

Getting Real is about skipping all the stuff that represents real (charts, graphs, boxes, arrows, schematics, wireframes, etc.) and actually building the real thing.

Getting real is less. Less mass, less software, less features, less paperwork, less of everything that's not essential (and most of what you think is essential actually isn't).

Getting Real is staying small and being agile.

Getting Real starts with the interface, the real screens that people are going to use. It begins with what the customer actually experiences and builds backwards from there. This lets you get the interface right before you get the software wrong.

Getting Real is about iterations and lowering the cost of change. Getting Real is all about launching, tweaking, and constantly improving which makes it a perfect approach for web-based software.

Getting Real delivers just what customers need and eliminates anything they don't.

Lightning summary:

• I know and agree with his philosophy (maybe from influences of Google, non-tech aspects of my background, friends, my own laziness) -- this is definitely Super-Official Linkspank Philosophy...

• ... but I still found the talk useful and will probably check out their book (which you can read free online - go smarties). Based on my limited experience I have admiration for the products as well.

Cover design was not important to this book.

• The limitations and influences of Jason's theory are not well explored. When asked how Google had influenced him, Jason said he didn't know. C'mon! Google was the start of this with its pristine homepage back in '98.

• Another limitation can be inferred from Google's experience - this method doesn't work well for integrating products. Don't things become more complicated at some point? Isn't the process of managing many simple tools complicated, and isn't there some way technically to help a person do that? (Of course - like any operating system, microsoft office, your Google account.) The more you hammer on this point, the more the general philosophy starts to fall apart and becomes nothing more than "we prefer to focus on building simple products" :-).

The whole thing and especially the last bullet raises a question for Linkspank - which is its scope? How complicated should it be and how wide should its set of features be? Example: people often ask for features that other sites have, especially adding more photos :-).

Short answer: I think Linkspank's feature set can grow, but we still DEFINITELY have work to do around the core idea.