A Proof of Concept Or a Preserie?

There is a lot confusion about what a proof of concept (POC) should do in the IoT world. Of course, the main goal of the POC stage is to evaluate the product concept – does it deliver the main benefits and on the overall business goal?  It is often also desirable to:

  • test user acceptance at this point,
  • evaluate the likelihood of any necessary certifications; and
  • identify any issues that might jeopardise either user acceptance or certification.

However, since this is the first physical manifestation of the connected device – the first time your idea jumps off the drawing board and into physical reality – it is tempting to get carried away creating a detailed POC which incorporates many different aspects of the product. This is a route to unnecessary costs.

From the Sigfox point of view, we believe that the main goal of the POC is to test any ‘unknown quantities’ in the overall design of the IoT solution.  This means limiting your POC to the bare minimum you need to test. Of course, this ‘bare bones’ approach can be disappointing.  But it is an important discipline to master – one that will significantly contribute to the overall success and profitability of your project.  Our experience has shown us that getting this stage right can save you money and hasten time to market – resulting in vital competitive advantage.

What follows is a description of what we believe to be the essential prerequisites which will enable you to successfully adopt this competitive-advantage-creating approach to your proof of concept.


The risk of keeping the POC to a bare minimum is that you don’t test the necessary features and functions comprehensively.  It is therefore vital that you have a very clear understanding of:

  • your overall product vision
  • a good brief
  • a clear specification
  • clear objectives
  • validated ROI

If you have all these things, you can skip POC altogether and move to pre-series, thereby saving time and money.  Of course, this is desirable – but not always possible.  It may be the case that you have specific technical aspects of your design that require further validation.  In such a situation, you will need to develop a POC model.


To keep costs low and reduce the time spent on POC, it is vital to strip back your POC to the bare minimum.  Ask yourself: what do we need this POC to prove?  Limit your POC to answering that question.  Otherwise you risk confusing the assessment with irrelevant feedback or data that does not assure effective decision making.

Reduce the POC to the bare minimum so you can focus on the particular functional or technical or ROI point that remains unconfirmed.  Do not be tempted to complicate the design further than absolutely necessary.


One straight-forward way to reduce the complexity of the POC is to look to existing products and components that are already proven.  This may even mean looking to other sectors or verticals to see how your issue is solved by other solutions and products.  Keep an open mind and explore how other people have solved your particular technical, functional or ROI problem.  If you don’t need to build it, don’t.


The POC is the first time you will get your hands on a physical manifestation of your device.  This is an exciting time.  It is all too tempting to get carried away creating an “all singing, all dancing” version of your POC – especially for inexperienced project teams.  However, this will simply create unnecessary time and expense. Stuck to the KISS principle, i.e. Keep It Simple Stupid!

An effective project manager can make the difference here.  Choosing a project manager with strong commercial experience will help to ensure that the POC team focus only on the commercially important and valuable metrics. A strong project manager will enforce the approach of maintaining a tight limit on the requirements and specification of the POC.  Not doing so risks testing something “other” and throwing up data that is not directly linked to your POC objective or, worse, falsely demonstrating success or failure.

A strong project manager will also work to help the whole team stay focused on the goal of maximising profit by using the POC to test the bare bones of your product concept and keeping this POC stage as simple but effective as possible.  As we have discussed, this is the best route to project success; minimising time to market and delivering associated competitive advantage.


Moving from your design board straight to your pre-production series is the logical extension of minimising the scope of your POC. It is, therefore, worth considering whether you can skip the POC phase in its entirety.

Ultimately, if you can prove the concept without investing in a POC model, it may be possible to skip directly to the pre-production series based entirely on your product specification, clearly stated objectives and validated ROI.  If done properly, this approach will allow you to skip the time-consuming POC element of the project and deliver maximum profit and optimum time to market.

However, this approach is not without its risks.  If you do intend to take this time-saving approach, it is vital that you have a very clear idea of your project objectives, product specification and a clearly validated ROI.  You will need an even clearer focus on:

  • your overall product vision
  • a good brief
  • a clear specification
  • clear objectives
  • validated ROI

If you do not define the specification in enough detail or demonstrate the ROI effectively before you begin, or do not have a clear understanding and definition of each of these elements, you risk creating a pre-series that does not deliver in important functions, benefits or ROI.  You risk needing to make reiterations.  This will require you to go back to the drawing board and recreate the pre-series model – thereby eliminating all the benefit you have achieved by skipping the POC stage. 

It is clear: you need all your ducks in row before moving straight to pre-series without a POC stage. However, if possible, this is the desirable option.