You’ve been working on a cool idea for the past few months. You have made significant progress in building your first prototype.
However, you are still not sure of whether people will buy your product.
The hard truth is, you can spend years building, but when you launch, your product still may not find any users. Many startups have slaved away for months, if not years, on their idea, only to gain very little traction.
We (a community-powered WiFi startup griggi.com) faced with the same doubts. So we ran an experiment, in which we followed ‘lean startup methods’. I will talk about why and how in a little while.
The problem lies in developing a product before validating your idea. It results in a waste of money, time and energy.
If you talk to tech startup founders, most of them want to first build the product, launch it and then ‘see’. This approach is wrong, because nowhere in the process is the idea tested.
We almost made the same mistake.
When we zoned into an idea which might have resulted in something useful, I was all ready to dive in and build an MVP. An MVP is a “Minimum Viable Product”; the first version of the product, comprising only the topmost priority features.
My cofounder, a close friend from college, was not too enthused by this approach. He had spent the last 5 years working on different ideas without validating them, without much success. So this time, he wanted to first validate it.
Our debate boiled down to what to start with:
Needless to say, we agreed on the second approach, i.e. validation first, product later.
I will get to the logic behind the “validation-focused’ landing page in a little while.
The reason behind founders not validating their ideas before building the product is that startups are assumed to be inherently completely chaotic. (However, as we shall see, this is only partly true. There is a method to the madness.)
In the current startup ecosystem one or more of the following, at best, is being done. None of them work as they are expected to.
Launching an MVP quickly is suggested as a good way for startups to go. This is the famous “build fast and kill fast” approach. Unfortunately, it is not so straightforward.
Firstly, building an MVP is a lot harder than founders want to acknowledge. It will take up more time and energy than planned, even if you have all the experts you need.
Secondly, many founders don’t want to release an unfinished product. It does not align with their vision for the product.
Survey data for a hypothetical product is worthless. People are generally nice, and are likely to say "Sure, I'd buy it" to a product which even mildly interests them. It isn’t like they have to pay for it at the time they agree to buying it.
When people talk about validation through a “coming soon” page, this is what they mean:
Step 1: Grab a million email sign-ups with a “coming soon” landing page.
Step 2: Build the product.
Step 3: Profit!
This page will be optimized for maximum sign-ups, in which it may succeed. But it will not validate your idea. By getting email IDs upfront, you haven’t allowed visitors to ponder much over your product. Most email IDs on this list will very likely not convert to users.
The solution lies in validating an idea before implementing it.
Idea validation is an iterative process, and it should be a core part of any startup process. It should be done before one invests a lot in building the product. Validation should be based on hard statistics. One should not embark on development until one has these statistics.
Our intent was clear when we created the landing page: it was to gauge visitors’ genuine interest in our hypothetical product, not to rack up a huge sign-up count.
In the snapshot of the landing page we displayed earlier, notice how we have not put in an ‘email ID’ box. Instead we’ve added a “get started” button, to check how many people are curious about the product. On clicking “get started” the visitor is presented with the choice of selecting one of the two ways we are offering the solution in. This makes the user think for a moment, so only a genuinely interested visitor decides to go on to the next step.
We put an easy bailout as our third option, in order to filter out weak interest.
Notice that the pricing shown is not of a “coming soon” product; it is a “buy now”.
Our last page shows “work in progress”. It is here that we ask for an email ID. Many of the users may not enter their email IDs once they know the product is not ready; but that’s okay, as we are not looking to build an email ID base yet. We are more interested in visitors’ navigation patterns.
In the back-end, we integrated a mix-panel for analytics. We can see stats coming in as we speak. The percentage of visitors that click either “buy router” or “install software” has exceeded the threshold mark we had set beforehand.
We are also getting quite a few insightful comments through the Disqus forum integrated into the main page.
Our final data will help us decide our next course of action.
A few visitors have raised a point which we also think is valid. On a site accessible globally, the user base will be really fragmented, which is not very useful in an idea like this. Initially, this idea will work only if all the users are in close clusters, at best within a city.
We have started discussing pivoting a little, and targeting a city first. For seeding of the community, we are planning to provide a few free WiFi routers within a targeted area. This of course will require some funding. We have thus started looking out.
We are now looking to make Griggi reach cafes & coworking spaces for free/metered wifi to their users. More details here.
About the author:
I have worked for 10 years in the networking/communication field as a chip design engineer. Of late, I have started exploring startup world, as I yearn for a different kind of experience. You can follow me on twitter.