2 things to not skip in an MVP

I have worked in many Agile projects, where the Minimum Viable Product is the focus of all efforts – but there are 2 things to not skip in an MVP. Too often, there is a focus on ‘shipping product’ or ‘getting it out there’ as soon as possible, but then there are at least two main areas that I too often see not getting enough attention – security and compliance in an MVP. This results in more work being needed later.

Minimum Viable Product

Within Agile projects, and also rapid application development, the concept of an MVP is used as a way to create an application, product, website or similar, and get feedback from the end user/consumer that can be used for enhancement and development. Iteration of developmental improvements through a minimal product can allow the product to be developed based on what the real users want.

Rapid development

Instead of spending months (or years) developing a product or website, waiting until it is fully working and created as designed, the concept of an MVP is based on the product not being fully functional, with known limitations, or even with known bugs. This is a much more rapid development approach where product is made available, increasing potential user uptake and an expected increase in matching what the user actually wants.

Never skip these

However, with an MVP, and its rapid development cycle, there are two important factors that should never be released as semi-functional or incomplete;

• Security, and
• Compliance

Importantly, areas such as security and compliance should not be an after-thought or a layer. Instead, these important factors should be inherent and pervasive within the product – even an MVP.

Minimum security

There is a minimum for security – and it may be that your MVP lacks 2FA or an EV certificate, but you should never have a time when the product is wide-open and unsecured. Back-end integration should always be authenticated and authorised, with encryption (even if there are plans to improve this from, for example, a self-signed certificate).

The time will come where focus is on developing the next iteration, or adding new functionality – and there is a risk that security will be de-prioritised or even forgotten. Often, the changes to add in security measures can change functionality, performance or reliability – and these issues should be identified early.

Semi-Compliance

In regulated industries, and any business that needs to meet regulations or standards, there is no such thing as semi-compliance. Even if you have an MVP to establish functional fit with a user story or proof of suitability – this product should still be able to meet compliance requirements. In the same way as security should not be applied retrospectively as a layer, compliance should not be an after-thought.

Don’t ignore security and compliance in an MVP

Whilst you may not implement a fully secure and compliant product, these important factors should always be inherent at all stages of a project. Don’t rush forward with an MVP that is insecure and non-compliant – as it may end up staying that way!