Edge AI – Difference Between a Project and a Product

To the optimist, the class is half full. To the pessimist, the glass is half empty. To the engineer, the glass is twice as big as it needs to be.


Edge AI and TinyML are having a moment.   The tech world has woken up to the fact that it is possible to put machine learning models on small, inexpensive microcontrollers. GitHub is now full of examples of Edge AI and TinyML models for all sorts of things.

These are interesting projects.  In addition, they effectively illustrate the concept and demonstrate that it’s now feasible to do really big things on really small processors.  And we applaud them. However, at Reality AI we work with engineers building products. Building a product is very different from completing a project.

What do we mean by that?  It means that there’s just a lot more to product development.

Executing a Project vs. Building a Product

A project is something that I create, here on my lab bench.  Maybe I build it myself, or maybe I build it with a small team.   It works for me (or us) in a limited range of conditions defined by our project scope, and it works on our particular apparatus.   

On the other hand, A product has to work everywhere our customers use it and they use it in all kinds of unpredictable conditions. Additionally, It has to work on all versions and in all configurations that we sell.  Products are built by larger teams that include marketing, management, and manufacturing, as well as engineering.  Most importantly, everyone involved is deeply worried about cost.

Certainity and Scale – Major differentiators

The difference between a Project and a Product can be described as differences in Certainty and Scale. Firstly, to build a product successfully and get it to release, we must achieve certainty about how it will function. Secondly, there has to be certain about the consistency of that function. Further, there should be certain about the cost — the cost of components (the Bill of Materials, or BoM), the cost to manufacture, and the cost to support.  And finally, this certainty must be achieved at a scale that matches the scale of our customer base.  To summarize, Products need to work predictably and well in every context and in every way that customers expect to use them.

Executing a projectBuilding a product
Built by me, or by a small project teamBuilt by the organization, including marketing, manufacturing, and management
Testing limited by project scopeTesting as broad as our customer base and their use of the product
Proving feasibility or aspects of functionalityMaking something customers will buy, use and love
Thinking about costMaking decisions about cost

Project and Product difference in Edge AI / TinyML context

When we’re talking about Edge AI / TinyML in product development, these differences have important ramifications. These differences have been summarized below in the table.

Executing projectsBuilding products
Sensor & Processing HardwareMight use Development board or prototyping kit
Need production-ready components that can be sourced from the supply chain at an acceptable cost.

Need to analyze and resolve cost/benefit tradeoffs between different components, sensor locations, and processor choices.
ML GeneralityLimited by project scope. Predicts accurately on project hardware, but generally is untested.Must work on all versions of the device, regardless of small variations in manufacturing and implementation. And must contain accurate predictions for the expected life of the period
Data CollectionLimited by project scopeMust provide some degree of coverage of a full range of variation in customer use and implementation
ML ToolsDev kits and basic AI Modeling softwareA broad set of engineering tools to understand issues presented by different hardware choices, sources of variation, analysis of metadata, explainability, and statistical confidence

Building an Edge AI Product Requires Different Tools

In our experience, the generation of the TinyML model is the least challenging part of product development — at least, it is if you’re working with a good toolset like Reality AI.   But, far more time-consuming are the aspects of hardware development and data collection.   That’s why we’ve focused on creating functionality that helps with these super-important product development problems:  BoM optimization,  AI-driven component selection and specification setting, AI-driven tolerance, and sensitivity testing, and features for managing the collection of data at scale by automatically checking data consistency, quality, and coverage.

YouTube demo videos and GitHub project repositories can make TinyML / Edge AI projects look easy.   And with AutoML tools for Edge AI like Reality AI, they can be easier than ever.  But the hard work of product development requires more than ML projects — and we’re working to make all that easier too.

Edge AI : Products Start with Projects

Don’t get me wrong.   Every product development effort our customers have launched began with a limited scope project. Most importantly, there is great value in a properly constructed Proof-of-Concept (PoC) at the beginning of an effort to prove feasibility and resolve important technical questions before spending time and resources on product development.

The danger in these early-stage projects is in expecting too much from them — they rarely translate directly into a deployable or manufacturable product without further development of hardware, processing, and the machine learning models themselves.   Only through extensive testing in a wide variety of circumstances do you discover all the corner cases that trip up models and require tweaks or retraining.  If you expect that an ML model built for a feasibility PoC will translate directly into deployable product functionality, you are in for some disappointment.

To get there, you need to place the machine learning development into a proper product development process, including model development, component selection, integration, field testing, and end-to-end certification.  While you’re at it, consider using some machine learning software that’s properly built to support that process.

Related Posts