Innovation Is Overrated

Whenever I write about incremental product development driven by user feedback, somebody always chips in with “but…innovation!” and “you can’t work from wish lists!” Let’s start with the first of these.

The need for innovation in a new product is a myth. Usually, “innovation” people imagine that they’ll start with a “Great Idea!, built in “stealth mode,” and released with a big bang. That approach fails 100% of the time when rounded to the nearest integer. The VC failure rate is famously 90%, but that’s with considerable vetting. The failure rate is much higher when unvetted products are added.

The vast majority of successful products are not innovative at all. Consider the spreadsheet, which automated a paper process—no real innovation. More to the point, the first couple of attempts failed. Does anybody even remember VisiCalc or Lotus? You could argue that automating a paper spreadsheet was innovative, but Excel, which was the third major attempt to hit the market, was not innovative at all, just an incremental improvement on prior attempts, and it’s the one that succeeded. In other words, success came about through incremental improvement. The companies that did the innovating failed. Other huge product segments work the same way: dating sites == personal ads with pictures, Uber == limo services, DoorDash == pizza delivery. Incremental improvement driven by customer or market feedback leads to success, not big-bang “innovation.”

Often, when innovation occurs, it’s invisible. Google search, for example, was one of a long line of search engines. The innovation was the algorithm, not the idea of web searching. In AI startups, the LLM (the innovative part) is usually buried deep in the product. I’ll happily admit that ChatGPT might be an exception to my rule. It was truly innovative at the surface level, but it’s built on decades of prior research—incremental improvement, and it’s losing billions of dollars annually.

So where does that incremental improvement start? I think the best approach is to identify a very small pain point—a problem that people are having. Collaboratively develop the smallest possible solution, gather feedback, and improve based on it. The smaller the thing you release, the better. You want feedback as early and often as possible—ideally during development, not after. (One of the problems that I have with Scrum-as-usually-implemented is that the team doesn’t get feedback until the Sprint Review, which is too late. If the review comes back with a “nah,” you’ve wasted the entire Sprint.)

You’ll note that none of this incremental improvement comes about from working through a wish list. I suggested starting with a problem. A wish-list approach starts with a (you hope) fully formed solution. That never works in my experience. “Customer driven” does not mean “mindlessly implement a wish list.” It _does_ mean: get regular feedback from your (potential?) customers during development to assure that you’re building something somebody actually wants.