Blog


Back to Blog

Back to Basics

At a certain point in the startup journey, a founder might pause and ask him/herself this question:

“What a minute. Am I doing the right thing?”

It is so easy to jump right into the process of building an MVP without properly validating the need for the solution. In the heat of the moment when a founder thinks that he has struck gold with his brilliant idea, he might fail to ask the most important question of all:

“Am I building something that nobody else wants?”

This video says it all:

Don’t perfectly execute the wrong plan.

Get out of the building and talk to your users, validate your idea, spend time on learning before you start coding. You do not have time to build the wrong product.

After speaking to several developers about my idea, I learned that what I thought was a must-have problem for developers might not be their biggest pain points at all.

Most advanced developers are not very excited about the prospect of being able to get help from another expert. Most of them are happy with using StackOverflow (which is free). This invalidates our initial hypothesis, or riskiest assumption, which is: Coders prefer instant and interactive problem solving over Googling for answers. 

So we have decided to pause our initial plan of building an MVP, and go back to basics: validating our idea. And we will do it through live user interviews, going out there to talk to potential early adopters, learn from them and find out more about their habits and pain points.

Two questions:

  • Perhaps advanced programmers should not be our focus. Perhaps there are other demography/user groups that might be better early adopters? Three groups have come up as potential early adopters so far: female coders, kids and university CS students.
  • What are the pain points that advanced developers have that we are not addressing?

To find answers to these two questions, we will need to talk to a substantial number of people from each of the potential pool: female coders, kids, university CS students and advanced programmers.

Lessons from Running Lean: the goal of live user testing is not to pitch your idea or ask users what they want, it is to listen to their stories and learn something from their habits (e.g, is the problem acute enough that they are currently using an alternative? what are the current alternatives they are using?). Let the users do most of the talking. And systematically document your findings.

That will be our next step. Back to the whiteboard we go!

 

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.