When Erick and I set out to build LiveShow, we wrote down literally every idea that came to mind. No matter how outrageous, complex, forward thinking, backwards thinking, or idiotic, if it was an idea related to booking shows we wrote it down. When it came time to actually build the application, it became my job to keep us on the straight and narrow. Because as we worked on the application, more ideas came to mind.

Is it Absolutely Necessary

Eventually it all came down to one simple question: Is that feature/idea absolutely essential to booking a show for your band?

If the answer to that question was a “No” then we shelved the idea for possible later inclusion.  It might seem like a really weird idea to not build as many features as possible, but doing so keeps you on the path to actually launching your product.  If we hadn’t followed that one simple rule when deciding where to focus our work, Erick and I would still be working on LiveShow and wouldn’t have gotten it out the door.  If you don’t ever release your product/application then you can never make money off of it.

Release Early, Release Often

Creating an an application that runs and works on the internet means that you can release a product early and gradually add to its feature set as time passes.  The phrase is often heard in what is known as the “agile development method” and it’s called “Release early, release often” and it means to release the product at the earliest possible point and then gradually improve it over time (have many successive releases).

If you want an example of a company that does this frequently, look no further than Google.  A good example of Google doing this would be Gmail, their online email product.  When Gmail was first released it allowed you to do 2 things with the emails you got: read them or archive them.  There was no “delete” button because Gmail gave users one gigabyte of space, compared to Yahoo and Hotmail which gave around 250 megabytes of storage, that was a lot of space.  They believed you’d never need to delete an email again.  Over time they found that customers really wanted to be able to delete so they added a delete button, and then they add a “Trash” folder so you could recover accidentally deleted emails.  They also over time added Google Talk to Gmail.  And more recently they added the ability to make phone calls from within Gmail.  Gmail is just one example of Google doing this.  Android is another example, so is Google Calendar.

The idea is to get your product out in front of the public.  Even if it doesn’t have all the features you’d want it to have, if it at least accomplishes the basic goal of the application then it’s good enough to launch with.  Just because you launch it doesn’t mean it’s done.  You can still make changes, add features, and fix bugs.  Getting the product out in front of people allows you to figure out how people will use your application.  You might find that they use it in a way that you hadn’t foreseen and that might give you a whole new direction to go in (read about Flickr’s early beginnings for a good example of this).

Conclusion

When you start to build something, ask yourself what is the absolute essential things your product needs to allow users to achieve their goals.  If a feature or idea isn’t a part of that, then shelve it for later.  You want to get the product out to the public so they can use it, not keep it to yourself until it’s “perfect” because realistically it will never be perfect.  Get it out there.