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.

We've built dozens of MVPs, some were brand launches at Google, some startups that raised $3M in funding, and some productivity tools we conceived that got acquired by bigger companies. Here's some of our 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.

It's been a long time since maintaining your own servers was the best way to deploy a service. GCP and AWS are clear winners in the space. But like all good things, don't go overboard. There are many services you should steer clear of. You want to prevent vendor lock in so you can migrate to a competitor if need be. More importantly, there's often higher quality cheaper solutions if you can roll it on your own. This article gives a few examples of the tradeoffs.

MVPs are constantly changing to adapt to the market and needs of users. You have to be very judicious in your testing, so that you don't waste valuable cycles on things that will be thrown out soon after writing, or something that just lengthens development time beyond what the market can bear. You don't want to be crushed by a competitor because you were writing duplicate unit tests for your backend that will be rewritten in a month. That said, I'm going to go through the major types of testing, and when they'll be useful in your product lifecycle.

When hiring your first engineers, it's important to show them you have a plan for their success at your company. The best way to do this is to have a promotion pathway laid out for different levels of engineers at your company. Aligning individual contributor goals to broader organization goals ensures mission alignment and work is focused.

Doing a competitive analysis on your MVP and business idea yields many benefits. It helps identify gaps in the market, shows where the attention and money is focused, and may expose features that are extremely technically complex. It's a good thing to do before starting building your MVP to ensure you're hyperfocused on your unique value proposition.