Today, most SaaS platforms are built using agile methods — by releasing new features in short iterations and following the “Minimum Viable Product” concept in order to maximize validated learning in the shortest time possible. This allows companies to run and react quickly in an ever-changing environment.
But what happens if you are building a SaaS platform that powers up a nuclear plant? Your MVP is no longer “minimal,” as it will have a high volume of “minimal” requirements in order to operate successfully and safely.
Another example is a platform that runs airport control towers. You can’t just release a product with very small functionality and have it control the towers instead of the existing systems, it must handle many critical things.
Similar to this analogy, in Optibus we have a product that runs the control room for public transportation operators. This is a mission critical system that runs the daily operation of all the vehicles and drivers. It has a large set of required functionality to start with — and it cannot break down.
When developing this product, our approach was to begin with what we named “The Skeleton.” The idea was to develop many real end-to-end user flows, going through all modules without focusing on the user interface design at all.
Each use case covered a unique new requirement that forced us to design and build a new part of the architecture that was not required for the other use cases.
For example, “Edit a vehicle” is a skeleton capability, unlike “Edit multiple vehicles” — which doesn’t require new services and architecture decisions on top of editing a single vehicle.
We used a careful process to select these use cases, making sure to cover all the services and architecture decisions needed for our first release, which contains many functionalities required in order for our users to be able to tear out and replace the existing way of running the control room.
Good architecture and code design is one of the biggest challenges when building a product, and the best way to approach this challenge is to build and validate with real use cases. Changing the architecture later is nearly impossible.
By doing this, we were able to achieve validated learning – building our product robust and scalable from the ground up and having it ready to work in real control rooms from day one.
To gather and learn from product feedback early on, we had a long market research process where we created comprehensive mocks and validated them with real users in an iterative process.
Clearly this process takes more time to get to the first release. However, you can get there safely while avoiding huge refactor efforts that will slow you down in the future.
So how do you make it happen? You will need access to a diverse group of real users and a strong understanding of the market, existing solutions, and pain points.
You will also need to build extensive mocks to validate your product plans with the users. This process is most suited when your product needs to replace a very comprehensive system/process from the beginning in order to be viable.
You shouldn’t be afraid to build an MVP for a nuclear plant using agile methods, just make sure that you adapt your processes accordingly.
Read more:
➤To Open Source or Not To Open Source? That Is the Question
➤How to Make Smart Decisions When So Much Is Unknown
➤Continuous Deployment in Mission-Critical Enterprise SaaS Software