Whether you are a business owner with a new idea in mind or just a curious mind searching into business terms, you might want to familiarize yourself with the functionality of Proof of Concept. Though it might seem trivial and some people even use the concept interchangeably with Prototype, the following article aims to simplify the concept by breaking it down.
What Is a Proof of Concept?
Sometimes known as Proof of Principle, Proof of Concept (PoC) is, in simplicity, a plan to see if a product, idea or design can be transformed into reality.
Although this generic definition can vary according to the product, industry and other factors, POC can help check the feasibility of a concept before it is put into production. It does not include factors such as market for a product, best production processes etc.
An important aspect to keep in mind is that POC does not focus on deliverables but on the feasibility of a project.
This means that POC has nothing to do with the production of a product. In fact, POC is a process to see if the ideas, theories and concepts, applied to the product have a place in the practical world.
For example, in the tech world, developers can pick a few of a client’s requirements and apply POC to find solutions to the problems. If this step is missed in development, many problems can arise.
What is the benefit of a PoC?
POC, because of its immense importance, is an integral part of a product’s development. It can help in identifying problems and thus save valuable resources. A product passed through Proof of Concept has a better chance of being successful. This is because thorough testing is done in POC and thus reduces business exposure to risk.
This is even more important in today’s competitive business world. Some of the advantages of POC are:
- Saving businesses time and resources
- Determining the feasibility of the market
- Identifying technical issues and providing solutions
- Improving the product
- Providing an alternative through market research
Proof of Concept vs. Prototype vs. Minimum Viable Product
Proof of Concept like Prototype is an important part of a product’s life cycle. These two concepts are integral to making a successful product. Unfortunately, many people confuse them a lot. These two concepts have very distinct meanings and purposes. Thus, they are going to be explained in detail in the following paragraphs.
Proof of Concept – Can?
The main idea behind Proof of Concept is to check whether an idea or principle is feasible for real life or not.
It helps in checking the viability of a principle applied in a product. However, this exercise is not carried out to see the overall functionality of the product. Proof of Concept usually focuses on checking an aspect of a product rather than the whole.
Prototype – How?
On the contrary, prototype helps to visualize the product in making. It focuses on a more holistic aspect of a product rather than focusing on a single principle.
The purpose of a prototype is to give a product or a function to the people to test it and improve. In essence POC emphasizes more on the feasibility of a product or idea, while prototype helps in testing the user experience.
Proof of Concept – Is it viable?
As mentioned, a POC is designed to check the feasibility of a single or many concepts. It does not take into account the market conditions and other real-world factors.
This is due to the fact that integrating technologies with Proof of Concept is time consuming and might waste crucial business resources. Taking into account factors other than the principle being tested might undermine the efficiency and results of the test.
This step is carried out before going onto the next step of development for the advantages mentioned earlier.
Prototype – Is it usable?
Prototype, on the other hand, is a more “real-world” version of the product.
A prototype considers all factors a product might have to deal with in the real world. This helps in identifying problems stemming from all factors rather than an isolated principle.
A prototype is also a less refined version of the end product. It helps to visualize and check the functioning of the product and eliminate any errors.
What Is a Prototype?
A prototype answers the question “How can we build that?”. The early adopters of the prototype are usually the people involved in its creation.
It is a tool for early-validating a concept with users and stakeholders without actual development effort. The prototype’s main goal is to support decisions regarding product development and decrease the number of mistakes.
It keeps the final user in mind, while developing a version of the product.
While a PoC only investigates the product’s one aspect, a prototype models several aspects of the product.
Usually, the development team uses prototypes to discover errors in the product. By creating a prototype, they can test the product’s design, usability, and often functionality.
For example, you are developing a smart-football that has the ability to show data such as place of contact on ball, speed, air conditions etc. All these numbers would be displayed through a mobile application.
So, a prototype version of this product would feature a football and the corresponding application. Both of these offer the core functionality, but no other features. You can use it to get feedback from potential customers to improve the features of the product.
Usually, more than one prototypes are built.
What Is a Minimum Viable Product?
Both an MVP and a prototype are modeling the system you’re going to build. However, an MVP often feels like a separate product itself, while a prototype is more like a draft.
A minimum viable product is the simplest yet well-polished version of the end product. It’s delivered to the market with minimal and minor bugs. Contrary, prototypes aim to find the errors early on, so most of the time they are far from perfect.
Now let’s get back to the previous example of smart football.
The MVP version of such a product would be a very refined version. This is because it has passed two stages already- POC and prototype. At this stage of the cycle, football has now all the features necessary for the market. It also has a very user-friendly mobile app to view the numbers.
As the MVP version of this product gets popular, you can go on to make further improvements. For example, one can add a tab to purchase smart-footballs or a guide on how to strike a football under particular wind conditions. This way the product keeps on improving without much risk attached.
When to Use a Proof of Concept?
If you want to add new technology to your product
For example, adding an additional sensor to the smart-football. POC, at this stage, allows you to determine the feasibility of the new feature without exposing the business to too much risk.
Trying to improve an existing technology
Situations like these give businesses the opportunity to choose from a variety of different technological options. This is when POC becomes important to see which of the options is better. One can try out the concepts without actually developing the product. This helps in saving scarce business time and resources.
Using a 3rd party solution for your project.
Using a 3rd party solution is always risky, so doing a feasibility check before you choose a solution can help you avoid a lot of headaches.
A classic example would be when you want to integrate a payment system into your application. You need to check technology feasibility before you start to integrate a solution.
Proof of concept template
As explained before, Proof of Concept is helpful in testing ideas. But the effectiveness of this concept depends a lot upon the business environment. If the POC is not tested in a realistic business environment, results can be inaccurate.
This does not mean to replicate the market environment fully, but to create a close version of it. This will increase the accuracy of the results.
- Define business need and why it needs it
- Check technical possibilities
- Compare technical options based on criteria
- Choose a technical option
- Create demo code
- Align the chosen solution with the business workflow
STEP ONE: DEFINE WHAT THE BUSINESS NEED IS AND WHY YOU NEED IT
Your first step should be defining the business needs in-depth and also understanding what it needs.
Let’s see through an example what we mean.
Let’s say you are operating an online marketplace, where people can sell their unwanted clothes to other users. You make money with commission fees that are placed in every transaction.
To handle these transactions, you need to implement a payment system. So, in this case, the business need is to implement a payment system.
Now you should define the need in detail and explain the motive behind those requirements.
You need this because you can have specific tasks to handle during payment, like split payments and calculating commission fees, not any payment system would work.
Here are some questions that can help you create a more detailed business need:
- What specific business process are we testing?
- What is our current process/methodology?
- What works/doesn’t work with our current solution?
- What problems does the feature need to solve?
- What happens if we don’t develop a new feature solution?
- What value do we want to realize?
- What metrics will we use to measure performance?
- Who will use and support the feature if it is implemented?
- Is this the kind of solution users are looking for?
STEP TWO: CHECK TECHNICAL POSSIBILITIES
After you have the detailed requirements for the feature, you need to collect the possible technical solutions for implementing the solution.
Back to the payment system example. In this case you need a system that pays the seller and pays the commission fee to you. There’s two ways to handle this:
There is one transaction with a split payment in the end. One going to the seller and one to you as the commission fee.
There are two transactions. The first one is when the buyer pays the seller. The second one is when the seller pays you your commission.
Both fulfill the requirements of the business need, but the mindset and the technological implementation of the two processes are very different.
STEP THREE: COMPARE TECHNICAL OPTIONS BASED ON CRITERIA
After you collected the different technical solutions, you need to compare the possibilities.
How you compare these are up to you. We usually use factors like:
- Complexity: how difficult is to implement the solution
- Implementation cost: how much the implementation or the solution costs
- Technical support: if you are implementing a 3rd party solution
- Maintenance: how is maintenance of the solution
- Scalability: can you scale the solution? Can it handle the growth of the product?
- Risk: how risky is implementing the solution
In this example the most important factors would be:
- Implementation cost: since you don’t want to maximize the commission fee
- Risk: how much risk does the solution contain
- Maintenance: the solution should be easy to maintain in the long run
- Scalability: the solution should be able to handle if the number of transactions increases
STEP FOUR: CHOOSE A TECHNICAL OPTION
After you select your criteria, you can score the technical options by assigning a score to each criterion. You can even do weighted scoring if you feel that some factors are more important than others.
Image of two solutions compared.
Back to our example. In this case, solution #1 is much better than solution #2. With solution #2 you would have more transactional costs, more transactions mean bigger risk, more room for error, etc.
STEP FIVE: CREATE DEMO CODE
After the most suitable solution is chosen, you need to check if it works in real life.
So, as a next step, the development team creates a demo environment, that represents the functionality of the feature. They run several tests to see, if:
- The solution works as it should
- There are any errors or malfunction that needs to be fixed
- The solution is scalable
This process helps developers overthinking the technical requirements and find any technological issue early on.
STEP SIX: ALIGN THE CHOSEN SOLUTION WITH THE BUSINESS WORKFLOW
Usually, these updates affect the business workflow too. So, after you have a well-working technical solution, you need to check back with the business stakeholders, to see how the new process affects the business process.
In the payment example, after you checked the technical viability of the 2nd solution, you need to make adjustments in some business processes for example in accounting.
TIPS for a successful PoC
The outcome of any POC cannot be determined.
You can make sure to improve the overall process, but the element of uncertainty will still exist. Here are a few more tips for a successful POC.
Agent or Representative from the developer
This agent would help to make your task easy. His primary task would include helping you deal with any challenge and keeping you on track throughout the process.
Knowing your success criteria
The whole purpose of defining success in the previous steps was to not deviate from your goal. Different problems will arise throughout the POC, but one should keep the success criteria in mind. This will help in being efficient and saving resources. Here you can find a great guide about how to set success criteria for your project.
This is one of the most important tips of the section. Documentation of everything is critical to a successful POC. This will help in identifying errors and improving them.
Also, you can successfully replicate the POC environment for implementation.
Documentation is critical because no POC works well the first time. By proper documentation, you can identify glitches, correct them and avoid them in the future.
This way you can easily check the feasibility of technology without much hassle.
Proof of Concept because of all its advantages holds an important position in product development. Without POC there would be too many errors and mistakes. Businesses would be exposed to a lot more risk and uncertainty. POC is a tool to make a successful and marketable product. It helps businesses succeed and avoid unnecessary risk.
To avail all the advantages, follow the Proof of concept template. This will help in making the process systematic and efficient.