The Agile Approach To Launching Your Product

Sometimes knowing when to go live can be one of the hardest decisions. For the most part there are two approaches to getting your product ready for prime time.

• #1. Extremely long drawn out testing process internally, then launch to public and hope you got it right.
  build, test, test, test, test, months go by, test, launch (typically still find issues)
• #2. Quickly get to market. Fix / change / add things based on users response
  build, test, launch, revise, revise, revise, revise...

Method #1 is perfect if you're launching that banking site that handles large sums of money or any extremely mission critical application. You want that sort of thing to be perfect before going to market. It's key to the success of that sort of product. A bug in the code for handling people's money can mean death for your product. User confidence equals nill.

The thing to keep in mind, however, is that most sites are not this mission critical. Does this mean you should launch a site that is full of bugs and broken pages? Hell no! There is nothing worse than looking un-professional and losing user confidence before they even finish working their way through your site. Do your unit testing, use your app for a while, invite friends and family, get all the low hanging fruit issues cleaned up. Then pull the damn trigger!

Here is why method #2 is typically the right approach.

First off, you get to market quickly. This is more important than you may realize. Getting user feedback to help shape your product is huge, especially in the early stages. No matter how big your internal team is, they are not going to find every usability issue and think of every feature your users want. They just won't... period. Mainly because they have been working on the product too long. It takes outside feedback and lots of it to really flush things out. Listen to your users. Take everything into consideration, then based on that data make your next set of features / fixes. Naturally you can't build everything everybody wants all the time. You still need to filter out the not so important stuff and focus on bugs first, then features that the majority of your users MUST HAVE! Don't let your product become bloated down the road.

Going to market quickly can also give you a leg up on the competition. Even if your competitor is advertising they will have X more features than your product, but they plan to launch sometime next year... people will move on and go to a product that already exists. Your competition is already behind the eight ball now, meanwhile you're busy tweaking things to make your app a better experience for your user base not your QA department.

Secondly, you don't build a bunch of stuff no one wants because you need to get to market quickly and don't have time. This is a good thing. Create these restrictions if they're not there already. It's really easy to go hog wild with features right out the gate. So many web apps are chuck full with so many features and functions that users get lost. It's like when you go to a restaurant that serves everything under the sun. First off you can't decide what you want to eat, so you just get frustrated, and then nothing seems to sound good. Then you're wondering how on earth can they make a good philly cheese steak and have great sushi. Chances are both are half ass, and probably both will make you sick. Your users will feel the exact same way when you give them too many items in your products menu. How many times have you been looking for a web app to do X and found something that did everything else but X? Think you're the only one who was looking for X but moved on because it was cluttered, complex and still didn't actually do what you want? Doubt it. Guarantee you're not the only one.

Start with the core functionality. Keep it simple. Let the product evolve based on your users feedback. Build on features your users MUST HAVE and you can't loose.