Prototype or MVP

Every startup will eventually get to a point where they have completed a substantial amount of research, interviewed potential users and have obtained an initial investment. It's time to start development of the product¹! Figuring out where to start is usually the first challenge.

The Prototype

The terms prototype and MVP are often used interchangeably, but they have very different goals and purposes. A prototype represents a small part of the product that has a lot of variables and unknowns. It's a piece of the service that needs preliminary testing before it can be built. A prototype can be used to evaluate a framework or system architecture. But it does not need to be technical or coded – it can take many forms – such as an interactive Figma prototype of a user flow. The point is to get rapid feedback in order to pinpoint the best solution possible. It's best to define a list questions that need to be answered using the prototype before development starts. The execution should be as fast and dirty as possible without compromising the underlying functions or falsifying evidence. Code quality and automated testing do not provide much value here as implementation can change on a whim. A prototype is not part of a final product - it is best to absorb the learnings and rebuild from scratch.

The MVP

An MVP on the other hand is an early version of a product. It's likely not the first version – but it is the first version that is shipped to users. The minimum features required to make a service function are bundled into a MVP. Starting with an initial list of features and discarding any that are not absolutely essential to make a product valuable is the best approach. It is paramount to start testing the product as soon as possible, so it is better to build fewer features into an MVP. Starting a feedback loop early will generate learnings almost immediately, which are even more valuable in the fist iterations of a service. It is good to remember that an MVP does not have to be launched publicly (although it is better) but can instead be distributed to a group of beta testers. The more diverse this group is, the more reliable the resulting learnings will be, contributing to the quality of a product.

Build, Measure, Learn

The best services depend on a steady cycle of learning and adapting to customers. The initial vision of a product might not be where it ends up generating the most value. It's key to start developing a product with this in mind and establishing a feedback loop with customers and users early on.

¹ I'll use product and service interchangeably, even though they aren't 🤫