Technical diligence in deep tech

The space between invention and adoption

Deep-tech diligence sits somewhere between a lab notebook and a market analysis. A technology can look strong on paper and still be difficult to adopt. A market can look large and still be difficult to enter. A patent portfolio can look impressive and still fail to create meaningful defensibility. A prototype can be technically mature and still be far from practical use.

The hard part is staying honest about both sides: what the technology can do, and what the surrounding market, regulatory, IP, integration, and adoption environment will allow.

Maturity is not the same thing as readiness

Technology Readiness Level, or TRL, is useful as a shorthand, but it should not be treated as the same thing as adoption readiness. Maturity asks whether the technology has been demonstrated. Readiness asks whether someone can actually use it.

A high-TRL system may still require difficult integration, new workflows, procurement changes, validation, certification, training, manufacturing readiness, or customer behavior change. A lower-TRL technology may sometimes have a clearer path if the use case is narrow and the integration burden is low.

A few questions worth asking:

• What has been demonstrated?
• Under what conditions?
• What environment was the technology tested in?
• What still has to be integrated?
• What evidence would a real buyer, partner, or regulator need?
• What would need to change around the technology before adoption becomes realistic?

IP that matters

A long patent list is not automatically a moat. Patents can matter, but the diligence question should go beyond counting them. The better question is not simply how much IP exists, but what practical advantage the IP position creates, and against whom.

Useful questions in this layer:

• What do the claims actually cover?
• Are the claims broad, narrow, or easy to design around?
• Does the IP protect the core value proposition or only a peripheral implementation?
• What would a competing implementation need to avoid?
• Are there freedom-to-operate concerns?
• Are there blocking rights from other parties?
• Is the value in patents, trade secrets, know-how, data, process experience, regulatory experience, or customer access?

These are general diligence questions, not legal advice. The real answers depend on the specific claims, jurisdiction, and competitive context.

Market fit signals beat market size slides

Top-down market size estimates can be useful context, but they often do less work than people think. For early deep-tech opportunities, specific customer signals usually matter more.

Signals worth listening for:

• A repeated pain point across independent conversations
• A current workaround
• Cost of inaction
• Urgency
• A budget owner
• An existing procurement path
• The performance threshold required for adoption
• The evidence required for pilot or purchase
• The reasons a buyer might still say no

It also helps to keep the gradient between signals visible:

• “That’s interesting” is not the same as “We would test this.”
• “We would test this” is not the same as “We would buy this.”
• “We would buy this” is not the same as “We can procure this within our actual constraints.”

Specificity is a stronger signal than vague enthusiasm.

Adoption risk is often the hidden category

A technology can be technically strong, protected by IP, and aimed at a real market, but still face adoption barriers that determine whether it gets used. Five categories show up often.

Regulatory pathway

• What evidence is required?
• Who reviews it?
• How long might it take?
• What standards or approvals matter?
• Does the team understand the pathway?

Integration cost

• Does adoption require new equipment, data migration, workflow redesign, retraining, validation, or infrastructure changes?
• Who bears that cost?

Switching cost

• Is the improvement large enough to justify moving away from an imperfect but familiar solution?
• What internal risk does the buyer take by switching?

Procurement reality

• Can the buyer actually purchase this?
• Are there budget cycles, vendor approval requirements, contracting steps, cybersecurity reviews, or pilot requirements?

Evidence burden

• What proof is needed beyond a demo?
• Are field trials, reliability data, validation studies, cost models, safety evidence, or third-party evaluation needed?

This does not mean the opportunity is weak. It means the path is heavier than the pitch may suggest.

A practical way to structure the questions

One useful way to keep the evaluation honest is to separate the questions into layers. This is not a proprietary framework, just a way to organize thinking so that different kinds of risk do not blur into each other.

Technical function

• What is the core technical function?
• What is mechanism, what is application, and what is aspiration?
• What performance claim is supported?

Evidence and maturity

• Is this a concept, model, benchtop result, prototype, pilot, or deployed system?
• What data exists?
• What is missing?
• What would the next validation milestone be?

IP and defensibility

• What claims, know-how, data, process, or partnerships matter?
• Can competitors design around the position?
• Does the protection match the commercial path?

Use case and buyer

• Who uses it?
• Who pays?
• Are those the same people?
• What current workaround exists?
• Why now?

Adoption pathway

• What needs to be integrated?
• What needs to be validated?
• What approvals are required?
• What behavior has to change?
• What procurement path exists?

Commercial path

• Is this better suited for a startup, license, joint development, strategic partnership, internal deployment, or more research?
• What milestone would increase confidence?
• What partner or buyer would reduce risk?

This structure does not remove judgment. It makes the judgment more transparent.

Examples of the questions changing by context

A new sensor

The question is not only whether the sensor works. It is whether it works under relevant conditions, integrates with existing systems, produces trusted data, and creates enough improvement to justify adoption.

A biotechnology platform

The question is not only whether the biology is plausible. It is whether outputs are repeatable, the use case is specific, the validation path is credible, and the regulatory or evidence burden is understood.

A software tool for technical workflows

The question is not only whether the software can generate useful outputs. It is whether the tool fits the user’s workflow, has access to required inputs, produces trusted outputs, and reduces decision burden.

A manufacturing process

The question is not only whether the process improves performance. It is whether it can scale, whether it requires new capital equipment, whether quality control is realistic, and whether customers can adopt it without disrupting production.

Uncertainty is not the problem. Unclear uncertainty is.

Deep-tech diligence should not pretend to eliminate uncertainty. Early technologies naturally involve it. The goal is to make uncertainty visible and useful.

A good diligence process should distinguish:

• what is known
• what is assumed
• what has been demonstrated
• what has only been modeled
• what customers have actually said
• what is inferred
• what must be true for the opportunity to work

A useful diligence output should identify the main reason to believe, the main reason to doubt, and the next thing that would change confidence.

Not every strong technology belongs on the same path

A strong technology does not automatically need to become a venture-backed startup. Some technologies are better suited for licensing, strategic partnership, joint development, internal deployment, or additional research.

Venture path

May require a large market, a scalable model, a strong team, defensibility, and a financing path that matches the time horizon.

Licensing path

May require clear rights, identifiable licensees, a defined use case, and a fit into another party’s existing product or process.

Partnership path

May make sense when the technology needs validation, manufacturing access, customer access, regulatory support, data, or integration that one party cannot provide alone.

Research path

May be the honest answer when the technical idea is promising but too early for commercialization.

The goal is not to force every technology into the same mold. The goal is to identify the path that fits the evidence.

From technical possibility to practical use

Technical diligence in deep tech requires two forms of honesty: honesty about the technology and honesty about adoption.

The best diligence does not flatten technical complexity into a simple yes or no. It creates a clearer map of what is real, what is promising, what is risky, and what should be tested next.

I am most interested in diligence when it becomes a tool for better decision-making: not just a gatekeeping exercise, but a way to move from technical possibility toward practical use.

These notes reflect my own general observations and do not represent any current or former employer, client, or partner. They do not disclose confidential information and are not legal, investment, regulatory, or business advice.