"Minimal Viable Products" in the Nonprofit Tech World

You may have been hearing the very buzz-wordy term "Minimal Viable Product" floating around in the technology world. This term was popularized by Eric Reis, the guy most famous for his "Lean Startup" work.  The concept is that you start your technology project something with as few features and as few complications as you possibly can- and, ideally, launch that into the world. You can then start to learn from what works (and what doesn't) while you continue to develop. 

As Eric Ries said: “As you consider building your own minimum viable product….remove any feature, process, or effort that does not contribute directly to the learning you seek.”

The MVP concept was created with a corporate tech product design mindset. But it's as applicable, or even more so, in the nonprofit world. One could argue that nonprofit customers of various sorts are more likely to be understanding of the flaws of a not-completely-fleshed-out product or website.

It's absolutely worth thinking about creating a "minimal viable product" for what you're building. I've found it useful on a number of my projects, to help reduce the initial build to essentials and to create something to test and learn from. It's also a great way to show funders or other stakeholders that you're able to create something worth having in the world… to hopefully build momentum (and money) to keep developing.

There are risks in this approach, though. Keep in mind:

• User experience and design. It's tempting to technology-centric folks to say that the quality of the interface and the graphic design are not minimal requirements of the system. If you're going to launch it to real users, or put it in front of funders, this almost certainly isn't a valid mindset. People will always be less compelled by something that's ugly and hard to use than by something polished and a pleasure.

• Cohesion. An MVP implies an iterative approach. As in all iterative approaches you need to first define and then keep a close eye on the overall vision for your product. If you don't, as you add things on, there's a real danger of creating a Frankenstein of accrued features instead of something compelling that's more than the sum of it's parts.

• Momentum. Any time you define a substantial release there tends to be a lot of team momentum towards that release… and then a real sense of relaxation after that, which can slow down development. To keep your team productive throughout, it's very useful to define "micro releases" - often done through sprints in an Agile process.

• Difficulty in "switch-over". If you're building a project that replaces something else- like a Constituent Relationship Management system or a membership portal, it may not be practical to switch to something that is less fully featured than the original. Especially when you have a lot of data to move. In this case, an MVP might only serve as an internal milestone, if it applies at all.

Often, these risks are things to be managed, not reasons to avoid a MVP process. I'd recommend that you at least think through what an MVP might be on every project, as a conceptual exercise. You may find that it's not right as an actual development process, but the thought process itself is likely to highlight some things that are critical and less so for the project. 

Want more information? 

• Here’s Eric Reis himself talking about the methodology

• This article from Interaction Design is a great overview of when MVPs can apply