Build The Absolute Smallest Thing


Speed is of great importance when creating a new business. But the big question has always been whether to focus your resources on getting it right ( building the core model or architecture) the first time before opening your product to the public or releasing your minimum feature set to the public and getting feedback based on the first release.

release early , release fast

Which one provides a greater chance of success: Building the absolute smallest thing a that can be considered a complete app and then shipping it or focusing on building a great product before inviting the public to use the complete product.

Can you handle the risk?

The risk with releasing early and fast is that you could end up loading up buggy apps and you will shot your business down immediately. Users hate bugs, but they don’t seem to mind a minimal version 1, if there’s more coming soon. In a study by Compuware,  published on Techcrunch by Sarah Perez, 79 percent smartphone users report that they would only retry an app once or twice if it failed to work the first time. Only 16 percent said they would give it more than two attempts. Now that’s scary. Compuware says that 62 percent of users had experienced a crash, freeze or error with an app or apps. That’s not the kind of app you want to put out there. In any business half baked product will not go down well with users.

…but releasing early is popular

Releasing early is popular with a lot of successful technology entrepreneurs and investors. According to Paul Graham, it’s better to “get a version 1 out fast, then improve it based on users’ reactions.” Advocates argue that this allows the application development to progress faster, enables the user to help define what the app will become, better conforms to the users’ requirements and ultimately results in higher quality web or mobile app.
In the words of Paul Graham:

Perhaps the most important reason to release early, though, is that it makes you work harder. When you’re working on something that isn’t released, problems are intriguing. In something that’s out there, problems are alarming. There is a lot more urgency once you release. And I think that’s precisely why people put it off. They know they’ll have to work a lot harder once they do.

Doing something “simple” at first glance does not mean you aren’t doing something meaningful, defensible, or valuable.

It’s popular, but be cautious!

Of course it’s important to get your product out as soon as possible. As matter of fact, if you take too much time in your garage, your product may not stand the test of time when it finally hit the market. Read the times and trends and get the right app, product or service out when you have to.

Thoughts of some entrepreneurs

@jasonfried

If the entrepreneur finds themselves in a situation they can’t control it’s almost certainly because they put themselves in that position — either by borrowing too much, spending too much, rushing too fast, creating a false sense of urgency, hiring the wrong people, attacking a market that doesn’t exist, or not focusing on generating revenue early enough.

@delputnam

Don’t let this need for speed push you into releasing something with tons of bugs. Release on quality, not on date. Instead, put fewer features into your initial roll out. You can always add more features later.

The beauty of this model is that it lets you get early feedback from your customers and allows you to make changes…maybe even before you implement a feature. So, listen to what they have to say. And follow up on it. Make your customers happy and they will stick with you.

@asmartbear

When it’s early, you don’t know what’s “right.” That’s not just true of features; it’s true of architecture too. Anyone who claims to already know exactly which DB queries will be responsible for the bottlenecks or exactly how tables should be designed is kidding themselves.

@toddsattersten

When you commit to “release early and often” you have to actually do it. The unspoken truth is that creators and customers have only a vague sense of what is important early in a project, and by choosing scope as the variable to control, we don’t build a bunch of stuff people don’t want or won’t use.

What are your thoughts on releasing early and often  and getting it right before hitting the market with your product. What has worked for your company or what do you intend to implement when or if you start your company.