For us, Proof of Concept is both a method and a delivery format. We innovate and iterate technical Proof of Concepts as a service – usually together with startups or companies with ideas in an early stage. In this guide we will walk you through the concept and how we use it in our way of working.
Proof of Concept (also called PoC) is an early test of the feasibility of a concept. It’s a delivery format that thoroughly explains and shows how a concept would work, and as it sounds, to get proof if the concept could and should be realised. It can be blueprints, models, maps – more or less whatever it takes to best explain and prove the feasibility of a concept.
Let’s say you’re a startup or that you have sold a vision of a product to one of your (potential) clients but don’t have any experience in how to build this product and that there’s no similar product on the market which you could use as a reference. That’s when PoC would fit as a delivery format because it’s the first blueprint of your vision. And with this the customer can get an actual feeling and taste of what the future may hold for them – as well as belief if it would work or not.
You and your team can get valuable feedback by developing one or more Proof of Concepts of your product in an early stage. This from example; potential clients, experts and/or investors. It will create an understanding of how you would need to tweak your vision to adapt it to reality and to make a decision of which way to continue before spending too much money and hours.
We would stretch it and say that Proof of Concept are crucial in the development of new products. Because if you don’t draw, test and get feedback the risk is that you will build the wrong product.
Putting in multiple development hours into a concept that will not work can be a costly experience. It’s about having an holistic approach to it as early as possible – and to test it’s feasibility.
In development projects (e.g. software) it’s possible to temporarily ignore, usually important, metrics such as; compatibility with some web browsers or systems as well as safety, design and user experience (provided that it is not central to the product and the test). You can also try to narrow down the focus area of the PoC to a certain feedback segment.
If the biggest challenge for your customer is that they don’t know if their users would like or need the product you intend to create – then you do a so-called; User case Proof of Concept. The customer chooses a small user segment as their focus group for which you show and explain the idea of the concept in order to gather valuable feedback and proof of it would work.
During the development of new technical products there may be some uncertainties around how systems and API:s would connect and work together. So, to test this in a PoC you can describe and isolate a part of the (visioned) technical solution and test it in an isolated integration. In this way you and the receiving part can see if the concept would work technically and what challenges and system configurations that need to be taken into consideration.
A PoC is more of a theoretical demonstration of how a concept would work while a prototype is a physical demonstration that shows how it works and looks like. If, for example, the idea is a mobile game app, then the PoC would be an explanation of how the game is supposed to work, what rules and characters there will be as well as an idea of how it will be visualised. The prototype, on its end, would instead be a demo version of the game that was explained in the PoC state that could actually be tested/played by your customer.
Proof of Concept is a blueprint of how a product would work and look like. An MVP (Minmum viable product) is an actual product that reached and fulfilled the preset criteria of what is good enough. To use the metaphor of a mobile game app, an MVP is when the game is good enough to actually be released at App store and Google Play.
We worked together with a startup operating in smart logistics and transport. They wanted to develop a digital platform that would display and educate their customers of what unnecessary and hidden costs they have with their current logistic setup. And with that emphasise their own value as a supplier.
The idea was to gather real-time data from connected trucks and visualise all data in an interactive dashboard. Something that of course was difficult to execute without investing a lot of money – especially because we didn’t have any trucks to use. We needed to use and deliver a Proof of Concept to test the feasibility of the concept.
Instead of trucks we chose to use simulations of predetermined delivery routes and an Autopi connected to one of our company cars to see if we could gather the data which was considered important for the existence of the concept.
👉 How we developed a Proof of Concept in smart logistics