Less boring way to build an MVP

Whenever you want to build a product, you never start out with building the entire product. Often times your first goal is to build a Minimum Viable Product (MVP). This is done so that you can test the Product Market Fit before you even build the entire complex project.

However, building an MVP isn't fun if you're uncertain that it will give any good results at all. In fact, it's very draining. I thrive on certain good results and uncertainty doesn't help it.

The first step to enhance the experience of building an MVP is by building the end goal right away. It sounds weird but it totally works.

Let's suppose that we're trying to build a social media website where people can post memes in their pages, and others add comments and stuff. The traditional way to go about this is like this:

1. Build the login UI (Nothing fun yet)
2. Setup the database
3. Build the login backend
4. Setup the tables for pages
5. Setup the tables for posts
6. Build the UI for the posts and images (Still can't use it because it's tied to the backend and the backend isn't implemented yet)
7. And so on and so forth...

Most people would feel like quiting at step 3. This is because we haven't reached our end goal yet and we're uncertain if it works and we don't even know how the end product would look like. Let's try a slightly better approach. Our main goal here is to let people create pages, post memes and add comments on them. Let's do that first.

1. Build the end goal UI functionality. (Allow people to upload things and view whatever is uploaded (don't save it. You don't have to). Mock any APIs that you may need.
2. Build other less fun UI components like login page, etc.
3. Slowly build the backend component by component for all of this and make them better.

I find this to be a much better way to go about prototyping products. At step 1, you already have what you're looking for which is going to inspire you. You can play around with what's going to be the future MVP which is going to be fully functional. At step 2, it is less boring considering you already have your end goal. All you're doing is just adding more UI components to your end goal. At step 3, it would feel like you're adding upgrades or patches to things that are already present.

Even though this doesn't solve the entire uncertainty problem, it is still much better than the traditional approach to go about prototyping products. Let me know if you have tried this and I will look forward to finding better ways of building an MVP.

Comments

[Aaron Reese]

For me...
1) backend data structures
2) API endpoints (at least the shape of the data)
3) front end functionality
4) UI/UX
5) security
6) performance

Starting you MVP with poor data structures and incomplete APIs is a massive technical debt that will cripple most startups. You are multiple times more likely to change your front end and middleware stacks that your database.