Exploring Technology
A new technology only becomes interesting once you know what it can do today, what it might do tomorrow and who would pay for it. This article shows how a project team explores a technology through desk research, expert interviews, use cases and feasibility experiments, and how to rate its maturity with the Technology Readiness Level (TRL).
Bernhard Doll
Business Design Maverick
Sabine Schoen
Team Coach
1. Purpose
Exploring a technology gives your team a sober picture of what a new technology can really do, how mature it is and where it creates value for your organisation. You need it whenever a playground has a technological focus: new sensors, new materials, new AI models, new sources of energy supply (see Exploring Playgrounds). The result is a technology assessment that the team can defend in front of the Project Sponsor.
Be aware that a technology on its own is not an opportunity. It becomes one once you know which job it does better (see Business Model), cheaper or faster than today's solutions, and for whom. That's why exploring a technology always runs alongside Exploring Customers. Otherwise your team ends up with a solution in search of a problem.
Four activities answer four questions:
Desk research: What is the technology, how does it work and who is ahead?
Expert interviews: What do people who work with the technology every day know that no paper tells you?
Use cases: Where does the technology create value, and for whom?
Feasibility experiments: Does it work under our conditions, and how mature is it really?
How much of each you do depends on the scope you set in Step 1: Setup and write into the Project Charter "Exploration". With a scanning scope, desk research and a handful of expert interviews give you a first orientation. A deep dive works through all four activities and ends in a solid technology assessment, including a TRL rating for every promising use case.
2. Desk Research
Desk research is where every technology exploration starts. The goal is a technology profile that a non-expert understands in five minutes. Collect the following:
Working principle: How does the technology work, in plain words? If your team can't explain it to the sponsor in three sentences, it hasn't understood it yet.
Performance parameters: The few numbers that decide whether the technology is any good for you — accuracy, range, energy consumption, throughput, cost per unit. Note the source and the reference year for every figure.
Limitations: What the technology can't do (yet), and why. Physics, cost, regulation and missing standards are the usual suspects.
Key players: Universities and research institutes, start-ups, established suppliers and early adopters in other industries. This list is also your source for expert interviews.
Trajectory: How performance and cost have developed over recent years, and what the key players expect for the next three to five years.
Good sources are patent databases, scientific publications, research funding programmes, start-up databases, conference proceedings, standards and technical datasheets. Analyst reports and the trade press help with the overview, but they love superlatives. Read them with a can of Anti-Bullsh*t Spray at hand.
AI
AI speeds up desk research considerably: it summarises papers and patents in minutes and helps you draw up the first list of key players. Check every figure against its original source before it goes into the technology profile. Prompts for exploration projects are in the AI Library "Exploration".
3. Expert Interviews
Desk research tells you what has been published. Expert interviews tell you what has not: what really works in practice, where projects failed and which numbers in the datasheets are marketing. Talk to four kinds of experts:
Researchers: People at universities and research institutes who know the state of the art and the next breakthroughs.
Technology providers: Start-ups and established suppliers who build and sell the technology.
Early adopters: Companies in other industries that already use the technology and know its everyday problems.
Internal experts: Colleagues from R&D, production or IT who know your own systems, data and constraints.
Be careful with technology providers. They know their technology best, and they want to sell it. Cross-check their claims with at least one researcher and one early adopter. For a T-shaped scope or a deep dive, plan eight to twelve expert interviews. For a scanning scope, three to five are enough.
The interview technique is the same as with customers: open questions, no leading questions, listen more than you talk (see Customer & User Interview). Questions that work well with experts:
What can the technology do today, and under which conditions?
Where have you seen it fail, and why?
Which parameter improves fastest, and which one doesn't move at all?
If you had our problem, would you use this technology? What would you use instead?
Who else should we talk to?
Document each interview on the same day and cluster the findings in the Insights Matrix, together with the results from customer research.
4. Developing Use Cases
A use case describes one concrete application of the technology: who uses it, for which job and what the technology does better than today's solution. Use cases are the bridge from technology to business. Without them, the Consolidation Workshop ends with a technology report and no ideas.
Describe every use case along five questions:
Customer or user: Who benefits? Name the segment, not "everyone".
Job(s) to get done: Which task, problem or need does the technology address?
Today's solution: How does the customer get the job done today, and what does it cost?
Advantage: What does the technology do better, and by how much? "Faster" is not an answer, "from two days to two hours" is.
Technical requirements: What must the technology deliver for this use case to work? These requirements are the yardstick for your feasibility experiments.
Imagine your team explores printed electronics. One use case: logistics providers stick printed temperature sensors onto pharmaceutical shipments instead of putting a data logger into every box. The job is proof of an unbroken cold chain. The advantage is cost — a few cents per sensor instead of several euros per logger. The technical requirement: the sensor measures to ±0.5 °C and survives 30 days in transit.
Collect use cases from all sources — desk research, expert interviews and customer research — and keep the list open until the Review Workshop. There, pick the three to five most promising ones for feasibility experiments. Check every use case with real customers or users before you invest in experiments (see Exploring Customers).
5. Technology Readiness Level
The Technology Readiness Level (TRL) is a scale from 1 to 9 that rates how mature a technology is, from the first scientific idea to a system in everyday operation. It was developed at NASA and is used today by the European Commission, research funding programmes and many R&D departments. That makes it a common language with researchers and technology providers. The European Commission defines the levels as follows:
TRL 1: Basic principles observed
TRL 2: Technology concept formulated
TRL 3: Experimental proof of concept
TRL 4: Technology validated in lab
TRL 5: Technology validated in relevant environment
TRL 6: Technology demonstrated in relevant environment
TRL 7: System prototype demonstration in operational environment
TRL 8: System complete and qualified
TRL 9: Actual system proven in operational environment
In practice, three bands are enough for most conversations: TRL 1 to 3 is research, TRL 4 to 6 is development, TRL 7 to 9 is ready for the market.
Be aware that a TRL always refers to an application and an environment. A technology at TRL 9 in consumer electronics can be at TRL 4 in your use case, because it has never run at minus 30 °C, in a dusty production hall or with your data. Rate the TRL for every use case separately and write down the evidence behind each rating.
The TRL also tells you what an exploration can deliver and what it can't. Below TRL 4, you are looking at a research topic: partner with a research institute and expect years, not weeks. From TRL 4 to TRL 6, feasibility experiments within a six-week exploration make sense. From TRL 7 upwards, the technical question is largely answered, and the open questions sit with customers, business model and organisation.
6. Feasibility Experiments
Desk research and expert interviews tell you what others have seen. A feasibility experiment shows your team what the technology does under your conditions. It answers one open question about one use case. Phrase it the way we phrase every open question:
We don't know whether a printed temperature sensor still measures to ±0.5 °C after 30 days in a shipping box.
Typical feasibility experiments, from cheap to expensive:
Hands-on test: Buy a development kit or a sample and try it out yourself. Often done in a day, and it ends many debates.
Vendor demo with your data: Ask a technology provider to run the technology on your material, data or samples — not on their showcase.
Lab set-up: Build a minimal set-up together with a research partner or your own R&D, and measure the technical requirements from the use case.
Field test: Run a first prototype in the real environment for a few days, for example on one machine or one delivery route.
Before you start, write down what you measure and which result is good enough. Derive both from the technical requirements of the use case. Otherwise every result looks like a success. Afterwards, rate the TRL for the use case again: a successful lab set-up can lift it from TRL 3 to TRL 4, a successful field test from TRL 5 to TRL 6.
Bring in a Prototyping Expert early. They know how to build the simplest set-up that answers the question (see Prototyping).
Keep in mind
Feasibility experiments in an exploration answer open questions about the technology. They don't validate a business model. Hypotheses about customers, prices and willingness to pay are tested later, in Phase IV (see Hypotheses & Experiments). Be careful with the word "validate", even where the TRL definitions use it.
7. Participants
8. Tools & Materials
See Tools & Methods for Phase II for an overview
9. Instructions for Coaches
Technology explorations attract enthusiasts. That's good for energy and bad for judgement. Your most important job is to keep the team honest: every use case names a customer, every figure has a source and every TRL rating has evidence behind it.
Watch out for three traps:
Solution in search of a problem: The team falls in love with the technology and forgets to ask who needs it. Push for customer contact from week one.
Vendor capture: One provider becomes the team's main source of truth. Insist on independent voices for every key claim.
Building instead of exploring: Engineers on the team want to build a full prototype. Keep experiments as small as the open question allows — the six weeks are fixed.
Prepare the results so that the Consolidation Workshop can work with them: one page for the technology profile, and one page per use case with its TRL rating and the evidence behind it. That's what the team needs to develop ideas in the Ideation Workshop.
10. Q & A
Do we need customers at all when the focus is technological? Yes. A technology without a customer is a hobby. Every use case names a customer and a job, and only real customers can tell you whether that job matters. If technology is the deep research area of a T-shaped scope, a few interviews per promising use case are enough (see Exploring Customers). Talk to customers before you invest in feasibility experiments, not afterwards.
What if the technology is still at TRL 2? Then six weeks won't give you a working set-up, and feasibility experiments make little sense. Change the question instead: who is working on the technology, how fast is it progressing and when could it reach TRL 6? The result can be a decision to watch the technology and look again in a year, or to start a research partnership. Both are legitimate results of an exploration. Tell the Project Sponsor early, so that nobody expects a prototype.
Readings