Our method
Six gates, six deliverables
How a design-in actually advances, and how the pipeline is weighted against it.
Design-in pipelines fail as forecasting instruments because they measure sentiment. A gate in this model is a state the opportunity is in, and it is passed only when a specific document exists. Enthusiasm is not a deliverable. Neither is a good meeting.
| Gate | Evidence deliverable | Weight | Typical | |
|---|---|---|---|---|
| 1 | Architecture access | Meeting record naming the program, and the power map under NDA | 5% | 0–2 months |
| 2 | Concept and modelling | Modelling review with a predicted result | 15% | 1–3 months |
| 3 | Test vehicle | Test report, ideally co-signed | 35% | 2–6 months |
| 4 | Integration freeze | Interface control document | 55% | 1–3 months |
| 5 | Qualification | Qualification data book and approved-vendor status | 75% | 3–9 months |
| 6 | Award and ramp | Production purchase order | 90% | — |
Twelve to eighteen months from first architecture meeting to production order is normal at the silicon and platform layers. That is the design cycle, not a hedge. Timing is recalibrated by sector — facility and power programs run longer, channel and integration programs shorter — but the sequence does not change and neither does the requirement for evidence.
Three rules
What does not change
Target before access
Access bought without a scored target list is activity. The list decides which doors are worth the year they cost.
Evidence before advancement
A gate is passed when the deliverable exists, not when the meeting went well. Prove the value before moving forward. Enthusiasm is not a deliverable.
Shared commitment before scale
Before a program scales, both sides align on what they fund and staff at each gate. Programs that skip this do not fail, they drift, which is worse.