This morning, Luke Wroblewski tweeted a manifesto on shipping incomplete.

lukew: Ok here we go…

lukew: Shipping early and incomplete is painful but necessary.

lukew: When you ship incomplete you don’t lose time polishing turds you thought were gems.

lukew: When you ship incomplete the features you need to work on become obvious as people try to make use of them.

lukew: When you ship incomplete you need to swallow your pride for the greater good of faster, more frequent learning.

lukew: It’s OK to ship incomplete UX when you are a designer. After all, design is never done.

Shipping incomplete is, I think, an extension of rapid prototyping. In traditional development, you have an idea, gather requirements, then develop a polished, feature-rich product. Rapid prototyping cuts the time between ideas and implementation by reducing functionality to the core. After you gather requirements, you cut everything that the product doesn’t really need to launch. But you still release something that’s relatively polished. If you ship incomplete, you’re skipping some of the glitter, and maybe even some of the core feature set.

As Luke points out, the advantage here is that you don’t waste time guessing on features—when people start using your product, necessary functionality will be obvious. Frequent upgrades also create momentum. Once the pain subsides, you’ll have serious velocity.

Large businesses and organizations want their product releases to sparkle. Brand managers are apprehensive—fear of criticism outweighs their willingness to take a chance. Delaying is an easy decision. It’s risk aversion. Then again, you will never see Apple launching just part of a gizmo. If your brand is sparkle, you better sparkle.

Rapid prototyping is much more appropriate for small, focused tech startups. Shipping incomplete is a way to launch even sooner, and continue building with real use cases informing design and development decisions. I’m a fan.