In too many deep-tech decks, slide 12 explains the physics and slide 38 finally names the buyer.
By then, the room has stopped thinking commercially.
The invention can be real. The patents can be filed. The prototype can work in a controlled environment. None of that tells a buyer why they should put it into a live operation with a budget, a procurement team and somebody's reputation attached.
Deep tech does not move from laboratory to market through a SaaS funnel. It moves through proof, translation, pilots, procurement and a series of decisions that make the risk feel smaller.
The first sale is a risk-transfer exercise.
The buyer is deciding whether enough uncertainty has moved from their side of the table to yours.
Technical readiness is one track
NASA's Technology Readiness Levels run from basic principles at TRL 1 to a system proven in operations at TRL 9. It is a useful discipline because it forces a team to say what has actually been demonstrated, in which environment and against which exit criteria.
There is a commercial trap inside it.
A product can move up the technical scale without moving closer to a purchase order. The system works. The target use case is still vague. The user likes it. The economic buyer cannot fund it. The pilot proves performance and teaches the procurement team that integration will take a year.
Technical readiness and commercial readiness need separate stage gates.
| Question | Technical gate | Commercial gate | | Does it work? | Performance demonstrated in the relevant environment | Buyer accepts the proof as relevant | | Can it deploy? | Interfaces, reliability and support are defined | Integration owner and budget exist | | Can it be bought? | Product configuration is stable enough to quote | Procurement route, risk owner and commercial terms are known | | Can it repeat? | Delivery can be reproduced | A second buyer can follow the same route |
NASA can tell you what the technology has proved. It cannot choose the first customer.
Pick the first use case, not the biggest market
Deep-tech founders are trained to see the full possibility of the science. That is valuable in the lab and dangerous in the first sales meeting.
A new sensing system might work in healthcare, industrial safety, defence, logistics and consumer electronics. Putting all five on the homepage does not make the company look large. It makes the company look undecided.
The first use case should score well against six questions:
- Is the problem expensive enough to have a budget?
- Can the buyer feel the problem now?
- Can the technology prove value inside a bounded pilot?
- Is the regulatory and integration path understood?
- Can one credible customer create proof for the next?
- Can the company serve this use case with the team and capital it has?
The largest theoretical market often loses this test. A smaller use case with a named buyer, a visible cost and a short proof loop can create the commercial evidence that opens the larger one later.
NSF's I-Corps programme is built around this gap. It sends technical teams out of the lab to test commercial hypotheses through customer discovery. Its full Teams curriculum expects at least 100 face-to-face interviews with potential customers and partners.
That number makes founders uncomfortable.
Good. Ten friendly conversations are enough to polish a story. One hundred conversations are enough to kill the wrong one.
Map the whole buying system
Deep tech rarely has one buyer.
There is a user who touches the product. A technical evaluator who decides whether the claims hold. An economic buyer who owns the result. Procurement checks terms and supplier risk. Security examines data and access. Legal examines liability. A regulator may sit outside the company and still decide the pace. Investors care because pilots become the proof behind the next round.
Write every role down before building the message.
| Role | Question they need answered | Proof they trust | | User | Will this make the work better? | Demonstration, workflow and peer reference | | Technical evaluator | Does it perform under our conditions? | Test protocol, data and access to the technical team | | Economic buyer | Is the outcome worth the cost and disruption? | Business case, pilot result and implementation plan | | Procurement | Can we buy from this company safely? | Terms, insurance, security, support and supplier evidence | | Regulator or compliance lead | Is the claim and use permitted? | Validation, documentation and review path | | Investor | Can this become a repeatable company? | Customer signal, paid pilots and movement through stage gates |
One message cannot do all six jobs.
The category story can stay consistent. The proof must change with the person reading it.
Claims need an evidence hierarchy
Technical founders usually write too much because they are scared of leaving out the bit that proves they are right.
The answer is not to simplify the science until it becomes meaningless. Build a hierarchy.
Start with the claim a buyer can repeat. Follow it with the measured outcome. Then show the test conditions, method and limitation. Put the deep technical material where the evaluator can inspect it without forcing every reader through it.
The hierarchy looks like this:
- commercial claim;
- measured result;
- use conditions;
- test method;
- evidence source;
- limitation;
- technical appendix.
This matters even more in medical, defence, energy and other regulated categories. In January 2026, the UK Regulatory Innovation Office opened a Front Door pilot specifically to collect regulatory barriers from science and technology businesses. Regulation is part of the route to market. It should appear in the plan before launch copy goes to legal.
Design the pilot backwards
Founders often treat a pilot as access to a customer.
That is too loose.
A pilot is a commercial experiment with a decision attached. Start with the decision the buyer will make when it ends. Then define the proof required for that decision.
Every pilot should name:
- the operational problem;
- the current baseline;
- the metric expected to move;
- the environment and users involved;
- the data both sides can access;
- the integration work;
- the risk owner;
- the start and end date;
- the decision meeting;
- the paid contract, expansion or stop condition that follows.
Free pilots are easy to start because nobody has to defend the spend. They are hard to convert for the same reason.
Price the work when the customer can pay. If the first pilot has to be subsidised, put a commercial value on it and agree the conversion route before the team begins.
Build a category story around the buyer's change
The science explains why the product can exist.
The category explains why the market needs to change.
A useful deep-tech narrative answers four things in order:
- What changed in the world or the underlying technology?
- Why does the old way now create an unacceptable cost or constraint?
- What becomes possible because this company exists?
- What evidence proves the claim today?
This story has to hold across the website, investor deck, pilot proposal, founder interview and product launch. Each version can change depth. The centre cannot keep moving.
At Blazon, the Pillo Health work is a useful example. The product sat across robotics, health, medication adherence, voice interaction and regulated delivery. The commercial story had to speak to consumers, healthcare stakeholders, press and a future acquirer without turning into five unrelated brands.
PR should arrive after the proof architecture
A funding announcement creates attention. It does not create a market position by itself.
Use PR at moments when the company has something that changes how an external audience should understand it:
- a financing round tied to the next commercial stage;
- a validated technical milestone;
- a named pilot or customer result;
- regulatory progress;
- a product launch;
- a partnership that changes distribution or credibility.
The founder should explain the category repeatedly between those moments. Technical essays, conference appearances, buyer briefings and analyst conversations create memory. A press hit can start the signal. Repetition makes the company own it.
Account-based demand starts narrow
A paid social campaign cannot rescue a list of accounts that nobody has chosen.
Start with 20 to 50 organisations that share the first use case. Map the likely user, evaluator, buyer and blocker inside each one. Build content around the objections that appear in real discovery and pilot conversations.
The first demand programme might include:
- a technical briefing for evaluators;
- an economic case for budget owners;
- a short pilot design for operational teams;
- a founder point of view for the category;
- one customer or test result;
- direct outreach linked to a specific operating problem;
- trade media and events where those accounts already pay attention.
This is patient pipeline creation. The number of marketing-qualified leads is less useful than movement from unknown account to technical review, pilot design and commercial decision.
A 12-month stage-gate plan
| Period | Work | Exit gate | | Months 1 and 2 | First-use-case scoring, 30 to 50 discovery conversations, buying-system map | One defined problem, buyer and commercial hypothesis | | Months 3 and 4 | Evidence hierarchy, positioning, category story, pilot offer and account list | Claims approved and pilot decision designed | | Months 5 and 6 | Technical content, website, founder narrative, procurement pack and pilot outreach | Target accounts enter evaluation and pilot design | | Months 7 and 8 | First pilots, funding or product announcement, trade PR and account follow-up | Measured pilot data and named conversion decision | | Months 9 and 10 | Convert the first pilot, publish approved proof and refine implementation | First revenue or a documented reason to change route | | Months 11 and 12 | Repeat with the next accounts, train sales, tighten pricing and delivery | A second buyer can follow a recognisable path |
Every gate can stop the plan.
That is what makes it useful.
The European Innovation Council separates research, transition, market readiness, commercialisation and scale-up across different funding routes. Founders should apply the same discipline to their operating plan. Capital can help a company cross a gate. It cannot remove the gate.
The first revenue is rarely the moment the market suddenly understands the science. It is the moment one buyer has seen enough proof to carry the remaining risk.
Who carries it next?
Compare the delivery models in How to Choose a Deep Tech Agency, inspect the published Pillo Health launch case, or see Blazon's deep-tech service.
If the technology is ready and the market story is still moving, bring Blazon the technical deck. We will map the first use case, buying system, evidence gaps and route from pilot to launch.