When an engineer starts designing a new product, there are lots of things to take into consideration before even starting the actual development. It could be months into the development process when suddenly you realize that the hardware that was chosen in the beginning turns out to be suboptimal for the requirements of the product. Okay, now what? Start all over? Not necessarily.
The choices of software tools and hardware, as well as the development methods that shape a project are obviously a major factor in the project’s success. It may prove difficult to determine all these factors beforehand, but it will be even more difficult to change the process once started (if possible at all, without starting all over again).
To help you get a good start on your product design, here are three tips that you’ll might want to take into consideration in order to safeguard your project’s successful completion.
Choose products and tools that embrace change
During the development process, it may turn out that the requirements of the end product have changed. Features can be added or removed, and while you are optimizing the product it might become clear that you can install less powerful hardware, so you can bring down the bill of materials. In order to prevent the necessity for a complete redesign when the project’s requirements increase or decrease, it’s wise to look into products and tools that can scale up or down accordingly as the requirements change.
For example, we often see that during early phases of prototyping engineers are developing on commercial-grade electronics. Eventually, when live tests take place on-site with the customer, it turns out the product has to cope with an industrial temperature range. To completely redesign the product would take a lot of time, or it may even mean the end of the project. By opting for suppliers with an ecosystem of compatible products you create scalability and flexibility.
These scalable components are often pin-compatible products that allow you to scale up or down without adaptions to the hardware from a single-core processor to a quadcore CPU, and vice versa. Furthermore, these components are already fully tested, meaning that you can turn your focus to what separates you from your competition, instead of having to design complex electronics in-house.
Having the option to scale tools and components in terms of performance, feature sets, temperature range and more can mean the difference between a successful or a canceled project.
More innovation by using off-the-shelf products
The ability to construct a proof-of-concept without breaking the bank leads to better innovation. After all, before the (mass-)production of your new product, tests will need to be done in order to make sure all the requirements are met, while being as cost-efficient as possible. This helps to improve development and ultimately drives innovation. No need to re-invent the wheel, as most components that you’ll need are often already available on the market. It might only be a difference of 10% that will distinguish your product from the competition’s product, so resources are better spent on these 10%.
With this in mind, it may be wise to choose a development environment that not only supports this, but embraces it fully, giving you plenty of space to alter the course while already underway. By making use of readily-available software stacks, libraries or Computer-on-Modules, the initial starting risks of the project can be greatly decreased. Instead of spending costly time designing for example a processor board, you can opt for an available module with an IO-board and start working on your “Special Sauce” right away. The threshold for developing and physically testing your ideas in the real world will be lowered significantly, resulting in easier and faster innovation.
Using platform-independent tools
As mentioned, the chances of requirements changing during the development process are significant. What if you need to switch to a more powerful processor when you are already using the most powerful processor from a certain vendor? This could become a real problem, because some tools are developed specifically for a certain architecture, or for a product line of that specific vendor. This is often the case with compilers, IDE’s, GUI tools or Build Optimizers. It takes a lot of time to really master these tools well, and when it turns out these tools are only compatible with, let’s say STM32, it can become a costly endeavour to retrain yourself or your engineers to a new tool.
By choosing tools and components that are not tied to certain vendors, platforms or architecture you allow for much more adaptability in the later stages of development, bringing your end-product closer to the customer’s (or your own) requirements while keeping costs, stress and time-loss to a minimum.
We hope these tips will help you make the best decisions for your project. If we have triggered any questions while reading this, don’t hesitate and ask us. We are happy to share our insights.