How to

Why Deep-Tech Teams Need Data Visualisation Before They Tell Their Story

Build a deep tech evidence map before a deck, website or film. A worked sensor example, visual selection table and six steps for technical review.

Why do deep-tech teams default to the story before the evidence is settled?

A pitch deck or film deadline can prompt a company to settle on a story before the people responsible for research and engineering have compared their evidence with manufacturing, regulatory, and buyer requirements. The asset needs a clear account of what the technology does and when someone can use it. Each function may have a different answer to the second question.

A working prototype shows that a technical approach works under stated test conditions. It does not establish that the company can produce it consistently, obtain any required approval, or deliver it under a buyer's operating conditions. If a deck calls the product ready without separating those claims, readers may take a laboratory result as proof of commercial readiness.

Consider a hypothetical sensor. Researchers may measure accurate results on clean samples, while engineers find that field temperatures affect the readings. Manufacturing may still be testing production yield, and a regulatory lead may need results gathered under a different protocol. A buyer may also require continuous monitoring that the prototype cannot yet provide. A single confident product story would conceal questions the company still needs to resolve.

What does "visualise the evidence" mean before any pitch deck exists?

Visualising the evidence before a pitch deck means mapping claims, relationships, and unknowns across functions, rather than producing charts for an audience. You can connect a research result to its test conditions, then trace whether engineering constraints, manufacturing capacity, regulatory requirements, and buyer needs support the same claim. The map should identify the evidence and owner for each claim, along with any dependency or question that remains open.

Put the lab conditions and the buyer's operating conditions beside the performance claim. If they differ, the lab result cannot yet support a claim about deployment.

In human spaceflight, NASA's systems-engineering guidance calls for human factors, operations, and safety to be considered concurrently with other design work. Its task analysis helps identify requirements gaps and informs evaluation and verification. That sector-specific practice offers a precedent for examining dependencies across disciplines.

This internal exercise serves a different purpose from Everything Design's B2B website-chart framework, which focuses on a reader's decision. It also differs from Everything Deep Tech's positioning-alignment check, which compares how people describe the product, buyer, and value. The evidence map tests what each function can substantiate before anyone selects a story to tell externally.

How do you tell technical proof apart from commercial, manufacturing, and regulatory readiness in a single view?

Attach test conditions, scope, and an owner to every claim in the shared evidence view. A performance result should identify the prototype, what you measured, and the conditions under which you measured it. Put the test record beside the claim, and mark any claim about production or field use as unverified until you have tested it.

Technology readiness levels describe stages of technical maturity, but they do not establish whether customers will buy a product or whether a company can deliver it. The US Department of Energy's adoption-readiness categories offer a separate way to examine barriers to adoption. Value proposition asks whether the product meets a need at an acceptable price. Market acceptance concerns demand and stakeholder participation. Resource maturity covers the inputs needed to produce and deliver it, while licence to operate covers barriers to deployment. The DOE developed these categories for energy technologies, so use them as prompts rather than a universal checklist.

According to the Department of Energy, its adoption-readiness framework examines 17 dimensions across four risk categories. Those categories help separate commercial questions from technical maturity. They do not certify a product or replace the requirements of its sector.

A readiness label compresses several judgements. Keep those judgements available beside the label. NASA's technology-readiness table separates laboratory validation from later demonstrations in relevant environments. Use the framework appropriate to your programme, and record who assessed it.

A buyer may accept the laboratory result and still need evidence that the device works during routine operation. A manufacturing partner may need a repeatable production process before committing capacity. Keeping those questions visible prevents one proven result from standing in for several decisions you have yet to make.

What does a worked example of this mapping look like?

To assess whether a prototype is ready for a pilot, map what the prototype has demonstrated against the conditions the buyer expects and the evidence needed to produce working units. Consider an illustrative sensor example, not a real client case. A bench test shows that one prototype meets an accuracy target at a fixed temperature. The buyer needs sensors to work across changing temperatures, and the manufacturing yield remains unverified.

The following evidence map is an illustrative sensor scenario, not a client result.

The evidence map would connect three claims.

• The research lead marks the accuracy result as demonstrated only under the recorded bench conditions. The map includes the test method, number of runs, and observed variation.
• The manufacturing lead marks repeatable production as unverified. A working prototype does not show how many units made through the intended process will meet the same specification.
• The commercial lead records the buyer's operating conditions and proposed acceptance criteria. If the buyer has not agreed on an acceptable failure rate, the map leaves that criterion open.

The unresolved question is whether units made through the intended process will meet the buyer's accuracy requirement across the operating range. A useful next test would produce a small batch, measure its yield, and test the conforming units under the buyer's conditions. Until that evidence exists, the map supports a claim about bench performance. It cannot establish that the sensor is ready for a pilot.

When do you reach for a diagram, an evidence map, a data view, or motion?

Use the question below to select a visual before commissioning production.

Choose the visual form by the disagreement you need to resolve internally, rather than by the audience for a future pitch. Use a diagram when research and engineering describe the mechanism differently. Draw components, interfaces, and dependencies, then mark which connections have been tested and which remain proposed. A diagram of a working component should not portray an integrated product that has yet to be tested.

Use an evidence map when people disagree about what has been proved. Put each proposed claim beside its supporting test, test conditions, owner, and outstanding validation. A lab result may support a performance claim under controlled conditions while leaving manufacturing repeatability or the buyer's operating environment untested. The map keeps those limits visible when you decide what to claim externally.

Use a data view when measured variation matters more than a single result. Plot individual runs or a distribution rather than only an average. Show units, sample size, and test conditions, along with error bars when the data support them. If repeated trials meet a target only under some conditions, the view helps you choose the next test without treating the average as proof of reliable operation.

Use motion when you need to examine a sequence whose underlying relationships have already been checked. A rough sequence study can expose a mistaken assumption about an operating cycle before you commission animation. Polished motion can make untested interfaces look like a mature integrated system. Everything Deep Tech's explainer-video process places technical review before animation so engineers can correct statements that are untrue, imprecise, or misleading while changes remain easier to make.

How do you build and review an evidence map in six steps?

Build an evidence map by linking each claim to a record, an owner and the decision it supports. A spreadsheet or shared document is enough for the first review.

1. Choose one decision. For a pilot, write down what the buyer must establish before agreeing to evaluate the product.
2. List the claims needed for that decision. Give each claim its own row so technical performance cannot stand in for manufacturing readiness.
3. Attach the source records. Include units, sample size, test conditions and the product version where they apply.
4. Mark each claim as demonstrated within stated conditions, unverified or contradicted by current evidence. Keep missing data visible.
5. Ask the responsible owners to review the rows. Record disagreements and the next test instead of averaging their opinions into one readiness score.
6. Approve the external subset. Record the review date and revisit the affected rows whenever evidence, requirements or the product changes.

For pilots, the UK government's pilot-to-production checklist recommends measurable success criteria and a plan for capturing results. It was written for space companies. Apply its planning questions to your own context and agree the actual criteria with the buyer.

When a test becomes a milestone, use the approved rows to prepare the milestone communication kit. A change in the evidence should reach the deck, website and film brief through the same record.

Who should own this exercise, and what happens after it's done?

Before you adapt a claim for an investor, buyer, regulator, or partner, the person responsible for it should confirm its evidence and limits. A research lead can confirm what a test measured, while an engineering lead checks the operating conditions. Manufacturing and regulatory owners should identify what remains unverified in their areas. A founder or product lead can maintain the shared map, but should not settle a technical disagreement on another owner's behalf.

When owners disagree, record the open question and the test or decision needed to resolve it. For example, measured prototype performance should retain its test conditions. It should not become a claim about repeatable production if manufacturing yield remains unverified. A visual makes that boundary visible, but it cannot supply the missing validation.

Once the owners agree on what the evidence supports, use an internal positioning alignment check to decide which claims should shape product priorities, target buyers, and sales qualification. Then adapt only the supported subset for each audience's decisions. Keep unresolved assumptions in the internal map and the next validation plan, rather than presenting them as established results.

How should the evidence shape your external story?

Use the claims and limits confirmed by their owners to decide what a pitch, website, or film can say. A lab result may support a performance claim while leaving manufacturing yield or buyer adoption untested. If those questions matter to an investor or buyer, state what remains unverified and what evidence you plan to gather next.

Book a 30-minute audit →