“If you build it, they will come.” Field of Dreams

In this iconic movie, Kevin Costner’s character hears a voice that tells him to plow part of his cornfield and build a baseball field. Once he builds it, they will come—the people he is supposed to help. And when he builds it, they do come.

As a former open source developer, I’m quite familiar with the build mentality. It’s in my DNA to build things.

But, unlike the movie, just because you build it (e.g., a web app or an iPhone app), it doesn’t mean they (users or customers) will come.

Solve a Real Problem

Don’t fall into the trap of building to build. Build something that solves a real problem, ideally one that you have faced. As Paul Graham writes, you don’t want your startup solving a problem no one has.

No one is going to pay you money or spend serious time with your product if it doesn’t solve a problem they have.

Many startups and “wantrepreneurs” believe a product is a business. It is not. A product is not a business, rather, a business sells products.

I continue to be amazed by how many startups fail to understand this simple fact.

Run More Experiments

A startup is an experiment to find a repeatable business model.

A business model implies an inherent business—you have a product that people are willing to pay for. Or, in the case of a free product like Facebook or Twitter, if you’re not paying for the product, you are the product (e.g., your data is sold to personalize ads shown to you).

Figure out what business you’re in before you get too far. Keep it manual at first to find product / market fit.

Don’t Over Engineer

Ship code and new versions often. Focus on a single or small set of features. Iterate.

It’s far too easy to over think and over engineer a product. If you build in a vacuum, you have no data on if your approach is solving a real customer problem or not. You might even blow through $40M on a product no one ever wanted (ahem, Color).

When I was building MothersClick, as co-founder and CTO, I suffered this same problem. We had some incredible technology (part of the reason Lifetime Television acquired us), but we had many unused features. I burned countless hours building features that didn’t really help our users. I built more and sold less.

Quick iterations, with built in feedback loops, would have let me build the features that really mattered, instead of developing ones no one wanted.

Be Embarrassed

“If you’re not embarrassed by what you shipped, you waited too long.”Reid Hoffman

Looking back to every piece of code I shipped, every website I made (including this blog), the first iteration has always been embarrassing. Even with lots of planning, in retrospect, it always stunk. So why waste so much time on it?

Ship it and fix it.

Rap Genius calls this “worse is better” and I love it.

It’s also how Sir Richard Branson started Virgin Airlines. He sold something before it was ready. In retrospect, his inaugural flight was quite embarrassing, but it worked. He addressed a real problem, ran an experiment, and didn’t over engineer. His first flight is quite embarrassing when compared to today’s fantastic Virgin America.

He built less, and sold more.