With digital becoming increasingly mainstream in the social impact sector, more organisations are practising Agile development – the way of working used to create and maintain most digital things and all the platforms we interact with everyday. Agile is a digital creation process that strives to launch features little and often, getting a product into the user’s hands as quickly as possible, and using feedback to determine what features to add next. It’s a process used by many of the digital products we use regularly – like Facebook and Google.
Agile is a brilliant, collaborative way of working that places users at the heart of the production process, which is exactly where they need to be. However, when creating digital products for hard-to-reach users, some parts of the Agile process require modification such as how and how often feedback is gained, the frequency of product updates and the role of the MVP.
Moving On From Minimum Viable Product
An MVP (minimum viable product) is a version of a digital product with just enough features to be functional for early users, who will then later provide feedback for future iterations and improvements. Eric Ries, who popularised the concept of MVP in 2011 in his book The Lean Startup, states that the MVP’s sole objective is not to create a good user experience, but instead to generate learning:
As you consider building your own minimum viable product, let this simple rule suffice: remove any feature, process, or effort that does not contribute directly to the learning you seek.
MVPs work really well when there is both an easy, frequent feedback loop and digitally literate users who have well-managed expectations of an MVP’s purpose. But hard-to-reach, digitally illiterate users in low internet resilient environments often don’t fit that criteria. AND they usually don’t have the time needed.
When the MVP is deployed to excluded, hard-to-reach users, it can take time to download, use, and then give feedback on it. The MVP – which by its nature comprises a small feature set focused on functionality, over usability – often does not meet enough of the user’s needs to be perceived as useful or better than their existing way.
As a result, the user often has an unfulfilling first experience with the product and reverts back to their previous familiar method. The next time feedback is needed, users are (understandably) reluctant to donate their time to a product they don’t believe adds value to their life. Especially one they stopped using after the first unsuccessful experience. The critical ongoing feedback loop needed for Agile development can’t be initiated.
Unless we have real, easy rapid feedback loops with users who understand what an MVP is, are digitally literate, and time-rich, we should stop creating MVPs in their current form.
Let’s Deploy Minimum Valuable Products
At Here I Am, we create Minimum Valuable Products – an extension of the original MVP concept. Rather than looking to create the minimum viable iteration of a product, we create the minimum iteration of a product that is capable of providing meaningful and lasting value to our users’ lives.
Unlike MVPs which often feel incomplete, Minimum Valuable Products are simple, but complete. They are ideal for including hard-to-reach, digitally illiterate users and provide a better user experience. Google Docs is a great example of this. It launched with only 3% of Microsoft Word’s features, but it still felt useful and most importantly better.
Creating a Minimum Valuable Product instead of a Minimum Viable Product increases the propensity for users to adopt the product into their lives from the get-go. Once they begin using the product, you can open up a feedback loop with the user based on their ongoing experiences using the product. And so a meaningful Agile journey that immediately adds value to both the user and the product begins.
MVPs aren’t the only area we urge you to reconsider when adapting Agile for hard-to-reach users – we share our thoughts on how to construct a respectful feedback loop here.
Minimum Valuable Products have another appealing benefit for social impact orgs: they aren’t dependent on further investment in order to add value. It’s always better that version 1 of a digital product evolves, but you also have the option of not immediately investing more into the product while still adding value for users. An MVP without additional investment is just a bad product.
A Minimum Valuable Product without additional investment is a good, if modest, product that most importantly adds value to its users’ lives.
Originally published as Why Social Impact Organisations Should Reconsider Minimum Viable Products in the Agile Process
I really like the point. But I don’t think that excluding essential users from using a product by leaving out complex issues is “viable”. If people say that there “MVP” doesn’t need to address features that are certain to be critical later and will even become more difficult to add later, then it’s not viable or the “viable” is defined by the wrong people.
You can find a similar pattern with respect to security. If an MVP doesn’t account for basic security like authorization, GDPR or encryption, it’s gonna be very expensive to patch up and thus that product was never “viable”. Ask security people what they think about security patching all the APIs of an MVP after a release.
Another also very related topic could be internationalization / translation and accessibility: These are also not patterns that are applied later. They need to be built-in from the start. The question is not if the MVP is translated into 100 languages – but if it *can* be translated. Otherwise, it’s not “viable”. A proper MVP will be launched in English + one additional language.
When an MVP isn’t “viable”, it’s just a prototype that should be deleted after the demo 🙂
Hi Ben,
Thanks so much for your feedback. I totally agree with your comments. Whether building a product for digitally literate users in HIC countries or excluded users in LMIC countries, it’s imperative that security, accessibility and scalability are built into the MVP foundations of any products, or as you say, it’s not viable. Where we see the difference, and the overlooked part, is also ensuring the product is immediately useful to the useful – ie better than their current solution. And too often, even MVPs that have achieved security, accessibility and scalability, aren’t useful enough to start a long term feedback loop with the intended user. So I think in summary what we are collectively saying is an MVP should comprise security, accessibility and scalability and usefulness?!
Thanks again for your excellent comments.
Laura
Useful to the user!*
What a useful (and important) distinction, Laura. Excellent article! For those of us that work in the global health space, there can also be another criteria that comes into play: safety. Digital health solutions that inform the course of care delivery (e.g. ANC workflows; HIV care and treatment; etc.) have to be valuable, for sure… and they have to also be demonstrably patient-safe.
Hi Derek, excellent point, and completely agree.
We have a safety mantra at Here I Am that goes like this – and helps us to always remind ourselves about the most important thing – safety:
“Our user’s safety is the most important aspect of every product we create, service we provide and every decision made should reflect this. It will be reflected across everything from design to development to delivery. We must not compromise our user’s safety in any way, nor will we opt for solutions that cut corners in terms of cost, process or time at the expense of safety. Their safety will sit at the core of every decision made, which is exactly where it needs to be”
It’s a good reality check to help us make the right decision, when we reach inevitably points of the journey where trades-offs need to be made.
Thanks again for your feedback.
Laura