What’s an MVP? A simple guide to software development for non-tech founders.

You want to make money using software.

The good news is, you don’t have to be an IT professional to have success in that endeavor. You just need vision to see a path of product viability. In other words, you need to understand how would-be users of your software would navigate through the application and why that would lead to a net revenue gain for a business. Now for the bad news. It costs money, and it takes time to actually get that done. So in order to be a good steward of your money (or an investor’s money), you have to understand the absolute bare minimum pathway to viability, hence the term Minimum Viable Product or MVP.

Product Viable Minimum

Let’s inspect each element of an MVP, but in reverse order. First, we’ll talk about what a product is in the context of software development. Next, we’ll address viability. Last, and by definition least, we’ll speak about how to achieve the minimum (viable product) and why it’s so critical.

Product

So, what is a software product?

In this context, think of it as a solution that:

• Originates from software development: It’s code purposefully crafted to execute specific functions or workflows.
• Drives tangible outcomes: This isn’t just software for software’s sake. It actively causes observable changes or enables new capabilities in the real world.
• Influences user actions: The ultimate test of a software product is its ability to meaningfully alter how people behave – how they work, communicate, decide, or interact.
• Generates value exchange: This behavioral shift creates a scenario where value (often, but not exclusively, monetary) is exchanged. Users invest (time, money, data) because the product delivers a desired benefit stemming from those new actions.

Viable

What makes a product viable?

At its heart, viability is the litmus test for whether a product (or even just a process) is worth the investment – worth building, worth maintaining, worth optimizing. It boils down to a fundamental question: Does this product create a net positive impact for the business? Put simply, does the product deliver more value than it consumes? If yes, then it is viable.

A viable product or service must achieve one or more of the following business outcomes. Crucially, these outcomes should outweigh implementation costs within a timeframe the business can tolerate:

• Increased Revenue: The product directly generates new income streams or increases existing ones.
• Protected Revenue: The product helps retain existing customers or market share, preventing revenue loss.
• Reduced Cost: The product streamlines operations, automates tasks, or improves efficiency, leading to lower operational expenses.
• Avoided Costs: The product prevents future potential expenses, such as those related to compliance failures, security breaches, or scaling inefficiencies that would otherwise arise.

To have your best shot at creating something viable, you can’t just think in terms of business outcomes, though. You have to understand the consumer or end user that the product serves. So, you need to know…

• Who is actually using the product?
• Why are they using it?
• What specific problem does it solve or benefit does it provide?
• How does their pattern of usage impact the resources needed to run and maintain the product?

You may notice that a product at this stage can have as many value-generating features as your imagination allows. In the next section, we’ll ask ourselves what is the shortest path to success and answer why we need to think in those terms.

Minimum

First, why is the minimum viable product the starting point? Why can’t we just plot out the grand vision from the get-go?

There are many different answers to those questions, but I think the truest answer lies in the unpredictable nature of human behavior. No matter how well you know your target end user, the solution you craft and build will not be used in the exact way you predict. It won’t have the exact utilization that you predict. The end users will find value in ways you don’t anticipate. They will reject value in ways that frustrate and confound you. This doesn’t mean that creating a plan for your product is useless. It means that you need feedback from the people that will actually use it as soon as possible, so that you can adjust the course of construction early and often. So, to begin, ask yourself (and your team), “What is the smallest subset of my product vision that can generate a clear use case with a positive outcome for my end user and my business?”

There are as many ways to find an MVP as there are products in the world, but a good rule of thumb is to identify that one core problem that you want your product to address. What is the most direct solution to that problem or pain point? At this stage, it is helpful to have multiple viewpoints for the main purpose of filtering out rather than including more. In other words, this is where the words “ruthless prioritization” come into play.

Take a proposed solution or goal and the end user. Slap them on a sticky note and put them on a board. Plot out each step that the user would need to complete to achieve the goal or find the proposed product value. Once all the steps are up on the board, critically review each one. If this wasn’t here (or if it was smaller), could the user still technically reach the end value? If yes, rip it out. “Ruthless prioritization” is gut wrenching at times, but it’s what is needed. There are so many things you have to set aside in deference to the minimum of MVP. The sad reality is that sometimes those things never make it to the product. But, in the best case scenario, this is because you find out that the cut feature wasn’t needed or desired by the end user. Therefore, the work, time, and money was saved; that is always a thing to be celebrated!

Up to this point, you’ve already exercised your empathy with the users to figure out what an acceptable MVP is, but it doesn’t end there. That’s literally just the beginning. That empathy has to be active throughout the development process. Using qualitative and quantitative data should guide the planning process all the time. User feedback isn’t the only source of strategy, but it is perhaps the most important. So, continue to ask, “How has our implemented solution helped my users and why are they using it in this way or that way?”

At some point, the MVP must be considered done, but the art of finding an MVP maps nicely to the quote attributed to Leonardo da Vinci, “Art is never finished, only abandoned.” In other words, you can always add more. The trick is to detect the line of diminishing returns. Justify its doneness periodically and see if you believe yourself. Use the same set of questions we justified the product’s viability with to see if adding more code will add more value.

TLDR / Recap

You don’t have to be a tech guru to lead a team to a profitable software product. The key is understanding the Minimum Viable Product (MVP) to wisely invest your (or investors’) money.

Let’s break it down:

• Product (Software): It’s not just code. It’s software that creates real-world change by influencing user behavior, ultimately leading to a value exchange (like a purchase).
• Viable: A product is viable if it delivers a net positive impact for the business—meaning the value it generates (by increasing/protecting revenue or reducing/avoiding costs) outweighs its own costs within a reasonable timeframe. Understanding who uses it, why, and how their usage impacts costs is crucial.
• Minimum: This is about finding the smallest version of your product that still achieves that viability and solves a core user problem. Why “minimum”? Because user behavior is unpredictable! You need to get your product into real users’ hands ASAP to learn and adapt, avoiding wasted effort on features they don’t want or need. This requires “ruthless prioritization” – if a feature isn’t essential for the core value, cut it (for now).
  The Big Takeaway: An MVP is your first step to learning. It’s about building just enough to be valuable, getting feedback, and then iterating. It’s less about a “finished” product and more about starting the journey of continuous improvement based on real user interaction.