Incremental vs. revolutionary improvements
The true art of product or service development might come down to this:
Knowing when it's appropriate to make incremental improvements and knowing when you need a revolutionary leap.
Do you continue to patch, tweak, tune or do you throw away the old assumptions and start with a completely fresh approach?
This is obviously a complex issue, but the metric we use is this:
If you're competing for market share, with products or services that are hard to differentiate, incremental improvements might be a waste of time and resources!
That's how we looked at the computer technical book market. We set out to write just one book, Head First Java. We said, "There are over 2,000 currently-selling Java books on Amazon. We have very little name recognition, especially among people who don't yet know Java (the audience for our book), so what can we do?" And in fact most publishers, book reviewers, etc. were saying, "Does the industry even need yet another intro to Java book?!"
We saw that there was a big gap in usability/learnability for a lot of programming books, and knew from our backgrounds in artificial intelligence, learning theory, and interaction design that there was an opportunity to make a major difference, if we could find a publisher willing to let us make the leap. So we proposed the idea to a major publisher (not O'Reilly). The publisher said, "That's way too radical and people won't accept it, but we'll let you do 10-20% of what you want and we can see how it goes..." In other words, they wanted us to make incremental improvements to the learning model used in the books we were going to be competing with. We declined, even though we were really anxious to have a book published, because we believed that without a revolutionary jump in the learning experience, we'd be in for a horrendously bloody fight, kicking and clawing for market share in an overcroweded field against successful competitors who were much better known.
A revolutionary improvement was taking the commonly-held assumptions and tossing out as many as we could if they stood in the way of a good learning experience. The thing is, there isn't anything revolutionary about Head First books if you view them in the context of all learning experiences, or even just the subset of "books designed for learning." You've all seen books that use visuals, surprise and novelty, strong metaphors, different learning styles applied to the same topic, etc. The difference is simply that you didn't see that in programming books.
So "revolutionary" often just means "revolutionary in THIS context." And that's also a way to think about where to find ideas for revolutionary improvements... look at what's being done in other domains, that might work in yours. In our case, we looked at trying to replicate as much as possible the things that make up a good classroom experience, and apply that to a book. In other words, instead of studying what's good about books, we looked at what's good about classroom experiences, and then we looked at books (largely children's books) for more ideas on the ways in which classroom learning could be mapped into a book. We didn't do a great job, either. But the leap was enough to make a significant difference to the majority of the market for those books.
In fact, when we look at it now, we realize that a lot of what we did in the Head First books was still mostly incremental improvements, and that we were still basing a lot of what we did on the way it's usually done. We chickened out in a lot of areas. (Which is why we designed another new series that you'll see the first books in near the end of this year.) But it's really hard not to make only incremental improvements, because the natural tendency is to focus on improving what's already there. You ask the question, "How can we make this thing better?" Instead of, "What are we really trying to accomplish for our users?"
One of the hardest things to do is throw away what you've worked so hard on. That could mean throwing away real stuff--physical products or software code--or throwing away ideas. There's a certain amount of unlearning that usually has to happen, as well as letting go of things you might be especially proud of. ("Killing your babies" is the expression many writers use.)
The biggest problem with incremental improvements is that they often lead, eventually, to an impenetrable wall that stops you from ever ending up where you really need to be. You can't get there from here. In the good old days, you could solve that by simply out-advertising/out-marketing the competition. Well, that's out. (See Hugh, Seth, and other neo-marketing folks for thoughts on that.)
But today, there's more supply than demand of just about everything, and the competition is fiercer than ever. You certainly don't want to go down that road of competing solely on price, but if everyone in the game is trying to make incremental improvements, the liklihood of anyone breaking through in a significant (let alone lasting way) is slim.
FYI -- I'm reading a book somewhat related to this, based on the idea of creating Blue Ocean Strategies (the book link is on that site). It's premise is that competing for market share is the "bloody red ocean" and that what you really want is the "blue ocean" where the competition is simply irrelevant, because you've created "uncontested market space." I was quite skeptical of the book ("Oh, yeah, it's really simple -- just make the competition irrelevant") , but having gone halfway through the book, I'm starting to be a believer. Their approach really does offer a variety of different, concrete, do-able strategies for looking for ways to make this possible.
And while we're on the subject of incremental vs. revolutionary improvements, I wouldn't assume that this applies only to products or services (or, say, a legacy school system). It applies to your whole life. I've known marriages, for example, that were failing with patches, tweaks, and tunes--but who survived and eventually thrived by taking a revolutionary step (moving away from the meddling in-laws, quitting the stressful job, choosing a simpler life, throwing away the television, etc.) And I've known people who gave up on incremental career improvements, made the revolutionary personal leap and changed their life in a dramatic way. Remember, thanks to what we now (and only very recently) know about the neuroplasticity of the brain, it's never to late to create You 2.0".
Posted by Kathy on March 28, 2005 | Permalink
TrackBack URL for this entry:
Listed below are links to weblogs that reference Incremental vs. revolutionary improvements:
Posted by: Terry Storch | Mar 28, 2005 7:44:24 PM
Well put. But here is an interesting twist. What happens when you have a company whose IT department has gotten a little too revolutionary? So, for example instead of asking the end-user what they believe is the best way to identify themselves to the system, the IT department huddles in a room, and comes out with bio-metric finger readers. (Keep in mind noone in the room has ever looked at a bio-metric SDK).
Now, this seems "cutting-edge". I would agree. I actually promoted the finger reader idea. But the problem is the part where they didn't ask the end-user. And I really should be saying we, as I was in the room. It felt like we were dictating a paradigm instead of growing one. The end-users don't care about bio-metrics, they really only want the system to recognize them with as little effort on their part as possible. It seems to me, if we ask them, they will give us the best answer.
So what do you do to departments that need to possibly "unrevolutionize" their thinking and just get back to simple problem solving? Is this taboo thinking now? Am I missing something?
Posted by: Clint Hill | Mar 28, 2005 9:23:55 PM
As usual great post Kathy...
Posted by: Prasanna | Mar 28, 2005 9:27:53 PM
One of my heros is Kepler, he spent 25 years working on epicircle orbits for planets, then finally threw all that work out because it couldn't explain what they were actually seeing in the night sky.
Few people have the guts to toss 25 years of their work and lives away just because it didn't work.
Posted by: Stephan F | Mar 29, 2005 10:12:48 AM
Of course, the big assumption here is that you're starting from scratch. If you already have a successful product, you can get a lot more mileage from making continuous, small, incremental improvements than revolutionary ones. In fact, I'd argue that revolutionary changes in successful products are actively dangerous and harmful. (Consider the shift from Mac Word 5.1 to Mac Word 6, for example. Yuck! Worse yet: VB6 to VB.NET. Or Mac OS 9 Finder to Finder X. The list goes on.) You can add revolutionary or evolutionary new features, if they're needed--for instance, Mac OS X 10.3's Finder is an improvement over Mac OS X 10.2's, though it still hasn't reached the level achieved by OS 9--but you shouldn't change what's already working.
Of course, if the product isn't already working, then there's justification for more radical changes. A lot of the underpinnings of Mac OS 9 weren't working: multitasking, I/O, memory protection, and more. They needed (and got) revolutionary change in OS X. But most successful products don't need this.
Posted by: Elliotte Rusty Harold | Mar 30, 2005 5:43:28 AM
The comments to this entry are closed.