Technology Readiness Level and Investment Readiness Level Deconstructed

INNOVATION

What is Technology Readiness Level (TRL)

TRL was cre­ated by NASA, and it works best when ap­plied to phys­i­cal prod­ucts. Although the prin­ci­ples be­hind TRL are broadly ap­plic­a­ble, the specifics of the in­di­vid­ual lev­els match poorly with soft­ware-based prod­ucts and ser­vices.

TRL 1Basic prin­ci­ples ob­served and re­portedThis is the low­est “level” of tech­nol­ogy ma­tu­rity. At this level, sci­en­tific re­search be­gins to be trans­lated into ap­plied re­search and de­vel­op­ment.
TRL 2Technology con­cept and/​or ap­pli­ca­tion for­mu­latedAt this level, the ap­pli­ca­tion is still spec­u­la­tive, but spe­cific ap­pli­ca­tions are be­ing con­sid­ered in aca­d­e­mic pa­pers.
TRL 3Analytical and ex­per­i­men­tal crit­i­cal func­tion and/​or char­ac­ter­is­tic proof of con­ceptAt this step, ac­tive re­search and de­vel­op­ment is ini­ti­ated. This must in­clude both an­a­lyt­i­cal stud­ies to set the tech­nol­ogy into an ap­pro­pri­ate con­text and lab­o­ra­tory-based stud­ies to phys­i­cally val­i­date that the an­a­lyt­i­cal pre­dic­tions are cor­rect.
TRL 4Component and/​or bread­board val­i­da­tion in lab­o­ra­tory en­vi­ron­mentNext, ba­sic tech­no­log­i­cal el­e­ments must be in­te­grated to es­tab­lish that the “pieces” will work to­gether to achieve con­cept-en­abling lev­els of per­for­mance.
TRL 5Component and/​or bread­board val­i­da­tion in rel­e­vant en­vi­ron­mentAt this level, the fi­delity of the com­po­nent and/​or bread­board be­ing tested is in­creased. The ba­sic tech­no­log­i­cal el­e­ments must be in­te­grated with rea­son­ably re­al­is­tic sup­port­ing el­e­ments so that the to­tal ap­pli­ca­tions (component-level, sub-sys­tem level, or sys­tem-level) can be tested in a ‘simulated’ or some­what re­al­is­tic en­vi­ron­ment.
TRL 6System/subsystem model or pro­to­type demon­stra­tion in a rel­e­vant en­vi­ron­mentThis stage re­quires that the fi­delity of the com­po­nent and/​or bread­board be­ing tested is again in­creased.
TRL 7System pro­to­type demon­stra­tion in an op­er­a­tional en­vi­ron­mentTRL 7 is a sig­nif­i­cant step be­yond TRL 6, re­quir­ing an ac­tual sys­tem pro­to­type demon­stra­tion in a space en­vi­ron­ment. The pro­to­type should be near or at the scale of the planned op­er­a­tional sys­tem.
TRL 8Actual sys­tem com­pleted and qual­i­fied through test and demon­stra­tionIn al­most all cases, this level is the end of true ‘system de­vel­op­ment’. This stage might in­clude in­te­gra­tion of new tech­nol­ogy into an ex­ist­ing sys­tem.
TRL 9Actual sys­tem proven through suc­cess­ful mis­sion op­er­a­tionsThis rep­re­sents the end of the last ‘bug fix­ing’ as­pects of true ‘system de­vel­op­ment’. This TRL does not in­clude planned prod­uct im­prove­ment of on­go­ing or reusable sys­tems.

Image

What is Investment Readiness Level (IRL)

IRL was cre­ated by Steve Blank to be to star­tups as TRL is to NASA. It works in a range of ver­ti­cals and con­texts, in­clud­ing soft­ware-based prod­ucts and ser­vices, which is TRL’s weak point.

IRL 1First pass can­vasThis is the low­est “level” of in­vest­ment ma­tu­rity. At this level, a rough out­line of a busi­ness model has been put to pa­per, but it’s mostly un­val­i­dated as­sump­tions.
IRL 2Market size/​com­pet­i­tive analy­sisOnce a rough busi­ness model in place, the next most im­por­tant an­cil­lary step is mar­ket re­search. It’s im­por­tant to know what the mar­ket looks like and who your po­ten­tial com­peti­tors are.
IRL 3Problem/solution val­i­da­tionNow that you have com­pleted your mar­ket re­search, the next step is to be­gin val­i­dat­ing that there’s a prob­lem and that your busi­ness plan aligns with pos­si­ble so­lu­tions to that prob­lem. Based on the prob­lem dri­ven ap­proach to soft­ware de­vel­op­ment, we adapted the Lean UX Canvas which pro­vides a frame­work for doc­u­ment­ing the prob­lem state­ment along with other con­sid­er­a­tions.
IRL 4Low fi­delity MVPOnce you have val­i­dated your so­lu­tion in the­ory, it’s time to be­gin val­i­dat­ing it in prac­tice. Do this with a low fi­delity MVP to con­serve re­sources.
IRL 5Product/market fitBuilding on the pre­vi­ous steps, next you need to val­i­date that your of­fer­ing rep­re­sents the best way to solve the prob­lem(s) ex­pe­ri­enced by your mar­ket. This is where you ham­mer down what your UVPs are and val­i­date that they ac­tu­ally mat­ter to your mar­ket.
IRL 6Validate right-side of can­vasIt’s time to val­i­date the left-side of your busi­ness model can­vas (customers, re­la­tion­ships, cus­tomer seg­ments, chan­nels, rev­enue streams). Some of this will have been com­pleted dur­ing pre­vi­ous steps.
IRL 7High fi­delity MVPNow that you have a good idea about your prod­uct/​mar­ket fit, it’s time to be­gin val­i­dat­ing your idea in earnest. Do this with a high fi­delity MVP to max­imise your in­vest­ment readi­ness and prove your tech­nol­ogy.
IRL 8Validate left-side of can­vasIt’s time to val­i­date the right-side of your busi­ness model can­vas (key part­ners, key ac­tiv­i­ties, key re­sources, cost struc­ture). Some of this will have been com­pleted dur­ing pre­vi­ous steps.
IRL 9Metrics that mat­terOnce you have a val­i­dated busi­ness model and prod­uct, the next step is plan­ning your growth. Key to this is iden­ti­fy­ing the met­rics that mat­ter (e.g. rev­enue, sales, so­cial me­dia clout).

Whereas TRL is too spe­cific to be di­rectly ap­plied to all or­gan­i­sa­tions, IRL can be ac­cused of be­ing the op­po­site; too gen­eral. So which is bet­ter? Technology Readiness Level or Investment Readiness Level?

TRL vs. IRL

Broadly speak­ing, TRL and IRL have the same pur­pose and cover much of the same ground, but there are some im­por­tant di­ver­gences. For ex­am­ple, TRL is very yes/​no ori­ented. An ex­am­ple of this is TRL 4 which is es­sen­tially ask­ing ‘does it work in a lab?’. On the other hand, IRL is highly sub­jec­tive. For in­stance, IRL 2 re­quires that you have com­pleted a mar­ket size and com­pet­i­tive analy­sis, which is a more open ended mile­stone.

This sub­jec­tive­ness makes it less clear how to ac­tion the IRL process. Some ideas are so niche or dis­rup­tive that mar­ket re­search and com­peti­tor analy­sis is quick and easy. Some ideas, how­ever, such as those in the bank­ing and in­sur­ance sec­tors, re­quire ex­ten­sive un­der­stand­ing of au­di­ences and reg­u­la­tions. The IRL cheat sheet does­n’t say what your mar­ket size/​com­peti­tor analy­sis should look like, only that you com­plete one.

UQ busi­ness lec­turer TIm Kastelle made this table aim­ing to con­vert each level in the IRL model into dis­tinct, bite-sized ac­tion­ables:

Image

In the case of mar­ket size/​com­peti­tor analy­sis, the ac­tion­ables in­clude a de­tailed map of to­tal ad­dress­able mar­ket di­vided in sub­sec­tions, an es­ti­mated re­turn based on to­tal mar­ket value and ex­pected mar­ket share and a petal di­a­gram of com­peti­tors.

Kastelle’s cheat sheet goes a long way to­wards de­mys­ti­fy­ing the rel­a­tively broad lev­els in Steve Blank’s IRL model. Conversely, TRL is more eas­ily bro­ken down.

In a nut­shell, TRL 1, 2 and 3 can be ap­plied to ideas in the­ory and TRL 4 and on­wards ap­ply to ideas in prac­tice. In each case, new mile­stones are pro­gres­sively achieved. For ex­am­ple, to be at TRL 1, all that is re­quired is the the­ory (e.g. maths) un­der­pin­ning your idea is valid. Let’s un­pack this.

Imagine your idea is a trans­par­ent alu­minium wind­shield (like in Star Trek) to go on a new NASA space shut­tle. Step 1 would be check­ing peer-re­viewed pa­pers to see if the ba­sics/​gen­eral prin­ci­ples of this idea are within the reach of con­tem­po­rary sci­ence. In this ex­am­ple, the ques­tions that may need to be an­swered in­clude: what is trans­par­ent alu­mini­um’s melt­ing and freez­ing points?

It’s only once these ques­tions are an­swered that you should progress to the next step, which is a deeper ex­plo­ration of the topic of trans­par­ent alu­minium wind­shields.

This process of grad­ual pro­gres­sion in the­ory and then in prac­tice is not mir­rored in IRL, where you be­gin with a ba­sic busi­ness model that is pro­gres­sively ex­panded and val­i­dated piece­meal. For ex­am­ple, in IRL 2 you ex­plore your mar­ket’s land­scape and in IRL 3 you ex­plore how your idea could solve a prob­lem. These are re­lated, but not di­rectly.

Another point of dis­tinc­tion is that it is only at IRL 4 and 7 that the ex­e­cu­tion of your idea is ac­tu­ally re­quired.

Despite this, how­ever, each sys­tem is built upon the idea that it’s bet­ter to val­i­date ideas as early as pos­si­ble. Will this work in cold tem­per­a­tures of space? Cool it in a lab and see. Can we use this unique nav­i­ga­tion method in our app? Create a pa­per mock-up of your app and test the idea be­fore writ­ing a sin­gle line of code.

It’s pos­si­ble that some of the steps in the TRL and IRL mod­els will be ir­rel­e­vant to your idea; how­ever, their value is less in cre­at­ing strict rules and more in em­pow­er­ing you and your idea with best prac­tices that help you to un­der­stand where your idea stands in terms of in­vest­ment and tech­nol­ogy readi­ness.

The Problem with App Development

When it comes to app de­vel­op­ment, TRL is too un­apolo­get­i­cally hard­ware-fo­cused and IRL is too vague. It at­tempts to be ap­plic­a­ble to all ideas and, as a re­sult, is not well-suited to the re­al­i­ties of app de­vel­op­ment.

The ba­sic prob­lem with app de­vel­op­ment is that the path you take to your MVP is rarely the one you ini­tially en­vis­age, nor is it some­thing you walk alone. Almost all app de­vel­op­ment is out­sourced. This, along with dif­fi­culty of adapt­ing code to align with emerg­ing ideas and changes to your busi­ness model, war­rants a do­main-spe­cific readi­ness level model.

Luckily, we have de­vel­oped such a model: WorkingMouse’s Brief process helps guide app de­vel­op­ers and their part­ners when plan­ning, build­ing and de­ploy­ing apps.

Discover Software
Secrets

ABOUT THE AUTHOR

David Burkett

Growth en­thu­si­ast and res­i­dent pom

Get cu­rated con­tent on soft­ware de­vel­op­ment, straight to your in­box.

Your vi­sion,

our ex­per­tise

Book a con­sul­ta­tion