Every client asks this question. The honest answer is: longer than you think, for reasons that are almost entirely predictable. Understanding where the time goes is the first step to planning a development programme that doesn't collapse under the weight of its own optimism.
Why timelines are almost always wrong at the start
Product development timelines produced before any design work has begun are not estimates — they're aspirations expressed in weeks. The information required to build a reliable schedule doesn't exist at project initiation: the design hasn't been explored, the manufacturing process hasn't been confirmed, the regulatory requirements may not be fully understood, and the number of iteration rounds needed to reach a satisfactory result is genuinely unknown. What gets produced instead is a timeline built on the assumption that each stage will go roughly to plan, which is a reasonable assumption for any individual stage and an almost certain underestimate for the programme as a whole.
This is not a failure of planning discipline. It's a structural feature of development work, where each stage reveals information that changes the scope of the next. The useful response is not to plan more elaborately before the work starts — more elaborate plans made on less information are not more accurate — but to build timelines that acknowledge uncertainty explicitly and create space to absorb it without everything slipping.
The stages and what each one actually takes
Product development follows a broadly consistent sequence regardless of the product: concept and brief, initial design and CAD, prototyping and iteration, engineering validation, manufacturing preparation, and production ramp. Each stage has a characteristic duration range, but the ranges are wide enough to be nearly useless without knowing the specifics of the project. What's more useful is understanding what drives duration within each stage — which is where the controllable and uncontrollable variables sit.
Concept and brief, handled well, takes days to a few weeks. The output is a sufficiently defined problem statement and design direction to begin CAD work without fundamental rework later. Rushing this stage is one of the most reliable ways to extend the overall programme — not because the brief itself takes long to produce, but because a poorly specified brief generates rework at every subsequent stage that individually seems like a design problem but is actually a specification problem in disguise.
Initial CAD and design development typically runs four to twelve weeks for a product of moderate complexity, assuming a clear brief and one senior designer working the geometry to a point where it can be prototyped. That range widens significantly for products with complex mechanisms, tight integration with electronic or structural components, or requirements that evolve during the design phase — which they often do once physical form starts to make the implications of decisions visible in a way that abstract briefs don't.
Prototyping and iteration is where timelines most consistently diverge from initial estimates. The number of rounds required is genuinely hard to predict in advance, and each round takes longer than it appears to — not just the print or machining time but the review, feedback consolidation, CAD revision, and re-preparation for the next round. Two to four prototyping iterations is typical for a product of moderate complexity. Six or more is not unusual for products with ergonomic requirements, complex assemblies, or performance targets that take multiple rounds to converge on.
The number of prototyping iterations required is the hardest variable to predict and the most significant driver of overall programme duration. Building a timeline that assumes one or two rounds and delivering four is not a planning failure — it's product development working as it should.
Engineering validation: the stage most timelines omit
Many development timelines produced for products that will eventually be sold to consumers or used in professional applications don't adequately account for engineering validation — the stage where the design is tested against its performance requirements in representative conditions before production tooling is committed. This is partly because validation can be easy to underestimate when the design looks right on screen and the prototypes have been progressively improving, and partly because clients who are eager to reach production are sometimes willing to accept a level of validation risk that a more cautious programme wouldn't.
The cost of inadequate validation is paid at some point regardless. A product that reaches production with an unresolved performance issue requires an engineering change after tooling — which is expensive — or a product recall — which is more expensive still — or a quiet acceptance that the product doesn't quite meet the specification it was designed to, which has its own long-term consequences. The time spent on validation before production commitment is almost always cheaper than the time spent managing the consequences of skipping it.
What validation takes depends entirely on what the product needs to demonstrate. Environmental testing — thermal cycling, ingress protection, drop testing — requires access to test facilities and has minimum duration requirements set by the physics of the tests, not the project schedule. Regulatory certification adds further time that is largely outside the development team's control: CE marking, UKCA, UL, or sector-specific certifications each have their own submission and review timelines. For products entering regulated markets, these durations need to be in the programme from the start, not retrofitted when someone realises they're required.
Manufacturing preparation: longer than it looks
The transition from validated design to production parts involves a set of activities that are individually unremarkable and collectively time-consuming. Tooling design and manufacture for injection moulded components typically takes eight to sixteen weeks from design sign-off to first samples — longer for complex multi-cavity tools or tools with side actions and lifters. First article inspection of tooled samples, tool corrections, and re-inspection add further weeks before production quantities can begin.
Supply chain qualification runs in parallel with tooling in a well-managed programme and sequentially in one that isn't. Qualifying a new supplier — auditing capability, reviewing quality systems, agreeing terms, and running sample approvals — takes time that is easy to underestimate when the focus is on the design rather than the supply chain. For products with multiple components from multiple suppliers, the longest qualification timeline drives the production start date regardless of how quickly the others resolve.
Assembly process development is similarly easy to omit from early-stage timelines. A product that is straightforward to design and straightforward to prototype may be significantly harder to assemble efficiently at production volumes. Building a production assembly process — defining the sequence, tooling the workstations, training the operators, establishing quality checkpoints — takes time that needs to be accounted for before the first production order can be fulfilled.
Rough duration ranges by product type
Simple single-component part: A bracket, housing, or non-functional enclosure with no electronics and no regulatory requirements. From brief to production-ready design: four to ten weeks. Tooling and first production if injection moulded: add a further twelve to eighteen weeks.
Moderate-complexity product: A multi-component assembly, a product with basic electronics integration, or something with ergonomic requirements. From brief to validated design: four to nine months. Full programme to first production: nine to fifteen months is realistic for a first-time product in this category.
Complex or regulated product: A product with significant mechanical complexity, safety-critical requirements, or mandatory certification. Twelve to twenty-four months from brief to first production shipment is not unusual, and programmes that underestimate this range reliably overrun it.
The caveat that always applies: These ranges assume a well-defined brief, a stable specification, and a client who can make decisions at the pace the programme requires. Scope changes, delayed approvals, and unclear decision-making authority each add time that doesn't appear in any standard estimate.
The variables that extend every timeline
Scope change is the most reliable source of programme extension, and it comes in two forms. The first is deliberate — a decision is made to add a feature, change a material, or adapt the product to a new market. This kind of scope change is manageable if it's recognised as a scope change and the timeline is adjusted accordingly. The second form is incremental and largely invisible: small decisions that individually seem minor but collectively expand the design work, the prototyping requirement, and the validation scope without anyone explicitly authorising an extension. This kind is harder to manage because it doesn't arrive with a conversation attached.
Decision latency — the time between a designer or engineer presenting a question and receiving a decision from the client — is a programme-length variable that most development timelines don't model at all. A programme where decisions are made within twenty-four hours runs at a fundamentally different pace from one where approvals take a week, even if every other variable is identical. For clients who are managing multiple projects or who have approval processes that involve multiple stakeholders, this is worth quantifying honestly at the start of an engagement rather than discovering its effect in the middle of one.
External dependencies — component lead times, supplier qualification timelines, test facility availability, certification review periods — are outside the development team's control and need to be identified and scheduled early. A programme that reaches the sourcing stage only to discover that a critical component has a sixteen-week lead time has a sixteen-week problem that no amount of internal effort will resolve. Identifying those dependencies at the programme planning stage, even when the design isn't far enough advanced to specify the exact component, allows contingency to be built in before it's needed rather than managed in crisis after it surfaces.
How to plan for the duration you'll actually need
The most useful thing a client can do when planning a product development programme is to build the timeline from the delivery date backwards, with honest assessment of each stage's duration and explicit contingency at the points where uncertainty is highest. That means not asking the design team to compress the prototyping stage to meet a timeline that was set before the scope of prototyping was known, and not treating the certification timeline as something that can be shortened by enthusiasm.
It also means distinguishing between the date the product needs to be in production and the date it needs to be on sale, and using the gap between them to absorb the variability that development work always contains. A product that needs to be on retail shelves for a specific seasonal window needs to be in production substantially before that window, which means the engineering validation needs to be complete well before production starts, which means the prototyping needs to be done well before validation begins. Working backwards from a real deadline produces a programme plan that can be tested against reality. Working forwards from an optimistic start date produces a plan that feels right until about halfway through, at which point every remaining milestone is already late.
The question of how long product development takes has an honest answer and a comfortable one. The comfortable answer names a number that sounds achievable and avoids the conversation about what could go wrong. The honest answer acknowledges that the time required is a function of complexity, specification quality, iteration count, external dependencies, and decision speed — and that most programmes underestimate at least two of those. Planning around the honest answer is harder in the short term and considerably less painful over the life of the project.
Add comment
Comments