The problem
How to find semiconductor design-in opportunities.
A semiconductor vendor's field team finds design-ins by hearing about a product, reading what exists about it, and judging whether their part could take the socket. It works, and it is limited by how many products one engineer can read about in a week.
The reading and the first sort can be done across a whole application class. The judgement on the uncertain cases stays with the engineer. This page describes what that looks like and where it is hard.
The information you need most is the information nobody publishes.
To know whether a part could replace what is in a product, you need to know what is in the product. OEMs have no reason to say. Their documentation describes function, not construction.
The rest is scattered. A sensor interface in a datasheet, a chip visible in a regulatory photo, a job posting that names a toolchain, a trade-press article about a new platform. None of them is a lead on its own.
- External interfaces, power, temperature range, dimensions
- Throughput figures that imply a processing load
- Launch dates and revision numbers
- The processor or programmable device inside
- The interface between the sensor and the processor
- Memory type
- Whether a redesign is planned
What an application engineer does, step by step.
The method is sound. It is the same method at scale that is missing.
- Read the product's documentation and note what it requires
- Compare each requirement with what the part can serve
- Look for what is inside: a teardown, a filing, a contact who knows
- Look for a reason now: a new revision, a hire, an end-of-life notice on the incumbent
- Decide whether it is worth a conversation
The same steps, with the evidence kept.
Each step becomes a stage with a defined input and output. Documents are collected and kept. Requirements are extracted into a fixed table, each value with the text it came from. A fixed set of questions is asked of that table against the part's criteria. Products with enough evidence are sorted; products without it go to a person.
The output is three lists: products the evidence supports, products it excludes with the reason, and products where the documentation does not say enough.
Two of the first five runs found faults in our own extraction rather than in the products: a temperature range compared by label instead of by number, and an unstated value read as a mismatch. Both were visible because a specific check moved. Both were fixed in the question definitions.
Described as built in September 2026. Extraction and evaluation have run on five public products. No accuracy figure is published until an expert-labelled benchmark has run.
What a manufacturer brings, and what comes back.
- You bring: the datasheet, the parts you can replace, the application classes you want
- You get: a shortlist with evidence, an exclusion list with reasons, a review queue
- Your field team decides the uncertain cases and their decisions improve the next run
Design-in intelligence · How signals are detected · FPGA product-fit screening · Datasheet signals · Teardown signals
Discuss a product line