New MCU on the market? Cue the influencer unboxing frenzy.
Meanwhile in real commercial projects? Nobody cares about the hype. Here’s what actually happens when you take an embedded product from idea to mass production.
Market trends are just one factor – and usually not even the most important one.
The consecutive iteration of a prototype that gives satisfactory results is ready for extensive testings
define the scope of the project
Everything starts with a meeting with the product manager.
They tell you what the company actually wants: the target price point, must-have features, nice-to-have extras, expected production volume, time-to-market.
But there’s another group whose opinion matters just as much: service technicians. Why? Because introducing a product to the market is not only about competitive pricing. It’s also about serviceability.
A well-designed product means:
- fast and efficient troubleshooting
- minimal training needed for technicians
- almost no customer frustration during repairs
If even a simple system requires referring to a 50-page manual to set jumpers, flip secret switches or perform strange configuration sequences – that’s a clear sign the design went wrong.
market & competitor analysis
Once I know the expectations, I dive into what’s already out there.
What is the current industry standard? What features are considered premium? Somehow we have to define the product’s market positioning relative to competitors. Very often I discover that many premium options can be added purely at the software level – either now or later. Sometimes it’s just a matter of buying a few extra passive components whose cost is basically negligible.
The product manager might not even be aware of these possibilities. It’s your job to bring them to the table.
With this full picture, you can prepare several realistic variants and get management approval.
Define price, features, timeline] --> E C[Consultation with Service Team
Serviceability, easy repairs, minimal --> E training] D[Market & Competitor Analysis
Standard vs premium features] --> E E --> F{Approved by management?} F -->|No| E F -->|Yes| G[Choose hardware platform] G --> H[Split into functional blocks.
Power, I/O, processor, interfaces, memory] H --> I{Prototype + functional testing} I-->|Failed
Identify problems, re-iterate|G I-->|Passed|J J{BOM cost optimization
Every extra $5 = $5k loss per 1k units} J-->|Failed|G J-->|Accepted|K K{First batch testing} K-->|Failed|I K-->|Everything perfect!|L L[Certification
EMC, RED, CE/FCC – often +€15–30k]-->M M[11. Serial Production]-->N N[12. Field Service & Maintenance]
the real challenge begins
After the design is greenlit, the hardware platform must be chosen.
This is where deep electronics experience is essential.
you split the requirements into circuit blocks:
- power supply
- data processing
- I/O interfaces
- communication buses
- user interaction
- data storage
All of this must be balanced against the dynamics of the controlled process.
- Medium or high inertia process? An 8-bit MCU is often more than enough.
- Real-time, low-latency demands? you may need a much more expensive SoC.
And then comes the moment of truth: a confrontation with the BOM cost.
Testing the prototype - pass or fail?
Underestimate the requirements → prototype fails, back to square one.
Overestimate → you risk blowing the budget and killing the project before it even starts.
Remember: companies care about profit. If they don’t feel the vibe of a future income, they stop.
Every over-specced chip that costs $5 extra = $5000 unnecessary loss on every 1000 units.
tools that actually help
To keep development smooth, I always reach for proven, mature libraries for peripherals.
I have zero desire to read a 300-page datasheet of some graphic OLED just to figure out how to transfer the frame buffer over SPI. In six months that display will be obsolete anyway. I’d rather spend time on the product than fighting aging components.
The same goes for vendor tools.
If the IDE is buggy, if libraries from the new compiler version barely reference the old namespace – I avoid that vendor.
a word on certification
If your product is going to the real market, certification is unavoidable.
your brilliant idea of adding a WiFi dongle for IoT features? That means expensive RF testing, EMC compliance, RED/CE/FCC certificates – sometimes €15–30k extra. Many engineers forget about this until it’s too late.
aftermath
This is what real commercial embedded development looks like.
It has almost nothing to do with youTube videos showing how you can control a relay over WiFi with the newest ARM SoC. That’s fun, that’s educational, but that’s not the real world.
The real challenge is balancing features, cost, serviceability, time-to-market and certification – while keeping the project profitable.
The flowchart I attached depicts that designing and launching a product to market is an entirely different game compared to tinkering with electronics in your own lab. As you can see, there are dozens of critical decisions along the way - ones that ultimately determine whether management will dump the project because they consider it unprofitable or unable to compete in the real world. Without sufficient experience it’s very easy to make a wrong choice at - i.e. - the hardware platform level, which then forces you into many, many rounds of prototype iterations. And each of those iterations burns huge amounts of time and R&D budget. I haven’t even mentioned the timeline yet. With a really good project manager the whole journey might take several months. In the worst case - it drags on for years, fails spectacularly, and expenses end up flushed down the toilet on research that never sees the light of day.
Want to share own experience? I’d be glad to hear!