Our method

Steering a deeptech project through evidence

Reducing risk step by step: tackle first what could make the project fail, and decide on facts rather than deliverables.

Talk to an expert Understand the TRL scale

In short

Innowide's method means steering a deeptech project through evidence rather than deliverables. We first identify the critical hypotheses that could make the project fail, then test them in short loops, with prototypes designed as decision-making instruments. Each cycle produces data that lets you continue, change course or stop. We apply this approach, rooted in agility and adapted to hardware, between TRL 2 and 6.

Principle #1

Steer an uncertainty curve, not a schedule

At the start, a deeptech project does not first need a detailed master schedule, but an explicit reading of its critical uncertainties. We distinguish five families.

Value

Is the problem important enough? Does the solution bring a significant gain?

Technical

Can the solution reach the expected performance? Which physical limits could block it?

Integration

Does it fit into the wider system? Are interfaces, environment and safety manageable?

Industrial

Can it be manufactured, qualified, sourced, maintained and scaled?

Organisational

Do we have the skills, the sponsor, the decision pace and the governance to move forward?

Principle #2

A deliverable reassures. Evidence lets you decide.

Deliverables are useful, but they become misleading when they are not tied to any evidence. A prototype can be delivered without answering the right question.

A deliverable shows that something was produced

  • A mock-up or a prototype
  • A study report
  • A target architecture
  • A roadmap

Evidence shows that something was learned

  • A measurement confirming a performance level
  • A test revealing a physical limit
  • A comparison between two architectures
  • A trial revealing an integration constraint

Principle #3

Link every action to a decision

A simple but demanding chain: it avoids both the overly abstract project and the overly busy one.

  1. Vision

    What ambition are we serving, for what concrete impact?

  2. Deadlocks

    Which deadlocks could invalidate that ambition?

  3. Artefacts

    What minimal artefact (prototype, test bench, simulation) lets us remove them quickly?

  4. Decision

    What will we conclude from the result?

The decision file

At the end of every iteration, the same short document: what we tested, what we measured, the maturity level reached, what holds, what doesn't, the decision we recommend and what it commits you to. It ends with a proposal for the next iteration, with its expected evidence and price. When the measurement says stop, we write it down.

Our approach

Four steps, repeated in short loops

We tackle first what could make the project fail. Each cycle develops, tests and validates the critical points before more resources are mobilised.

  1. Frame the deadlock

    Pinpoint what could make the project fail and state the critical hypotheses to test.

  2. Ideate and design

    Explore the technical options and design candidate solutions.

  3. Prototype

    Quickly build prototypes designed as decision-making instruments, not finished products.

  4. Experiment and decide

    Test, measure, then deliver a decision file: continue, redirect or stop.

A prototype is not a mock-up: it is a decision-making instrument.

Agile for Hardware

Keep the agile mindset, adapt the tactics to reality

Copying software practices often leads to a dead end in deeptech. Agile principles remain powerful; it is the tactics that must be adapted to hardware constraints.

What we keep

  • A focus on value: prioritise what reduces a structural risk
  • Feedback loops that turn hypotheses into facts
  • Adapting to change, because uncertainty is part of the terrain
  • Team autonomy, within a clear framework and clear decision criteria

What we adapt

  • Initial framing before iterating: intention, deadlocks, decision criteria
  • Two rhythms: short disciplinary sprints and system-level iterations
  • Prototypes designed to answer a question, not to impress
  • Milestones organised around decisions rather than deliveries

The four dimensions of a useful cycle

An integration goal

Not "what will we do?" but "what will we make testable together?"

A prototype strategy

Do not confuse speed of building with speed of learning.

Deliberate alignment

Synchronise disciplines when it is essential, not all the time.

A reality check

Bring in early what the real world accepts, rejects or transforms.

TRL scale

Understanding technology maturity

The TRL (Technology Readiness Level) scale describes a technology's maturity in nine levels, from observing a principle (TRL 1) to operation in real conditions (TRL 9). Innowide works between TRL 2 and 6, where critical points still need to be proven.

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
Innowide's focus · TRL 2 → 6

TRL 1 to 3

From principle to proof of concept

What it proves
A principle can be harnessed and a first demonstration obtained in controlled conditions.
What it does not prove
That the solution is robust, integrable or manufacturable.

TRL 4 to 5

Validation in the lab or a representative environment

What it proves
The technology works beyond an isolated demonstration, reproducibly.
What it does not prove
That the simulated environment reflects real conditions.

TRL 6 to 7

Demonstration in a relevant or operational environment

What it proves
A demonstrator works in a relevant environment; the architecture becomes credible.
What it does not prove
That the technology can be industrialised or that system integration is risk-free.

TRL 8 to 9

Qualification and real conditions

What it proves
The technology is qualified and proven in real conditions.

What TRL does not measure

Manufacturing maturity

Producing at acceptable cost, rate and quality: that is what MRL covers.

Integration maturity

A building block mature as a component can remain immature as a system.

Qualification maturity

The sector's regulatory or certification requirements.

Usage maturity

What users and the operational environment actually accept.

What about your organisation? Measure your maturity on hardware agility, technological uncertainty or prototyping in 5 minutes.

Take the self-assessment

FAQ

Frequently asked questions about the method

What does steering through evidence mean?

Organising a project around what has been learned rather than what has been produced. A deliverable shows that something exists; evidence reduces an uncertainty and lets you decide: a measurement, a test, a comparison or an integration trial.

What is Agile for Hardware?

A way of applying agile principles (value, feedback, adaptation) to hardware and deeptech projects while adapting the tactics: initial framing before iterating, prototypes designed as decision-making instruments, and two rhythms combining short disciplinary sprints and system-level iterations.

Why are sprints not enough in hardware?

Because a sprint built around a list of tasks does not speed up learning. In hardware, a useful cycle is built around an integration goal, a prototype strategy, deliberate alignment between disciplines and a reality check.

What is the TRL scale?

The TRL (Technology Readiness Level) scale measures a technology's maturity in nine levels, from observing a principle (TRL 1) to operation in real conditions (TRL 9). Innowide works between TRL 2 and 6.

Is TRL enough to assess a project's maturity?

No. TRL measures technology maturity, not manufacturing (MRL), integration, qualification or usage maturity. A project can be advanced in TRL and still very immature in terms of industrialisation.

What is a prototype as a "decision-making instrument"?

A prototype designed to reduce a priority uncertainty, not to show progress. It answers a specific question: validating a principle, comparing two options, measuring a performance or revealing an integration constraint.

Further reading (in French)

Putting the method into practice

Technology to validate

Research & Technologies

Turn hypotheses into concrete evidence before you decide.

Discover the expertise

Project unclear or stuck

Innovating under uncertainty

Identify the critical priorities and get the project moving again.

Discover the expertise

Move faster

Tech Studio

Accelerate with technological building blocks explored and matured upstream.

Discover the expertise

Let's apply the method to your project.

30 minutes to identify your critical hypotheses and the first evidence to produce.

Talk to an expert