Startups are highly complex projects that are famously easy to get wrong. Countless moving pieces need to align neatly at the right moment for them to work. For any given concept, there are a thousand ways it can fail, and just one or two that it may truly succeed.
There is no map for founders to follow because every business, product, market, and team is different. But that doesn't stop people trying to map the ever-changing landscape anyway.
The problem is, generally the original intent is not to create a map, but to create a framework for navigation. Yet unfortunately people take it for a map and follow it blindly anyway — often to their demise and frustration, and then report to the world that it does not work. Many of these frameworks were wonderful in their original context, but years of interpretation and misinterpretation have taken them away from their original value.
For a long time I have been thinking about startup first principles. The core building blocks that we can model our thinking around, to solve everyday problems you must overcome. Rather than spend time following a rigid practice or framework that may or may not help you, simply because that's what everything says you are supposed to do.
Should you interview users? Should you build an MVP? Naturally we are inclined to shout "yes!" without further thought. But to what end? How many users? What are we testing with our MVP? When should we double down, or invest heavily into deeply building a product beyond a minimum viable version?
Rather than debate when or how to use a specific framework, I pose that we should practice thinking more fundamentally instead. Using the principles below, you can build any other concept.
Building an MVP is fundamentally a validation exercise. Expending the smallest amount of resource (time) possible, to find out if your hypothesis about your market and product is true. Do people like it? Will they use it? Does it solve their problem?
I suggest that it is a formula like this:
Spending time (your resource) on a short-term objective (MVP) which is designed to gather facts and lower risk, working toward a bigger objective (launching your proper product).
After stripping away everything we've read from books and blogs about MVPs down to this formula, we can think like real innovators. Let's ask the question again: Should we build an MVP?
Given that the objective is to gather facts to lower risk, first we need to know the risk. What is our current level of understanding? What existing evidence do we have? What experiments have we previously run? What assumption might kill us, if we are wrong?
Then, finally: is an MVP the best way to answer these questions? Could there be other ways to do it faster, better, cheaper? Maybe you could more effectively lower your risk by doing something else instead.
If you have answered yes to building an MVP, it can continue offering us more value too. What do we test, and therefore what do we spend time building (and not building), to most effectively lower risk?
The best founders know when to use a framework and when to completely break the rules, because they intuitively think this way.