How long does product development take?

For a connected hardware product of moderate complexity, twelve to twenty-four months from concept to production is typical. Software-only products move faster; anything requiring safety or medical certification takes considerably longer. Detailed engineering and certification are usually the longest stages.

What is the difference between a prototype and a product?

A prototype proves that something can work, usually once, in controlled conditions, built by the people who designed it. A product works reliably, in the field, built repeatably by someone else, and can be certified, serviced and supported. Closing that gap is what detailed engineering and pilot production are for.

Can stages be run in parallel to save time?

Partially. Mechanical and electronic design, and firmware and cloud work, routinely overlap. What should not be compressed is the gate review between stages — skipping a gate does not remove the work, it moves the discovery of problems to a later and far more expensive point.

How many prototype iterations should I expect?

Two to four for a product of moderate complexity. Fewer usually means the prototypes were not testing hard enough; many more suggests requirements were unclear at the start. Each iteration should be driven by a specific question rather than general improvement.

When should compliance and certification be considered?

During discovery, and planned in detail during detailed engineering. Identifying applicable standards early and running pre-compliance testing before formal certification is far cheaper than failing a formal test and having to redesign, which can add months.

What is the most common reason products fail?

Unclear requirements at the start. Most late-stage crises trace back to an assumption that was never written down and agreed — a constraint, a user need or a regulatory obligation discovered after the design was committed.

From Idea to Working Product: A Product Development Roadmap

Stage 1: Discovery and Definition

The most expensive mistakes in product development are made here, and they are usually mistakes of omission — a requirement that was assumed rather than written down.

Discovery answers four questions in writing:

Who is the user, and what do they do today? The current workaround defines the bar you must clear.
What must the product do? Functional requirements, stated so they can be tested.
What are the hard constraints? Cost target, size, power, operating environment, regulatory obligations, launch date.
How will success be judged? Specific, measurable criteria agreed before engineering starts.

Gate 1: a written requirements document that every stakeholder has read and agreed. If requirements are still verbal at the end of discovery, the stage is not finished.

Stage 2: Concept and Feasibility

Concept work explores several approaches before committing to one. The objective is to deliberately kill the weakest options early, while changing direction is still cheap.

Feasibility spikes

For each significant technical unknown, build the smallest thing that resolves it. Can the sensor detect the signal in the real environment? Will the radio reach from where the device must sit? Does the algorithm run fast enough on the target hardware? These are experiments, not products — the code and hardware are expected to be discarded.

Architecture and make-or-buy

Decide the split between hardware, firmware, application and cloud, and which parts are bought rather than built. A certified radio module, an existing cloud platform or an off-the-shelf enclosure can remove months of work and considerable risk.

Gate 2: one selected architecture, every major technical unknown resolved by demonstration rather than assumption, and a cost estimate credible enough to plan against.

Stage 3: Prototyping

Prototypes exist to answer questions, and different questions need different prototypes. Building one prototype that tries to answer everything is a common and costly error.

Looks-like. Non-functional models that resolve size, ergonomics and appearance. Usually 3D printed, and available within days.
Works-like. Functional electronics on development boards, often in an enclosure that looks nothing like the product. Proves the technical concept.
Integrated. The first build that combines both. This is where the genuinely interesting problems appear — thermal behaviour, assembly sequence, connector access, interference between subsystems.

Expect to iterate. Two to four prototype revisions is normal for a product of moderate complexity, and each one should be driven by a specific question rather than general improvement. Our article on taking a circuit from design to prototype covers the electronics side of this stage in detail.

Gate 3: an integrated prototype demonstrating the core function in a realistic environment, with a documented list of what must change for production.

Stage 4: Detailed Engineering

This is the longest stage. A prototype proves the product can work; detailed engineering makes it manufacturable, reliable, serviceable and compliant.

Design for manufacture

Component selection revisited for availability, lifecycle and cost at volume. Tolerances specified. Assembly sequence designed so it can be performed consistently. Test points and factory test procedures defined.

Design for the real world

Thermal behaviour at the temperature extremes, not just on the bench. Ingress protection. Mechanical robustness against the drops and vibration the product will actually see.

Production firmware and software

Prototype firmware demonstrates function; production firmware handles error states, power loss mid-write, network failure, secure boot, and over-the-air update with rollback. This is usually a larger effort than the prototype firmware it replaces.

Compliance planning

Identify every applicable standard and engage a test house early. Pre-compliance testing during engineering is dramatically cheaper than failing formal certification and redesigning.

Gate 4: a complete, released design package — drawings, bill of materials, manufacturing files, firmware and test procedures.

Stage 5: Validation and Testing

Validation asks a different question from verification. Verification asks whether the product meets the specification; validation asks whether it solves the user's actual problem.

Functional testing against every requirement from Stage 1.
Environmental testing — temperature cycling, humidity, vibration, drop, ingress.
Life and reliability testing — accelerated ageing on the components most likely to wear.
Compliance testing — formal EMC, safety and radio certification.
User validation — real users, unsupervised, in the real environment.

User validation reliably produces the most surprising findings. Products fail in the field for reasons no laboratory test predicts: an installation position nobody anticipated, an interface users read differently than intended, a maintenance step that is impractical with gloves on.

Gate 5: all tests passed, certification obtained, and user feedback either addressed or consciously accepted as a known limitation.

Stage 6: Pilot Production

A pilot run — typically tens to low hundreds of units — validates the manufacturing process rather than the design. It exists to find the problems that only appear when someone other than the design team builds the product.

What the pilot reveals:

Assembly steps that are ambiguous or physically awkward.
Tolerance stack-ups that pass individually and fail combined.
Test procedures that are too slow or produce false failures.
Yield rate, and therefore true unit cost.
Packaging that does not survive shipping.

Also settle the operational questions here: unit provisioning and serialisation, firmware loading at the factory, warranty handling, spare parts, and the support path when a customer reports a fault.

Gate 6: acceptable yield, a stable documented process, and a confirmed unit cost.

Stage 7: Launch and Iteration

Launch is a stage, not an endpoint. The first months in the field generate information no internal process can substitute for.

Instrument the product so you learn from it: device health telemetry, feature usage, error and crash reporting, and a straightforward channel for user feedback. For connected products this is where an over-the-air update path proves its value — issues found in week three can be fixed in week four across the whole fleet.

Plan the first revision before launch. There will be one. Knowing in advance which known limitations are queued for it keeps the team from treating every field report as a crisis, and keeps the roadmap honest.

From Idea to Working Product: A Product Development Roadmap

Stage 1: Discovery and Definition