A common use case to build an essentialist MVP is to get more support for your idea. Taking the functional demo and pitching it to an investor, so you get more funds to flesh it out further, and recruit more team members to mentor, give resources, ideas, and connections to the project. Here I'm going to discuss some considerations around building an MVP for this purpose.

When facebook pulled together a simple app for dating, it was immediately valuable. This is the power of network effects. Not the most popular dating app in the world, but a viable, useful, and profitable tool. When you launch your dating app, while more innovative, it suffers from the cold start problem. You have zero users, so who am I going to match with? There are two main solutions to the cold start problem, and your MVP must keep these in mind while building to be successful.

There are a number of ways to build your MVP, and each might have a different pricing structure. But here I try to lay out some rules of thumb on how to get budget ballparks for certain features.

The year is 1996. My third grade teacher has five brand new Dell computers and is teaching the advanced math students Logo, an education programming language...

There are a number of ways to talk about essentialist MVPs. Minimum Viable Tests and Minimal Minimum Viable Products are popular. Here I want to explore this concept a bit further and compare a standard approach to focused one.

When constructing the backend architecture for a system, keep the concerns separated. This is a general principle followed in containerized designs, but holds true down to smaller components. Even if the component isn't far away and different, keep responsibilities relegated to separate files or directories.

Finding the right fit for your engineering staff is important, and there's a few things to keep an eye out for on resumes to share here. Screening out bad fits is much more important than being sure to hire the perfect person. So screening out good candidates should be seen as a necessary mistake to ensure the wrong employees don't get hired.

Much of my focus is reducing the scope of MVPs and getting really essential. One method I want to explore here is what I'm calling reverse scoping. Instead of starting with all the hopes and wishes for a product, start with the time and money you have right here right now. What can you build with that, however small, to increase your commitment, increase the investment others have made, and build out something bigger.

I've built dozens of MVPs, some were brand launches at Google, some startups that raised $3M in funding, and some productivity tools I conceived that got acquired by bigger companies. Here's some of my hard won knowledge about building a product from the software perspective.

You're a white collar professional with over a decade of experience. You've found some major inefficiencies in your work, and repetitious tasks that you have to do, and not only you, but everyone in your role at other companies. If you're driven, creative and have an insight that's repeatable, you can leverage and sell it with software. This lets you stop trading time for money, and gives greater opportunity for growth. Hard work, no doubt, but worth a risk to escape the 9-5.