Incremental Destruction

26 May 10

Great products evolve over time. It’s rare to get it right on the first try. So we iterate.

The ability to throw something out there and iterate is one of the biggest strengths of the Web — No software to update, no physical hardware to worry about. You can build out a lot of ideas and see what gains traction.

Iteration also leads to trouble. Take a simple, focused product and iterate, iterate, iterate. Pretty soon you’ve got a complex product with dozens of new features and a general lack of focus.

Every feature you added proved its worth when you initially tested it. Each one improved some part of the experience for some percentage of your audience. But taken as a whole, those new features made your product harder to understand, less targeted towards a specific use case, and more difficult to maintain.

This is really hard to see when you’re nose-down on a project. It’s difficult to say “No” to a new feature when the stats tell you it produces an X percent increase in Y.

The only solution to this problem is to take a step back and start over. Re-design the entire thing. This time you’ve got a deeper understanding of the underlying problem and will make a stronger first pass. Now test this new solution against the solution produced through iteration.

There’s a chance you’ll shift the stats to an entirely new baseline, far above where you could get through incremental improvements. Designing a monolithic change is a bigger commitment and risk, but it’s the only way to make a giant leap forward.

Photo by blopsmen under Creative Commons

If you liked this post, you should subscribe.