What is Technology Readiness Level (TRL)
TRL was created by NASA, and it works best when applied to physical products. Although the principles behind TRL are broadly applicable, the specifics of the individual levels match poorly with software-based products and services.
|Basic principles observed and reported
|This is the lowest "level" of technology maturity. At this level, scientific research begins to be translated into applied research and development.
|Technology concept and/or application formulated
|At this level, the application is still speculative, but specific applications are being considered in academic papers.
|Analytical and experimental critical function and/or characteristic proof of concept
|At this step, active research and development is initiated. This must include both analytical studies to set the technology into an appropriate context and laboratory-based studies to physically validate that the analytical predictions are correct.
|Component and/or breadboard validation in laboratory environment
|Next, basic technological elements must be integrated to establish that the "pieces" will work together to achieve concept-enabling levels of performance.
|Component and/or breadboard validation in relevant environment
|At this level, the fidelity of the component and/or breadboard being tested is increased. The basic technological elements must be integrated with reasonably realistic supporting elements so that the total applications (component-level, sub-system level, or system-level) can be tested in a 'simulated' or somewhat realistic environment.
|System/subsystem model or prototype demonstration in a relevant environment
|This stage requires that the fidelity of the component and/or breadboard being tested is again increased.
|System prototype demonstration in an operational environment
|TRL 7 is a significant step beyond TRL 6, requiring an actual system prototype demonstration in a space environment. The prototype should be near or at the scale of the planned operational system.
|Actual system completed and qualified through test and demonstration
|In almost all cases, this level is the end of true 'system development'. This stage might include integration of new technology into an existing system.
|Actual system proven through successful mission operations
|This represents the end of the last 'bug fixing' aspects of true 'system development'. This TRL does not include planned product improvement of ongoing or reusable systems.
What is Investment Readiness Level (IRL)
IRL was created by Steve Blank to be to startups as TRL is to NASA. It works in a range of verticals and contexts, including software-based products and services, which is TRL's weak point.
|First pass canvas
|This is the lowest "level" of investment maturity. At this level, a rough outline of a business model has been put to paper, but it's mostly unvalidated assumptions.
|Market size/competitive analysis
|Once a rough business model in place, the next most important ancillary step is market research. It's important to know what the market looks like and who your potential competitors are.
|Now that you have completed your market research, the next step is to begin validating that there's a problem and that your business plan aligns with possible solutions to that problem. Based on the problem driven approach to software development, we adapted the Lean UX Canvas which provides a framework for documenting the problem statement along with other considerations.
|Low fidelity MVP
|Once you have validated your solution in theory, it's time to begin validating it in practice. Do this with a low fidelity MVP to conserve resources.
|Building on the previous steps, next you need to validate that your offering represents the best way to solve the problem(s) experienced by your market. This is where you hammer down what your UVPs are and validate that they actually matter to your market.
|Validate right-side of canvas
|It's time to validate the left-side of your business model canvas (customers, relationships, customer segments, channels, revenue streams). Some of this will have been completed during previous steps.
|High fidelity MVP
|Now that you have a good idea about your product/market fit, it's time to begin validating your idea in earnest. Do this with a high fidelity MVP to maximise your investment readiness and prove your technology.
|Validate left-side of canvas
|It's time to validate the right-side of your business model canvas (key partners, key activities, key resources, cost structure). Some of this will have been completed during previous steps.
|Metrics that matter
|Once you have a validated business model and product, the next step is planning your growth. Key to this is identifying the metrics that matter (e.g. revenue, sales, social media clout).
Whereas TRL is too specific to be directly applied to all organisations, IRL can be accused of being the opposite; too general. So which is better? Technology Readiness Level or Investment Readiness Level?
TRL vs. IRL
Broadly speaking, TRL and IRL have the same purpose and cover much of the same ground, but there are some important divergences. For example, TRL is very yes/no oriented. An example of this is TRL 4 which is essentially asking 'does it work in a lab?'. On the other hand, IRL is highly subjective. For instance, IRL 2 requires that you have completed a market size and competitive analysis, which is a more open ended milestone.
This subjectiveness makes it less clear how to action the IRL process. Some ideas are so niche or disruptive that market research and competitor analysis is quick and easy. Some ideas, however, such as those in the banking and insurance sectors, require extensive understanding of audiences and regulations. The IRL cheat sheet doesn't say what your market size/competitor analysis should look like, only that you complete one.
UQ business lecturer TIm Kastelle made this table aiming to convert each level in the IRL model into distinct, bite-sized actionables:
In the case of market size/competitor analysis, the actionables include a detailed map of total addressable market divided in subsections, an estimated return based on total market value and expected market share and a petal diagram of competitors.
Kastelle's cheat sheet goes a long way towards demystifying the relatively broad levels in Steve Blank's IRL model. Conversely, TRL is more easily broken down.
In a nutshell, TRL 1, 2 and 3 can be applied to ideas in theory and TRL 4 and onwards apply to ideas in practice. In each case, new milestones are progressively achieved. For example, to be at TRL 1, all that is required is the theory (e.g. maths) underpinning your idea is valid. Let's unpack this.
Imagine your idea is a transparent aluminium windshield (like in Star Trek) to go on a new NASA space shuttle. Step 1 would be checking peer-reviewed papers to see if the basics/general principles of this idea are within the reach of contemporary science. In this example, the questions that may need to be answered include: what is transparent aluminium's melting and freezing points?
It's only once these questions are answered that you should progress to the next step, which is a deeper exploration of the topic of transparent aluminium windshields.
This process of gradual progression in theory and then in practice is not mirrored in IRL, where you begin with a basic business model that is progressively expanded and validated piecemeal. For example, in IRL 2 you explore your market's landscape and in IRL 3 you explore how your idea could solve a problem. These are related, but not directly.
Another point of distinction is that it is only at IRL 4 and 7 that the execution of your idea is actually required.
Despite this, however, each system is built upon the idea that it's better to validate ideas as early as possible. Will this work in cold temperatures of space? Cool it in a lab and see. Can we use this unique navigation method in our app? Create a paper mock-up of your app and test the idea before writing a single line of code.
It's possible that some of the steps in the TRL and IRL models will be irrelevant to your idea; however, their value is less in creating strict rules and more in empowering you and your idea with best practices that help you to understand where your idea stands in terms of investment and technology readiness.
The Problem with App Development
When it comes to app development, TRL is too unapologetically hardware-focused and IRL is too vague. It attempts to be applicable to all ideas and, as a result, is not well-suited to the realities of app development.
The basic problem with app development is that the path you take to your MVP is rarely the one you initially envisage, nor is it something you walk alone. Almost all app development is outsourced. This, along with difficulty of adapting code to align with emerging ideas and changes to your business model, warrants a domain-specific readiness level model.
Luckily, we have developed such a model: WorkingMouse's Brief process helps guide app developers and their partners when planning, building and deploying apps.