What An Embedded Product Development Cycle Actually Looks Like

Ask a final-year team how their embedded project is going and you will usually hear about a component that has not arrived. Ask what problem the product solves and the answer is often vaguer than the bill of materials. That order is backwards, and it is the single biggest reason good ideas stop at the prototype.

Requirements before components

Before a single part is chosen, write down what the device must do, the conditions it must do it in, and how you will know it worked. Power budget, operating temperature, enclosure constraints and expected duty cycle decide the microcontroller. Choosing the microcontroller first and discovering the power budget later means starting again.

Prototype to answer a question

A prototype is not a small product — it is an experiment. Each iteration should answer one question: does the sensor read accurately at range, does the radio hold a link through a wall, does the battery last a week. A prototype that tries to answer everything answers nothing clearly.

Design for the person who assembles it

Test points, connector keying and silkscreen labels cost nothing at design time and save hours per unit later. If your board can be assembled backwards, eventually it will be.

Documentation is part of the deliverable

Schematic, BOM, firmware build instructions and a test procedure. Without them the project is one person's private knowledge, and it dies the day they graduate.