A startup is like a rat in a maze searching for a piece of cheese. The cheese in the startup's case is product-market fit, that pivotal point when the startup can scale and monetize the business.
In the maze, the startup has a dazzling amount of choices of where to go. Should we build this new feature? Should we try this new idea we have for a product? Should we backtrack and completely change our idea?
Lean startups use a strategy called "Minimum Viable Products" to help navigate the maze. The idea is that a startup formulates hypotheses about what users want or do not want; each of these hypotheses is a "turn" in the maze. A "Minimum Viable Product" is the smallest test that will let the startup know whether their "turn" was a good one. A startup wants to stop going the wrong direction as early as possible.
The term "Minimum Viable Product" is a misnomer
However, the term "Minimum Viable Product" is a misnomer. The real goal is to test hypotheses as fast as possible, and being minimal is just a side effect of being fast. "Fastest Viable Product" is a more appropriate name.
There's a subtle difference between the terminology. "Minimum Viable Product" is focused on minimizing wasted work -- minimize the amount of code and features required to validate a hypothesis.
"Fastest Viable Product" is focused on speed. When you're focused on speed, as opposed to just minimizing wasted work, you can work on things for the sole purpose of improving your iteration speed in the future. A rat with a jetpack will find the cheese faster than a rat without one.
Investing in speed at BackType by scaling
Let's take my company BackType as an example. We make analytics tools for understanding how people are engaging on social media. We collect about 2 TB of data a month from sources like Twitter, Foursquare, Reddit, and millions of blogs.
The large size and deeply interconnected nature of our dataset used to be a barrier to testing hypotheses quickly. Testing hypotheses was an exercise in figuring out what data to ignore and what parts of the algorithm to fake. The fact that we wanted to do things with our data that were difficult to do with our current infrastructure indicated that we could "build a jetpack" by scaling.
The traditional risk of investing in back-end infrastructure is that it's a large time investment that doesn't directly test hypotheses about customers. If you have to significantly change direction, the investment could turn out to be a huge waste of time.
Scaling made sense for us because we had already validated many critical aspects of our business. The existence of the market was clear based on the number of companies in the space and the fact that customers were coming to us asking for better tools. We had reduced significant risk and knew that scaling would help us test hypotheses that were difficult for us at the time.
Scaling our data infrastructure gave us the ability to ask arbitrary questions of our dataset. Now, we can iterate on features and test hypotheses extremely quickly. We recently unveiled influence profiles of everyone on Twitter, including the influence graph of who influences who. The feature was developed and deployed in just a couple of days.
We scaled so we could test hypotheses faster. The fact that we created a technical architecture that will support the company for a long time is secondary.
Invest in fast iterations, and invest in iterating faster
"Building a jetpack" doesn't just mean scaling. Other "mini-jetpacks" are things like one-button deploys and unit tests. They don't test hypotheses, but they help your startup move faster (and aren't huge investments).
The tradeoff to investing in speed is that it takes away valuable time that could be spent testing hypotheses. You have to weigh the investment with the associated risks.
If you succeed in increasing the speed of your iterations, you'll be able to test more hypotheses faster. This will increase your rate of learning and improve your startup's chances of navigating the maze.
Just don't forget to bring some wine for when you find the cheese.
You should follow me on Twitter here.