Definition
Design-in intelligence for semiconductor vendors.
A design-in is the decision by a product's engineers to build a specific component into the product. For the semiconductor vendor it is the unit that revenue follows, because the part then ships with every unit of that product for as long as the product is made. Design-in intelligence is the work of finding where those decisions are open or could be reopened.
In practice it answers one question per product: could this part take this socket, and is there a reason to ask now. The answer is built from public technical evidence, and each claim in it carries the source it rests on.
A product, not a company.
Most sales data is organised by company. A design-in is decided per product and per revision. One company can have a camera line where the part fits and a controller line where it never will, on different schedules, with different engineers.
So the record is a product: what it is, what its documentation says it needs, which checks a given part passes against it, which part is in it today if that is known, and what evidence exists that the design is open.
Technical fit says whether the part could serve the product. Timing says whether anyone is deciding. A product can fit perfectly and be three years from its next revision. Both are recorded; neither is inferred from the other.
The part's capabilities come from the manufacturer's own datasheet, and the list of parts it can realistically replace comes from their field team. That side is given. The work is on the market side.
What public documentation says, and what it leaves out.
Product datasheets describe what a product does for its buyer: interfaces to the outside, power, temperature range, size. They almost never name the processor, programmable device or memory inside. In a test on five industrial products in September 2026, none of the five datasheets named the device inside the product.
The missing half has to come from other kinds of page: regulatory filings with internal photos, teardowns, job postings, and the manufacturer's own knowledge of where competing parts are used.
- Datasheets and product pages: requirements
- Regulatory filings and teardowns: what is inside
- Job postings: what a team is working with, and when
- The manufacturer's field knowledge: where competing parts already sit
Personal data collected from public traces. The records are about products and companies, with sources. Contact data, where an engagement needs it, comes from the client's own systems or a licensed provider.
Where the evidence stops.
For many products nothing public says what is inside. In the same test, targeted searching found the incumbent device for two of the five products and nothing for the other three. Those products are recorded as open questions, not as guesses.
- Missing evidence is not evidence that a part does not fit.
- A product launch does not prove that component selection is open.
- A job posting names what a team works with, not what is in a specific product.
- Several pages repeating one source count as one source.
The test used a stand-in product line and public documentation. It was not a customer engagement, and its counts are observations, not performance figures.
The pages that go into detail.
- How opportunities are found, and why the usual methods miss them
- How each kind of signal is detected and what it can establish
- How this differs from intent data, technographics and lead databases
Finding design-in opportunities · How signals are detected · FPGA product-fit screening · Compared with intent data · Compared with technographics · Compared with lead databases
Bring a product line and an application class