In the world of web and mobile app development, everyone seems to have a different definition of a minimum viable product (MVP). At Near The Box, in order to have apples-to-apples conversations with founders, it’s imperative we have a firm definition of an MVP.
Let’s first deconstruct the term before we go into our definition. Minimum alludes to how the MVP should only include the core features that are essential to the customer value proposition of your business. This word also speaks to the fact that a common constraint to founders early on is capital. When capital is precious and companies often have no revenue to help cover initial costs, a founder and technical partner must be laser-focused on building only the features that are inextricably linked to enticing customers to want to spend money on your product. Do you provide a solution to their problem? What benefit do they gain by obtaining and using your product? We challenge founders in our Requirements Gathering phase to ask themselves—what is the essence of my business? If you need 100 features to launch your MVP, you’ve probably lost sight of your core business model.
Next, an MVP must be viable in that it should deliver the value promised to the customer. To us, that’s twofold. First, after the initial Requirements Gathering phase, we build and iterate in the Rapid Prototyping phase where we get a product prototype in the hands of the founder and a potential customer to get feedback on what needs to change and how the product might need to pivot. The view of core features might change at this point, but this step distills what the product requires to be viable or truly valuable. We aim to eliminate bugs with our MVPs. That means exhaustively testing and fixing glitches prior to launching an MVP in the market. The value you’re delivering the customer can be undermined if they’re experiencing issues while using the product.
Finally, the MVP has to be an actual product. You often hear of a concierge MVP, or the founder manually providing the value that the product/platform would offer. This is a way to get initial validation, but, in our view, it’s not an MVP.
Ultimately, the MVP should be a version of the product that incorporates a core feature set and provides significant enough value to attract paying customers (traction). We’re often asked—can a non-custom, no-code/low-code DIY Adalo or Bubble version of a digital product be an MVP? Absolutely, as long as you’re able to carry out the core feature set to gain paying customers. Think of your MVP as your ‘ugly baby.’ Obviously, it needs to be presentable and have a base level of design in terms of user experience, but the MVP phase is not the time to spend money on beautiful design.
Finalizing your MVP should happen after it’s validated with prospective paying customers. This final validation comes in what we call the Rapid Prototyping phase. This is the Design Thinking phase where you’re constantly building, measuring, and learning. You’re in stealth mode and getting feedback from select customers. This phase helps founders and technical partners have an informed, data-driven approach when establishing the final core feature set. From there, it’s polishing and finalizing your MVP so it’s ready to be introduced to the world!