Modern software development often involves a minimum viable product (MVP), proof-of-concept (POC), or other partial or incremental solutions. These approaches embrace the reality of software being difficult and time-consuming to produce but highly valuable for the users. The tactic is a form of the Pareto principle where the focus is on getting a large amount of functionality delivered quickly. Thus, we must be intentional about building these out so they can benefit us (and our customers) now and in the future. Now, let’s start with a look at some common ways to get a portion of the problem solved and deployed quickly.

The Minimum Viable Product

The MVP is as close as we get to the objective of releasing a product in the shortest amount of time. The key to this approach is the word “viable” and how it applies to our product. However, It must be clear that the result of an MVP is a product that can be put in front of customers or users. That includes deployment, training, and documentation as needed. Therefore, we can also consider this a phased or versioned approach to releasing the product.

You can also think of this as finding the solution with “just enough” functionality to be useful to the customers. Thus, this is the point where the solution is worth the money charged to customers. However, there is often a promise of some sort of follow-up features or releases that will be provided to customers. They are buying the product with an understanding that more features and functions will be coming in the “near” future.

The Proof-Of-Concept

A proof-of-concept is an excellent way to see what the solution to specific challenges in a project will look like. These are often functional only and not the “pretty” solution customers will see. A POC is a research project where technology and knowledge are tested to produce a solution to a new or unique problem. However, this approach also can be used to create baseline metrics for a solution. The resulting POC is far from an MPV. At this point, we are only proving that the technology exists or our design is sufficient to solve a specific problem.

For example, a common POC category is where an integration is required. Even though the desired integration might be fully documented and a public interface, there can be critical issues that arise. A POC is the best tool for tightly defining a result so that it focuses on solving our research goal or unique problem. Thus, when we talk about “why,” the POC is a very tightly defined and specific focus that adds no bells or whistles.

Agile and Incremental Solutions

When one is unsure of what they really need or require rapid partial turn-around, agile and similar incremental solutions are the best. These embrace the “satisfy the customer” focus of the Agile manifesto and keep everyone in a high-efficiency mode. The key to this approach is that the team always has an objective that is reasonable. Thus, it is short-term ( a few weeks), and they are held accountable. The design and management of the project are much more active, though.

The goal in this approach is to continually (every sprint of a few weeks) set up goals that are realistic. Likewise, they must advance the features for the users. The result is a highly flexible approach to solving the problem. The rapid turnaround earns the trust of users by regularly responding quickly. However, it can be overwhelming to the user base. They will work on a product that is regularly adding and improving features, which can be frustrating. On the other hand, this can be an approach that incrementally offers features to users. Thus, the solution is easily trained and learned through this piecemeal approach.

The Best Approach

Each of these approaches answers the challenge of getting to a solution quickly. That objective is valuable whether it is customer-facing or not. All of these embrace the Pareto principle that is far too often ignored in software development. Actually, it is ignored too often in many product development efforts. Worse, it is often ignored in problem-solving for businesses. We do not need the highest-end solution for all of our problems. Far too often, the budget solution is perfect for our needs. We can add bells, whistles, and deeper functionality inn the future. Thus, our best approach is a solution that works most of the time sooner rather than a complete solution weeks or months from now.

Each of these approaches has a different goal. You can use MVP when you know you need to solve the problem sooner rather than later. A POC will answer whether your most significant problems or concerns can be met. Finally, the Agile approach will keep you churning out results regularly while building out a full-featured solution.

Next Steps

Feel free to schedule a time to discuss your next project with us. We have experience in each of the approaches above and can help you make the most of them. Every project we work on includes demos and similar discussions regularly. Often every two weeks, including a release our customers can use to test the features further and get comfortable with the solution. We are happy to help you with investing in requirements and improving the overall success rate of software projects. 

Our experience has taught us a lot about the pitfalls and challenges of custom software. Likewise, we have an e-book that can help you explore all the steps in building software, including a few templates. However, we ask that you share an e-mail address so we can send you a copy. We will add you to our monthly newsletter, but you can unsubscribe anytime. Your data is not shared with anyone else. Learn more about our book here.