Edge computing is still a new concept, and I think many users are considering adopting it through PoC. By the way, have you ever heard the word PoC? If you search on the Internet, it will come out, but it may be a word that is not familiar to the general public. However, in the field of product development and system development, it is expected that opportunities to be used in the future will increase. This section explains the definition of PoC, the difference between PoC and prototypes, the necessity and merit of PoC, and the flow of PoC verification work.
What is PoC?
PoC stands for Proof of Concept and translates as “Proof of Concept” in Japanese. Verification of the effectiveness of a product or system before launching a new product or system project. For example, when developing a new product, Test sales and monitor customers before a full-fledged sale to verify whether they actually sell. Alternatively, in system development, it refers to a minimum implementation and a test operation.
The difference between PoC and the verification work so far
Among the POC’s ideas, the idea of actually making and using it itself includes “trial production” in product development that has been around for a long time and “prototypes” in system development. With this “prototype”, we are checking the progress of the project and the defects in development. The flow of development projects is carried out in the flow of “concept → planning→ development→ testing→ operation and sales”, but “prototyping” and “prototype” were carried out at any time during the development phase or the test phase. 。
PoC, on the other hand, is often next to the envisioning phase: between the envisioning and planning phases. In addition, while prototypes are a confirmation position of development workmanship, depending on the results of PoC, the development policy may change significantly, and in some cases, development may be abandoned. In other words, it is about verifying that the conceptual design is appropriate before a full-fledged development project moves.
Needs and benefits of PoC
In recent years, uncertainty in development has increased as customer needs have diversified and product life cycles have been shortened. In addition, in system development, there are many challenges in new fields such as IoT and artificial intelligence, and it can be said that uncertainty will increase here as well. In an easy-to-understand way, there is a high risk that the aim of development will be lost due to these uncertainties.
In the development process so far, these risks have been predicted at the conceptual stage, and they have been incorporated into development in advance. In this case, it is very important to predict the risk at the conceptual stage. However, the changes mentioned above are increasingly causing unpredictable risks. If this risk materializes after development progresses, all the development processes up to that point can be wasted.
This can be avoided by understanding the risks earlier. Therefore, at the time of the concept, it is possible to create a product or system on a small scale and have customers actually use it. If you incorporate sales and defects, modify the concept, and then do full-fledged development, the risk of everything going wrong along the way will be reduced.
In addition, such PoC will brush up on the concept, so the development policy becomes clearer and the project progresses smoothly. In other words, POC can be used to modify the concept to better meet the needs of users before full-fledged development and to capture user needs in advance through small test sales and test operations.
An example of PoC is the development of artificial intelligence. Here, it is possible to complete only the engine part of the most important artificial intelligence for the time being and to brush up on learning in cooperation with the user. In this way, it can be said that PoC also brushes up on only the important parts while cooperating with users before full-fledged system development.
However, it is important to note that there are disadvantages such as the concept of a product or system leaking to the outside world and in the worst case, a conflict in obtaining that information in order to have users use it at the conceptual stage.
PoC verification flow
PoC has various merits, but even if you go blindly, it will not be effective. Let’s take a look at the effective verification flow.
- Verification of effect/utility
First, we verify that what the target product or system is trying to achieve matches the needs of the user. In other words, determine if you are achieving the desired effect. For example, in a clinical trial of a new drug, a safe new drug candidate is actually administered to the subject to see if it has the intended effect. It is a PoC because it is tested with a much smaller number of subjects before it is sold than if it were sold. - Verification of technical feasibility
Next, we will verify whether the concept is actually feasible, not a theoretical theory. A slightly surprising example would be a short film. The purpose of this is to verify that the required technical challenges can be achieved by making a small piece of work before making a feature film. In PoC, it is often the case that the verification of technical feasibility precedes the verification of effect/utility. In other words, the technology comes first, but as a result, there is a possibility that development will proceed without sufficient verification to see if the target needs are met. You should be aware that PoC is a method for achieving the desired effects and benefits. - Verification of specificity
Then, the specifications and issues to be considered required by the concept are identified, and verification is performed to confirm whether they are concrete. This means that we will collect the results of market research and the voices of users who have actually used it and utilized it in development.
After the above verification, we will modify the concept, prototype products, and systems based on the modified concept, have users use it, and verify it again. By repeating this, it is possible to brush up on a concept that can achieve “effect/utility,” “technical feasibility,” and “concreteness.” Once the brush-up is fully done, we will move on to the next planning phase.
The important thing is to get the user to actually use it. This avoids the risk that the finished product will be far from what the user wants. It is also important not to scale the verification too much. This not only reduces the cost of the work required to establish the concept but also leads to risk hedging that prevents the development concept from leaking to the outside as much as possible.
PoC is a method with great merit
Performing a PoC that listens to the opinions of users at the concept stage will lead to benefits such as brushing up on the concept, reducing development risk, and smooth progress of the project. However, it should be noted that if the scale and number of verifications are increased too much, there is a risk of increasing costs and leaking the concept to the outside.
As a secondary benefit, even if you abandon development as a result of PoC, you can actually collect user opinions as data, so the knowledge gained in the PoC process will not be wasted. It can be used for the next development. In that sense, PoC can be said to be a method with great merits.
