There is a tendency for many first time founders to overbuild an MVP. The reasons vary, but most often it stems from improper/lack of customer discovery and results in an improperly scoped build. The role of an MVP is not to capture the entire workflow of a potential user, rather it is to build a solution for a very specific white hot pain point that allows you to build trust with your customer and over time deploy more product and capture more wallet share. When a startup truly understands their target customer, and has isolated top priority problem areas, they are often able to zero in on a fairly narrow scope for an MVP. Oftentimes this solution can be fairly crude with a V1 UI/UX and not built to scale, but because it is meeting such a pressing need it generates robust usage from an initial cohort of users. On the other hand, when a startup fails to perform robust customer discovery, they almost always fall victim to the "feature fallacy" and overbuild initial products thinking that quantity of features will lead to adoption. It's the classic problem solving technique of throwing spaghetti at the wall until something sticks, but in early stage startups with very limited resources, this is often a path to failure. Founding teams need to balance the feature set of an MVP with their ability to ship product within the existing runway of the business - which in many cases is the sweat equity of the founding teams living off of savings or friends and family money they've raised. As such, the composition of an initial founding team is crucial, and having engineering talent on the founder team is most often necessary to bridge the gap. Founding teams lacking engineering talent and reliant on outside development contractors to stand up initial products put a startup in a suboptimal position to succeed. Investors are increasingly unwilling to fund first time founders to build out an initial product. As such, teams need to focus on a way to get a product in market and prove some degree of traction within their customer base before realistically targeting institutional capital. Raising money before deploying an initial product is possible, most notably by second time founders or early executives at high growth startups, but in many cases this subset already realizes the importance of customer discovery and getting an initial version of product in market, and optimizes for that before looking to capitalize the business. There are certain types of market opportunities where a narrow feature set is an unrealistic option for initial deployment - examples being an embedded payroll offering or a core infrastructure layer. In these cases, a founding team will need to raise capital to build an MVP. Second-time founders or founders with deep domain experience/networks who can demonstrate robust customer discovery proof points have a reasonable chance of raising capital, but most founders will struggle to launch these types of businesses.
I can't thank you enough for sharing this today. Your thoughts on MVP for the first time founders are greatly appreciated James Murphy
What you said applies to the majority of cases. However, there are cases when it’s not possible to narrow down the problem because there are basic features that everyone is accustomed to, so if you build something awesome but without a basic foundation it won’t work. A very prominent example is recruitment: scheduling, email functionality or people management are basics. Over time, nice to have become basics, like candidate and client CRM. If I am wrong with the approach, I am more than happy to discuss and correct my product approach in this area
Spot on. Overbuilding an MVP can be a costly mistake. Focusing on solving one core problem is key to gaining early traction.
Thanks James Murphy, we’re just about to start spec’ing the MVP. You post is very timely! Mackenzie M. Howe
Very good post. I often encourage founders to try and find an engineering counterpart before tendering independent contractors for the reasons you discussed.
Straight 🔥🔥🔥
James Murphy facts! And I’d add, Bootstrapping or if possible, running a service business to get a better understanding of the landscape, customers, value over risk over problem over solution is a smart way to start.
Love this - from the way you thought about (and experienced it) to the way you communicated it.
Co-founder and CTO @ Fluence | BS/MS in CS @ Duke
5moYes, whether your mvp needs a narrow set of features or a more comprehensive set of features, more often than not, you will benefit from launching ASAP. You only really get to know your users when you start charging them. I guess that’s my beef with lots of entrepreneur programs at many higher institutions. They make it feel like you need a whole semester to find the right idea, another semester to brainstorm the product, another semester to build a team, another semester to actually build, another semester to [you name it]. I saw quite a few people at Duke who hadn’t even launched after 2 years