For decades, the lean thinking mantra “build-measure-learn” has dominated how innovative applications – in particular SaaS solutions – are launched on the market. The idea is as simple as genius:
- Formulate a business hypothesis, e.g., “a digital patient journal reduces administration in healthcare”.
- Build a simple, initial version of the product, known as a Minimum Viable Product (MVP), to test the hypothesis in the market.
- Measure the outcome, e.g., “interviewed medical staff claims to have 2 hours a week more for patients”.
- Learn by analyzing the collected data and deciding what hypothesis to test next, e.g., “administration can further be reduced by making the interface responsive, so that the healthcare staff can use tablets”.
That worked then, but it no longer works now. The EU has recognized how critical some applications are to fulfill basic social needs, such as healthcare, education, grocery shopping, etc. To bridge the knowledge gap and financing gap when it comes to keeping these applications stable and secure, the EU has introduced a number of regulations.
What does this mean for innovators? Do we need to give up lean thinking and go back to waterfall project management? How can we both innovate fast and comply with regulations?
In this blog, we present the 7-step innovation process proposed by Swelife.
1. Clarify your idea
The first step is to formulate what you are building and for whom. This corresponds to the “formulate” phase in the build-measure-learn process. The output of this stage can be as sophisticated as a business model canvas or an NABC elevator pitch.
2. Identify what you need
Now that you have formulated what you plan to do, it’s time to think about how you will do it. Do you have the needed skills? If not, what skills do you need? How will you acquire them? And how will you finance the work?
If you need advice, our friends at ALMI are really helpful.
3. Understand your audience
Map out the customer journey. How will the customers find out about you? Can they get a free trial or at least a demo? How will you onboard your customers? Self-service or “call us and we’ll set you up”?
4. Map the information flow
The three previous steps feel like textbook business development where the focus is to let your creativity grow without adding any blockers. Now, let's make sure those ideas align with legal requirements.
The first step is to make an information analysis. What information do you need to process for your MVP? In particular, you should map out the input information, output information and model information.
Input Information
If you draw a fence around your MVP, what information goes into it and for what purposes? For example, to sign up a new medical staff to your patient journal system, your MVP will likely need their first name, last name and email address, so as to keep an audit log of all patient journal accesses.
As another example, a nurse working for a school needs to enter a child’s weight and height as part of a yearly checkout.
Output Information
Thinking again about the fence, what information goes out of your MVP and for what purpose? For example, your MVP might report the number of daily active users for the purpose of monitoring application health or billing.
Model Information
With the advent of Generative AI, applications increasingly use some kind of model. As the saying goes “AI is the new web application and Kubernetes is the new web server”. You need to understand:
- Where does the training data come from?
- How has his model been trained on the training data?
- Are there any particular pre- or post-treatment steps?
5. Know the rules
Now that you have mapped out your information flows, it’s time to think about regulatory requirements. Regulations broadly deal with two concerns:
- Privacy, i.e., making sure that you collect only as much information as you need, that you remove it after it’s no longer needed and that you don’t use it for purposes other than agreed to by the person concerned. GDPR is the main regulation in this area, but note that it is incorporated by reference into MDR.
- Security, i.e., making sure that the collected information does not get in the hands of bad people (confidentiality), doesn’t get changed in unintended ways (integrity) and is available when needed (availability). GDPR Art. 32 has some provisions related to security, but the most security-focused regulation is NIS2.
That probably doesn’t help, so let us map out some regulations with examples.
In the example above, first name and last name are personal data and fall under GDPR.
If you operate in Sweden, then information about the health of a person falls under Swedish Patient Data Laws, i.e., HSLF-FS 2016:40.
Even if your MVP is not “physical”, it might will fall under Medical Devices Regulations (MDR) if – I’m grossly simplifying here:
- Output information can lead to misdiagnosis (MDR Class I);
- Output information can lead to temporary injury (MDR Class IIa);
- Output information can lead to permanent injury (MDR Class IIb);
- Output information can lead to death (MDR Class III).
Finally, if security issues with the information processed by your MVP may lead to the disruption of services critical to society, then you might fall under NIS2.
Make sure to take the time, study these regulations carefully and assess what non-functional features your MVP needs in order to comply with these regulations. Depending on the regulation, you may deduce such non-functional requirements in two ways:
- The regulations list explicit requirements. For example, MDR is rather prescriptive about change management, and has definitions for major, minor and patch versions.
- The regulations require you to go through a risk catalog, identify risks that apply to your product and take measures to reduce the likelihood or impact of those risks. For example, the NIS1-era MSBFS 2018:8 requires you to do risk management.
6. Build the solution
This step corresponds to the “build” phase in the “build-measure-learn” loop.
Now that you identified all functional and non-functional requirements that your MVP needs to fulfill, you are ready to start developing. Noteworthy is that regulations can add quite a few non-functional requirements, so your MVP probably ended up becoming a “not-so-Minimal” Viable Product (nsMVP 😁) after the regulatory analysis above.
At this stage, it is important to avoid reinventing the wheel and focusing on technical development only on your “magic sauce”, i.e., that piece of code which truly makes you stand out from the competition. For example, you might need to make sure that your application runs in the right jurisdiction. However, that is just a “hygiene factor” and not something that will motivate your customers to try out your MVP. Similarly, you might need to think about redundancy and information backups early on. But again, those are just qualifying checkboxes and not differentiating.
To reduce development cost for non-differentiating requirements, it is paramount to leverage open source and cloud native projects, such as Kubernetes. However, be mindful that these might not fulfill your regulatory requirements out of the box.
Therefore, it is really important to select the right platform. Loosely speaking, a platform is a set of open-source and cloud native tools carefully integrated together, so as to accelerate your development team. Some platforms, such as Welkin, are specifically designed to comply with EU regulations and can tremendously reduce your compliance burden allowing you to put more effort into your functional requirements.
7. Measure and learn
This step roughly corresponds to the “measure” and “learn” steps in lean thinking. What have you learned from the previous steps? Do you need to redo any of the previous steps to improve your MVP?
Conclusion: Innovate Smart, Innovate Secure
In today’s world, it's not enough to just have a great idea; you need to make sure it’s safe and complies with all the rules. The 7-step process helps you do just that, blending creativity with compliance.
By following these steps, you can turn your innovative ideas into reality while staying within the bounds of regulations. This process ensures your products are both cutting-edge and trustable. So, keep innovating smartly and securely. With this approach, you’ll be able to lead with confidence, knowing your solutions are both groundbreaking and compliant. This isn’t just a way to innovate—it’s the best way to succeed.
And remember, don’t reinvent the wheel. Contact Elastisys today to streamline your innovation process and ensure compliance.
Blog post by Cristian Klein
I’m Cristian, the Compliant Kubernetes product owner at Elastisys. I review data protection regulations and security best practices, to translate those into Kubernetes and Cloud Native solutions. I gathered over 19 years of experience acting variously as an on-call network engineer, consultant, teacher and researcher. You can follow me on LinkedIn, where I post about topics at the intersection of information security and Kubernetes.
