Reworking TRL and IRL for App Development: Software Readiness Level
NASA’s Technology Readiness Level (TRL) and Steve Blank’s Investment Readiness Level (IRL) are great, usually…
However they are inappropriate for software-based products and services. TRL is too specific, it is unapologetically hardware-focused. Meanwhile, IRL is too general, as it tries to be applicable to everything.
But something is better than nothing right?
Developing a new product or service is hard enough, even Google gets it wrong, which is why you want your resources to be a little more than better than nothing.
Trying to apply TRL and/or IRL to your app’s development timeline probably is better than nothing; however, this does put you at risk prioritising the wrong milestones and tasks or missing unique steps that apply only to app development.
For example, TRL suggests that you should start by researching the basic principals of your idea in peer-reviewed papers. Yes, knowledge is power, but speed is of the essence. Reading back issues of Accounting Programs Quarterly will only help you so much. (Meanwhile, Xero’s YoY growth rate has been 100% or more since 2008!)
The problem is, as great as TRL and IRL usually are, they are inappropriate for software-based products and services, that is why we have reworked these existing models into a new model that is more aligned with the realities of app development.
The Software Readiness Level model
|1. Business model canvas||You’ve a rough outline of a business model, but it’s mostly assumptions, which will be validated in subsequent steps.|
|2. Problem/solution validation||You’ve validated that there’s a problem and that your business model aligns with possible solutions to that problem.|
|3. Market size/competitive analysis||You’ve completed market and competitor research, and the results align with your canvas and problem/solution validation.|
|4. Funded||You’ve secured funding to develop your idea (NOTE: according to Kinvey the average app takes 7 months and costs $270,000 to develop)!|
|5. Scoped||You and your developer have completely scoped your idea’s EXACT technical requirements and have a roadmap of when each requirement will be developed and what this will cost. This roadmap should organise your requirements into (bite-sized) sprints.|
|6. Developing||There is regular communication between you and your developer, who is developing your idea in agile sprint cycles. Partner meetings include a demonstration of design prototypes and technical progress.|
|7. Testing||Your developer has released the latest version of your software to a beta environment, where it can be tested by you and your end-users. (This step should be repeated at the end of each sprint cycle.)|
|8. Minimum Viable Product||Your developer has developed an app in-line with the scope (SRL 5) in a series of iterative cycles (SRL 6). This app’s testing (SRL 7) has validated the assumptions made on your business model canvas. You’re ready to begin commercialising your software.|
|9. Sales||You have commercialised your software and have sales.|
SRL 1 - Business model canvas
Creating a business model is the opening and most important step towards commercialising your idea.
There are some great templates that streamline this task. Alexander Ostewalder’s business model canvas (BMC) is one.
At minimum, you should complete each panel by outlining your underlying assumptions and how each of these will be tested. For example, if you write “less time coding and more time creating” under Value Propositions, as we did when completing Codebot’s BMC, one assumption is that Codebots does equal less time coding, which it does. How do I know? We tested it!
Your business model needs to be testable assumptions or validated statements.
SRL 2 - Problem/solution validation
Next you must validate that there is indeed a problem to be solved and that your business model aligns with possible solutions to that problem. Reaching this level requires a basic market overview.
To be SRL 2 you should have validated at least one market-solution and invalidated another through end-user interviews. It is recommended that you conduct between 50 and 100 interviews.
Engaging your end users early is the best way to avoid the quagmire that is redevelopment.
SRL 3 - Market size/competitive analysis
At SRL 3, you must have completed, at a minimum, a detailed map of the total addressable market divided into subsections, an estimated return based on total market value and expected market share for each of these subsections and a petal diagram of competitors.
You should then integrate this map and diagram with your problem/solution learnings.
SRL 4 - Funded
Although you will not know the true cost of your app until your app developer has scoped your idea, it is important that you make steps to secure adequate funding prior to partnering with a developer.
The Global State of Enterprise Mobility 2016 report estimates that most apps cost over $100,000 and more than 25% cost between $250,000 and $500,000.
SRL 5 - Scoped
At this stage, your idea’s EXACT technical requirements should be recorded alongside a roadmap of when each of these requirements will be developed and what this will cost. This roadmap should organise your requirements into (bite-sized) sprints with the intention of delivering a Minimum Viable Product (MVP) as soon as possible.
Your backlog should be a high-level vision of the pieces that make up your app (Epics, User Groups and User Stories).
Epics are the big picture ideas that make-up your idea. For example: Web Portal.
User Groups are types of people using your product. For example: Admins and Customers.
User Stories are how a User Group interacts with an Epic. For example: Customers can log into the Web Portal on Desktop or Mobile and do X, Y and Z so that this result is achieved.
SRL 6 - Developing
At this point, you and your developer have partnered to develop a specific backlog of requirements.
The question is: do you adopt an agile methodology or develop your backlog using a traditional, waterfall approach? Both methodologies have their advantages and disadvantages and while we’ve been advocates of agile in the past, it’s not always clear cut which option is better.
SRL 7 - Testing
Once you have developed your app, it’s imperative that you test it. Otherwise, you might wake up to discover that your ERP payroll system has overpaid employees $53 million.
You can outsource your testing, do it yourself, or automate it using Codebots.
SRL 8 - Minimum Viable Product
An MVP is a version of your app that meets your end user’s minimum needs. More specifically, some parts of your app are must haves and some are nice to haves. It is common practice to develop the must haves initially and the nice to haves later. This way, you can begin testing your app’s UX and raison d’etre as soon as possible.
To be at this stage of readiness, your app must be ready to be used by your end users, who could be app store customers, employees or a client’s employees.
SRL 9 - Sales
Your software is ready and you have started making sales.
This is not the finish line, you should continue to iterate on your idea and its technical expression.
We have reworked NASA’s hardware-focused Technology Readiness Level (TRL) and Steve Blank’s Investment Readiness Level (IRL) into a NEW and EXCLUSIVE software-focused model: Software Readiness Level (SRL).