Emerging technology horizon scanning: a method built on your own problems
Horizon scanning is the disciplined search for technologies that could matter to your organization before they are obvious. Done well, it starts from your own strategic questions, draws on signals with known strengths and weaknesses, scores candidates on the same rubric and ends in a short watch list with explicit review triggers. This guide sets out that method, the outputs it should produce and the biases that most often distort it.
On this page
- Why a trend report is a poor substitute for your own scan
- The horizon scanning method, from questions to watch list
- Signal sources for a technology scan and the bias each carries
- A five-factor rubric for scoring scan candidates
- Outputs: a watch list and one-page technology briefs
- Hypothetical watch-list entries across four frontier domains
- Biases that distort a horizon scan
- Cadence, ownership and how the scan feeds budgets
- Questions and answers
- Sources
Why a trend report is a poor substitute for your own scan
Published trend reports are useful reading, but they answer a different question from the one a leadership team has. They rank technologies by general attention, written for a broad audience, at a moment chosen by the publisher. Your question is narrower and more demanding: which developments could change the economics, risks or obligations of this particular business, and when would we need to act.
A report also cannot see your constraints. A technology that is years from general readiness may be close for a niche you operate in, and one that is everywhere in the press may be irrelevant to your processes. An internal scan that starts from your own problems keeps both errors visible. It also builds organizational memory, because the reasons a technology was dismissed are written down and can be revisited when circumstances change.
The horizon scanning method, from questions to watch list
Frame scanning questions from strategy
Turn each strategic concern into a question a scan can answer. "Could field service costs be cut?" becomes "which technologies could change how technicians diagnose and repair equipment in the next planning period?"
Choose signal sources per question
Match sources to the question: standards activity for interoperability concerns, regulatory consultations for compliance concerns, research and patents for capability concerns.
Collect and log signals
Record each signal with its source, date and the question it bears on. Keep weak and contradictory signals; they are often the most informative.
Cluster signals into candidates
Group related signals into candidate technologies or capabilities, described in terms of what they would let you do rather than by product names.
Score candidates on one rubric
Rate every candidate on the same factors, with a short evidence note per score so others can challenge it.
Write briefs and set triggers
For the few that matter, write a one-page brief and name the events that would move them up or down the list.
Review on a fixed cadence
Revisit the list on schedule and whenever a trigger fires, recording what changed and why.
Signal sources for a technology scan and the bias each carries
| Signal source | Good for | Watch out for |
|---|---|---|
| Standards bodies and working groups | Seeing which approaches the industry is converging on, and when interoperability will be possible | Long timelines; a draft standard can stall or split |
| Patent filings | Spotting who is investing in a capability and where commercial interest is concentrating | Filings show intent, not working products; many are defensive |
| Peer-reviewed research and preprints | Understanding what has actually been demonstrated and under what conditions | Lab conditions rarely match field conditions; preprints are unreviewed |
| Regulatory consultations and proposals | Anticipating obligations, bans or incentives before they apply | Proposals change between consultation and adoption |
| Open-source activity | Gauging developer adoption and whether tooling is maturing | Popularity is not production readiness; projects can be abandoned |
| Public procurement notices | Seeing which technologies buyers are prepared to pay for and specify | Tenders reflect a buyer's plans, which may not be delivered |
| Vendor announcements and analyst commentary | Learning what is being marketed and to whom | Optimism is built in; treat as a lead to verify, not as evidence |
No single source is reliable on its own. A candidate supported by signals from several independent rows deserves more weight than one supported by many signals from the same row.
A five-factor rubric for scoring scan candidates
Use a simple low, medium or high rating for each factor and write one sentence of evidence beside it. The evidence matters more than the rating.
- Relevance
- How directly the candidate bears on one of your scanning questions. High relevance means a named process, product or obligation would change.
- Maturity
- How far the technology has been demonstrated in conditions like yours. Rate from evidence; a structured readiness assessment can refine it later.
- Regulatory position
- Whether current or proposed rules enable, restrict or are silent on the use you have in mind, and how settled they are.
- Dependencies
- What else must be true: hardware availability, standards, data access, skills, partners or infrastructure you do not control.
- Time to impact
- When the candidate could plausibly affect your business, expressed against your planning horizon rather than in absolute years.
Outputs: a watch list and one-page technology briefs
The main output is a watch list: a short set of candidates, each with its scores, the evidence behind them, an owner and the triggers that would change its status. Triggers should be observable events, such as a standard reaching a defined stage, a regulation being adopted, a price threshold being crossed or a competitor announcing a deployment. A list without triggers tends to be reviewed only when someone remembers it.
For the candidates that matter most, a one-page brief explains what the technology would let the organization do, what the evidence shows today, the conventional alternative it would compete with and the decision it might eventually force. Briefs are written for executives who will not read the signal log.
A horizon scan deliberately does not decide which tools engineering teams may adopt. That governance, often run as a technology radar with adopt, trial, assess and hold rings, belongs to the technology capability. The scan feeds it: when a watched candidate becomes ready for general engineering use, it moves onto the radar.
Hypothetical watch-list entries across four frontier domains
Biases that distort a horizon scan
Novelty bias
Early signalNew candidates are scored higher than older ones with stronger evidence.
MitigationScore against the rubric's evidence notes, and have someone argue for the conventional alternative in each review.
Vendor-led signals
Early signalMost signals for a candidate trace back to suppliers selling it.
MitigationRequire at least one independent source type, such as research, standards or regulation, before a candidate moves up.
Sunk cost in earlier scans
Early signalCandidates stay on the list because they were championed before, despite weak new evidence.
MitigationMake removal a normal outcome and record why, so it is not a loss of face.
Recency and availability
Early signalScores move after a conference or news cycle without new evidence.
MitigationOnly change a score when the evidence note changes, and date every change.
Cadence, ownership and how the scan feeds budgets
Most organizations refresh the full scan on a planning cycle and review triggers continuously in between. A small core team, typically in a strategy, innovation or CTO office, owns the method and the log, while business owners own the scanning questions and the decisions they lead to.
The scan earns its place by feeding decisions. Candidates that become relevant and plausible move to a structured technology readiness level assessment and, where justified, a small experiment against a conventional baseline under the frontier technologies portfolio approach1. That link to budgets is what stops a scan from becoming an annual slide deck.
Questions and answers
How often should a horizon scan be refreshed?
Refresh the whole scan once per planning cycle, so its results can inform budgets, and review the watch list's triggers continuously. A trigger firing, such as a regulation being adopted or a standard being finalized, should prompt an immediate review of that entry rather than waiting for the next cycle.
Who should own the horizon scan?
A small team in strategy, innovation or the CTO office should own the method, the signal log and the watch list. Business leaders should own the scanning questions and the decisions that follow, because they control the budgets. Without that split, the scan either drifts from the business or becomes a set of pet projects.
How do we stop the scan becoming a slide deck nobody uses?
Tie every watch-list entry to an owner, a trigger and a decision it could lead to, and route candidates that become relevant into a readiness assessment or a funded experiment. Publish removals as well as additions. When people see the scan changing what gets funded, they start contributing signals to it.
How many technologies should be on the watch list?
Few enough that a leadership meeting can discuss each one properly, with briefs for the most important. A long list usually means candidates are not being removed. The signal log can be large; the watch list should be short, with clear reasons for every entry that stays.