The abbreviations PoC (Proof of Concept) and MVP (Minimum Viable Product) have become firmly established in IT industry terminology over the last 10 years. Although the terms have become more common, we’ve nevertheless noticed that people sometimes use the words to mean completely different things.

In this text, we want to explain what Kodan means when it uses the terms “PoC” and “MVP”. This text was written by service designer Ville Yli-Knuutila and architect Herkko Virolainen.

Proof of Concept

“Proof of Concept” can be broken down into the individual components of “proof” and “concept”, or translated to the equivalent of concept proving. Proving is clear, but what do we mean by concept? In this case, it refers to a claim, assumption, idea, or hypothesis, about whose funtctionality we are uncertain. The concept and proof thereof can also be summarised in a simple “if X, then Y” conditional clause. Depending on its content, the purpose of a proof of concept is to explicitly prove one or more concepts included in a future system or service.

Here’s an example. SalesCompany Ltd makes the following assumption: if sellers have a certain type of data available to them (if X), then they can contact more customers per day (then Y). Here, we may be tempted to think of a data dashboard or other digital user interface, but the easiest way to prove this concept may be to just manually collect data and email it to sellers once per day. If the number of contacts then increases, the concept has been proven worthy of further development.

It’s important to understand that proof of concept is not a functioning system that has been “stripped of some features”. Its only purpose is to test the viability of a particular concept. You don’t necessarily need even a single line of code to prove a concept, either. Once a concept has been tested, the proof of concept is usually discarded. It is often carried out quickly and cheaply, so it’s not sensible to begin to build new features or other long-term functionalities on top of it.

Minimum Viable Product, MVP

It’s worth taking a moment to really examine the meaning of these three words!

Minimum. Small. The product already generates value and solves a problem or problems, but is still subject to numerous restrictions and requires further development. Restrictions can involve limited availability on different platforms, a lack of various functions, or a lack of automation and integration, to name just a few examples. Lots of manual work may still be required behind the scenes. Because of these limitations, the product is still “small.” It does not cover all possible use cases.

Viable, practicable. The system produces clear value for at least one target group. Further development should be continued, and it does not consume too many resources in relation to the benefit it provides.

Product. The system is a clear entity with carefully implemented foundations which allow for scaling and further development. If you’re developing a product for sale, then it can already be sold.

The definitions above can sometimes contradict one another. When building an MVP, the most difficult struggle is to strike a balance between the terms minimum and viable. What do we truly need - and what can we leave out? At what point do the investments required for further development outweigh the benefits provided by the system?

Example (continued). SalesCompany Ltd’s proof of concept shows that the extra data provided to sellers increases the number of daily contacts. Because collecting and sending data manually is not sensible in the long run, SalesCompany Ltd decides to deploy a digital service where sellers can always find up-to-date data. The MVP is deployed as a functional but stripped-down version: user management (e.g., new user credentials, forgotten passwords) is handled manually, there is no support for mobile devices yet, and the user interface is deployed with off-the-shelf components. Initially, the product serves approximately 50% of all sellers. If the service generates added value as expected, its development will continue.

The MVP’s most important task is to test and demonstrate the idea’s functionality in practice; in the hands of real users in the often chaotic real world context. An MVP is used to obtain feedback from users on whether the value produced by the system is valuable enough, and on which direction that product development should take.

Don’t be afraid of embarrassment!

Sometimes an organisation that provides a digital service has an extremely detailed idea in mind of how the system “should” look and how it “should” work. The difference between the vision and reality may at some point in the project result in negative cognitive dissonance. There is a fear that if the product goes out to the user looking like this, it will be a laughing stock. This can cause sensible decision-making to be thrown out the window, and the development team’s time and energy are focused on the wrong places.

The service’s end users however do not have that same vision in mind. They don’t know what’s missing from the service or how it “should” work. They’re simply and solely interested in whether the service makes their lives easier. If it does that, even a clunky product will find loyal users.

Once the product is in a state where it substantially creates value for at least one user group without breaking, it should be published. If you’re embarrassed about the product’s functionality or appearance, then good! That means you haven’t polished it for too long.