Written by: Bryan Hernandez
June 17, 2014
In any skill or knowledge transfer, there is a tendency to start teaching the topics that you know or understand the best. This often makes for a smoother teaching and learning experience. The instructor feels at ease and confident in his comfort zone, and the student benefits from being skillfully eased into a new domain with the masterful guidance of someone who clearly knows what he's talking about backwards and forwards.
This is fantastic, but not always the right thing to do.
In entrepreneurship, the thing you most need to be doing is probably not the thing you feel the best at. It's probably not sitting down and optimizing that block of code, or fine-tuning the hue of your logo background. Coming from an engineering background, this can be especially difficult. An engineer is a creature who is especially good at solving a certain set of technical problems. Working on those kinds of problems is especially pleasurable when you're good at solving them. However, in entrepreneurship this can be dangerous because of the tendency of that tech-derived pleasure to draw away your attention and energy from other less familiar but more important kinds of problems.
How many startups failed because they flawlessly solved a problem or built a product that nobody cared about? I can definitely count myself in that bunch, just as can many other entrepreneurs who eventually went on to realize the mistake and ultimately become very successful.
There are some useful models that explain why we might expect this behavior—especially from highly competent technical people—but I don't need to get into that just now. My major point is that most startups made up of technical people will not fail for technical reasons. They will fail because they will not address the critical problems a startup needs to solve—the problems that technical people usually have are least experienced with or generally don't like.
This is why we're going after the first Rand.
Everybody knows that the necessary and sufficient condition for a viable business is a paying customer. So let's make sure we can get that before doing anymore work at all. The value of all work done without some kind of confidence that there are paying customers waiting for you at the finish line is a complete gamble. And startups don't have a lot of resources to gamble. If at all possible, we want to minimize this kind of work. Startups are severly resource limited, and so we cannot spend our time and money frivilously.
There is an added psychological bonus to this milestone as well. Seeing that people will actually give you their money if you solve a problem they care about is a life-changing experience. It suppresses much of the self-doubt many people have when getting started as entrepreneurs, which in the beginning is a very important thing to avoid.
I want to shatter our founders' conception for the steps required to launch a vaible business.
From day one, we push hard on customer development and getting the first customer commitment. Not uncommonly, this can be done before writing a single line of code! Again, the challenge with this approach is preventing the engineers on the team from running wild on what they believe to be the correct solution to the problem at its first sign, and instead use that Grade-A engineering discipline to stay focused on validating the customer and market.
Let's have the excitement of waiting customers be what drives you to a build your app. Let's not have the sunk cost of having already built a product be the driver to find someone who is willing to pay for it.