Startups are essentially machines that build MVPs (minimum viable products) that help answer questions and gradually de-risk the value proposition of the company.
The key is that every MVP a company builds needs to be laser focused on answering a very particular question. If it does anything more than that, it’s time and effort wasted. In my experience, a lot of startups worry about scaling way too early, wasting resources on something that may never be needed.
This tendency is particularly apparent in startups founded by individuals who come from engineering disciplines at big, already-scaled companies. But the things you need to do to ship code at Facebook, Netflix, Amazon or Google don’t apply in the same way to early-stage startups.
Early-stage startups may have a few hundred or a few thousand customers, and each list has its own unique set of challenges.
Don’t get me wrong; it’s always best to ensure that code is relatively secure and that it is written in such a way that it doesn’t degrade the customer experience. But technical founders often err in the wrong direction, spending a lot of time on hardening the code (i.e., making it secure) in addition to writing and deploying it in such a way that it is scalable.
But that doesn’t quite work when you’re in concept-proving mode.
Inexperienced founders often get defensive about this sort of thing, worrying too much about whether the product or feature they just built will offer a perfect user experience or caring about whether it can handle a million concurrent users. Yes, those things are important, but they might not be right in this exact moment.
The mindset in early-stage startups should be that you are building MVPs to answer questions. Bear in mind that MVP continues to be a terrible term; it’s neither a product nor viable. Nor is it all that “minimum” in many cases. An MVP is the smallest amount of work you can do to confirm or reject a hypothesis for your startup.
If the hypothesis is, “Can a million customers use this app at the same time?” by all means, that’s the right time to optimize it to within an inch of its life. But, when you are building a company in the early days, that’s rarely the question, and unless you fall into particular categories of apps that do need to be resilient to remarkable amounts of traffic, investors are unlikely to care.
For one of the startups I worked with, the company had a product where tens of thousands of people were put in a waiting room, and when a countdown clock ended, they would all be let into the product. That turned out to be an interesting challenge: What happens when 10,000 people hit the exact same part of a web app within a second of each other?
As you might imagine, even small inefficiencies in the platform caused huge bottlenecks and potential service degradation. In the short term, we “solved” the problem by spinning up a bunch of extra servers, then letting people in over the span of a few minutes; having 500 people hit the slightly inefficient code at a time was much less of an issue than having 10,000 people come in all at once.
Was it elegant? Nope. Did it work? Yes, and it made sense because, at that point, the company wasn’t explicitly worried about whether the service could take on 100,000 customers at the same time. Spoiler alert: It couldn’t, and by the time it needed to, that part of the code had been refactored in a way that ensured it could.
At the earliest stages, the questions tend to be as follows: “Is what we are trying to do even possible?” or “Will people pay for this?” or “Can we convince a corporate partner to integrate this?” or “Can we acquire customers at a reasonable cost?” or “Can we manufacture this at a price that makes sense?” or “How do the unit economics of this product work out as we scale?”
For a pre-seed company, you don’t need perfect design and scaleability; you need to build enough product and traction to get user feedback. From there, you can iterate and create value for the customers. Once you start generating enough value that customers are willing to pay, you might start to consider investing more heavily in scaleability.
Over-engineering your product too early isn’t big or clever. It’s a contra-indicator: It tells investors that you don’t know what’s important at the current stage of your startup.
When deciding to focus your attention, run the litmus test: Is your current activity contributing to getting you collateral that helps with your next round of fundraising? If it doesn’t, you’re probably working on something that seems super important but is not stage appropriate.
That’s a problem: You could always be spending more time on creating something sleeker, faster, prettier or more scaleable, but the mantra in your startup should be “good enough is good enough.” You’ll be amazed how much faster you can go once the company internalizes that.
Comment