Here at the Accelerator, last week we had a workshop by Merrick Furst , a professor and the man behind Flashpoint, an accelerator at Georgia Tech. It was a week long workshop with a mix of lectures, one-one sessions and discussions. Essentially at the end of the week, the workshop attendees (myself included) felt like we had been taken through a journey of product building. I still can't put a label to this workshop and define it.
My notion of building a software product was essentially shattered. Here's how I had gone about product building in the past
Step 1 - Get an idea about building something that you relate to. When me and Gaurav started beetroute, both of us related to the traffic pain point and wanted to do something about it. There was no product in Bangalore that gave us real time traffic updates when we needed. So we said to ourselves we'll build one.
Step 2 - Customer validation and start building. We started telling people about what we are building. Almost everyone instantly resonated with the problem and said they'd use it. Ok, so now we thought we had a market for the product and we started going about building a product and a few months later released an early version. Got a pretty decent response.
Step 3 - Continue validation and iterate building. We didn't end up doing this but this is the logical next step. Figure out how people are using the product, iterate and build new features that people ask for. Figure out any loopholes and continue iteration.
So this should be the magic formula for success. Right ? Almost every startupper who's serious about making their startup successful follows this mantra. But then not all startups are successful. The failure rate is alarming. We've all pondered about this and tried to understand why startups fail. Merrick comes at it from a different perspective. What he showed us was quite an eye-opener.
Going back to step 2 - When we start going about customer validation - we start by telling the customer what we are about to do. At this juncture, the customer, gets influenced by what we are saying. So in our case -the statement - 'Hey we are trying to build this traffic application that'll give you real time traffic updates' , immediately puts the customer in a mode of 'oh that day I felt terrible waiting in the traffic jam. If I had a tool like this, I could've avoided that damn traffic jam'. This is response no 1.
We talk to 10 such people and almost all of them will give more or less the same response. Then we get excited about the opportunity and start building stuff, release a beta and here's what typically happens. 8 out of those 10 guys use the product once or twice. These are the guys who use the product perhaps because it has come from a friend and their motive is to make the friend feel good, more than determining the usability or the need for the product. Often, we mistake this for customer proof that the product needs. This effect is not just related to friends, the effect multiplies as it hits more friends, friends of friends etc. We then mistake this for the viral effect. The product has gone viral true, but has it gone viral in the intended use ? This is perhaps the reason , many products do not hit or cross the mass adoption tipping point. At this juncture, we founders wonder as to what happened - where did we go wrong. We then start tweaking product features, trying to fix bugs that we think are stopping users from mass adoption and the like.
If we tell a customer or user in advance as to what we are building, it might cloud the user/customer's actual need for the product. The sad part is, even the customer/user is unaware that their actual problem is not surfacing. They are instead excited by the possibility of them using something new and cool, and not by how the product can solve their problem.
So to summarize, the customer is excited that he gets to try something new and cool, the startup founder is excited to build something new and cool, founder builds this cool new toy, customer uses this cool new toy, only to realize it's not exactly solving his problem, after a few days he either dumps the product or reduces usage. Then the startup founder wonders what the heck happened.
If we tell a customer or user in advance as to what we are building, it might cloud the user/customer's actual need for the product. The sad part is, even the customer/user is unaware that their actual problem is not surfacing. They are instead excited by the possibility of them using something new and cool, and not by how the product can solve their problem.
So to summarize, the customer is excited that he gets to try something new and cool, the startup founder is excited to build something new and cool, founder builds this cool new toy, customer uses this cool new toy, only to realize it's not exactly solving his problem, after a few days he either dumps the product or reduces usage. Then the startup founder wonders what the heck happened.
