Build a Minimum Viable Product, and They Will Come…
…and then most of them will leave after spending 3.27 seconds on your landing page.
But don’t worry, this is the way things go in the start-up world…you don’t hit gold the first time. Instead, you “discover” your way there through trial-end-error based on how the visitors to your site respond to it.
To rephrase more fully: Build a minimum viable product, launch it sooner rather than later, find a way to get users who may be interested in the service or product you are offering to come to your site, measure their behavior while on the site, make adjustments to your site based on this behavior, get more users to visit…and repeat.
At this point you’re probably thinking “ok, that makes sense, but how does this work in the long-term and what is a ‘Minimum Viable Product’ anyway?!”. So let’s define our terms:
Minimum: The least you can get away with to accomplish your goal.
Viable: It’s not perfect, it’s far from perfect, but it works enough to demonstrate the core of your idea
Product: It’s not an alpha release. It’s not a beta release. It’s nowhere close to finished! But it is a product and despite the bugs and the issues in the UX, it’s ready for real use.
For short, we’ll just call this “MVP”. Let’s get into the “Whys?”
Why would I launch my product to users when it’s not finished and may have issues?
Because although it’s flawed, it’s a much, *much*, better use of time and resources than building what you think is a great product out to perfection, or even completion. Chances are great that you are going to fail the first time either way. In fact you will fail many times. It’s better to fail on a small scale, with minimum — there’s that word (!) — time and effort. The cost is minimal, and you learn a bit about what worked and what didn’t, and you take that knowledge and keep building and evolving your product with it.
How does this get me to where I want to be…with a solid product or site that offers tons of value and is in demand?
It gets you there in smaller steps, not giant leaps. So you will likely get there slower. But slower than what? Than if you spent 6 months or a year building the perfect product only to find out no one wants it? Because this is what happens 99.9% of the time with such an approach. It’d be great if you could just build to completion and launch a successful business, but this isn’t the reality. So it’s the “slower” way, but it’s also the “possible” way.
Won’t having a site or product that is flawed harm my reputation with users?
Most likely not. But it’s important that your users see weekly improvements and new features. They will understand that the site is evolving, and since you are listening to their feedback closely, they will feel invested and will *want* to help you make a killer product.
How do I actually implement this?
Since you are basically “iterating” the product on a regular basis, “agile development“, which I talked about in a prior post, is a perfect fit for the MVP approach. A typical process would be to identify a set of tasks to be implemented for the coming week, do the work, release, then “test”. The following week, repeat the process, taking into account user reactions to decide what to add, drop, or change.
Many small companies and start-ups find this sort of “small-chunking” approach to website and web application development the best way to efficiently user time and money while building a stellar product.