When "minimal viable product" doesn't work

One of my favorite ideas in the new wave of programming is the notion of minimal viable product. The thought is that you should spec and build the smallest kernel of your core idea, put it in the world and see how people react to it, then improve from there.

For drill bits and other tools, this makes perfect sense. Put it out there, get it used, improve it. The definition of "minimal" is obvious.

Often, for software we use in public, this definition leads to failure. Why? Two reasons:

1. Marketing plays by different rules than engineering. Many products depend on community, on adoption within a tribe, on buzz--these products aren't viable when they first launch, precisely because they haven't been adopted. "Being used by my peers," is a key element of what makes something like a fax machine a viable product, and of course, your new tool isn't.

With enough patience and push and consistent enthusiasm, these products have a shot at crossing the threshhold. But if the mindset is "see what works and do it more," you'll often discover yourself giving up long before that happens.

2. There's a burst of energy and attention and effort that accompanies a launch, even a minimally viable one. If there's a delay in pick up from the community, though (see #1) it's easy to move on to the next thing, the next launch, the next hoopla, as opposed to doing the insanely hard work of sticking with that thing you already launched.

Inherent in the process of minimal viable product, then, is a trusting, large permission base that will eagerly listen to you, try your new work and let you know what they think. And you don't have the option of building that audience once the product is ready--that's too late.