.png)
The purpose of a proof-of-concept (POC) for your product and the way you implement it can be hugely varied. However, there are normally two key elements in a POC – design/development of a physical device and the experiments/activities to validate the proof points required. This article sets out some key considerations to get the most out of your POC.
When starting out with an innovation, it is natural to begin with an implicit mentality of “if I build it, they will come”, meaning that once others see the brilliance of the idea, everything else will be easier. That may be true when the concept is hard to communicate but normally this can be more cheaply achieved using a 3D rendering of the concept.
So before you start, consider if you need a proof of concept at all. In particular:
Have you developed a business plan and does it clearly state the purpose and rationale for having a POC?
How does your POC fit within a clearly defined product road map? E.g. will the POC design evolve into a commercial product?
What is your product development strategy? E.g. Agile versus waterfall?
What is your appetite for discarding the POC once it has served its purpose, versus wanting to, or knowing you will, reuse some of its design elements later?
Do you intend to rely on POC test results in formal submissions?
These factors strongly affect the best approach to take for a POC. It may be that a throw away POC is fully justified but it can also be prudent to put a little more into your POC to get the job done properly or to smooth the next iteration in the product development process.
Identifying proof points
The professional approach is to firstly identify all the proof points your POC is trying to demonstrate. Here are some questions to consider:
Who are the audience groups for this POC and what are they looking for?
Is the POC an eligibility requirement for grant funding?
What are investors looking for in your POC?
What concept(s) is the POC trying to communicate?
What technical elements needs to be de-risked? What feasibility is being proven?
What commercial elements need to be de-risked?
What features are you trying to validate as being useful?
What are the performance characteristics your final product will need?
What data will your POC be used to collect? For what purpose?
What elements of the manufacturing process will you test with this POC?
As you address these questions, it is worth considering this: Does your POC qualify for the R&D tax concession? (see article and free templates). If so, the costs you incur may be nearly halved.
Validation
Some POCs are used for simple “show and tell” evaluation, and are not subject to rigorous testing. Conversely, other POCs are used to prove or de-risk critical concepts, and are tested accordingly. How will you gather the evidence to support your proof points? This will depend on the nature of each proof point but consider the following:
What is your hypothesis or objective of your investigation?
What is your experimental design? How can you be sure the results you are observing are due to your product and not external factors?
Do you need to use calibrated equipment to take measurements and gather data?
What methods will you use to analyse the data?
What is the sample size you need? What range of sample groups do you need to draw from? Do you need a control group?
If you are applying for the R&D tax concession you will need to carefully consider how you document your experimental process and the results.
Project Planning
The next step is to develop a “light” project plan. Key points to consider are:For most POCs a simple Work Breakdown Structure in Excel with time and cost estimations for each task, is normally sufficient to deliver the POC in time and on budget.
What is the order of priority for the proof points listed above?
What is your timeframe and budget?
Considering all of the above, what will be included in the scope for the POC?
What are the tasks that need to be undertaken to complete the POC?
What are the lead times for any POC components that need to be delivered (see below)?
For most POCs a simple Work Breakdown Structure in Excel with time and cost estimations for each task, is normally sufficient to deliver the POC in time and on budget.
Technology selection
With the huge range of options available, it is hard to know which combination of products, modules and components are the best fit for delivering the proof points your POC has to deliver. Following are some of the typical technologies Genesys works with:
Genesys baseboards with an extensive library of embedded software for various industrial sensing scenarios, including our Wireless Wearable Sensor platform
Genesys mobile device app for rapid development of demonstration user interface, data gathering and visualisation, control functions etc
System on Module (SoM) devices for specific functions to be embedded into a wider system.
Genesys modules including those for 4G, 5G, LoRa, NB IoT, WiFi, GPS and more.
Eval boards and dev kits if a particular unique technology is most appropriate.
OEM devices such as cameras etc.
Other devices such as Programmable Logic Controllers and Data Acquisition modules.
Custom PCBs can be developed rapidly when the specific POC requirements cannot be achieved otherwise.
Single Board Computers (SBC) including Raspberry Pi, Arduino and Beaglebone (normally only in cases where the PoC is a throw-away, as these devices are generally not suitable for use in a commercial product)
It’s difficult to generalise as to when each of the above technology options are the most appropriate, as they are highly contextual to the circumstances of each project. With more than 30 years of experience, Genesys can quickly recommend the best technology for your project.
Visit our Rapid Proof of Concept Service page for more information or contact us now to discuss how to get the most out of your POC.
Comentários