Our team at Agile in Nonprofits, as well as the larger DH Leonard Consulting team, always has Stanford Social Innovation Review (SSIR) articles in our “TBR” (to be read) list of articles as we prioritize our industry reading as there are always thought-provoking articles publishes. In August of 2020, they released an article “Five For-Profit Practices That Philanthropy Should Avoid” that had a particularly relevant element for Agile. It was indeed thought provoking for our team, and in this particular instance, we believe that they got one of the items in the article wrong. Specifically, we think that they got the MVP (minimum viable product) idea wrong for what it means for nonprofits and wrong-fully included MVP in their list of practices to avoid. 

Here’s why. We don’t see nonprofits embracing the concept of “minimum viable product” as rushing to get services designed and quickly in place. Rather, “minimum viable product” in nonprofits is about having small tests of services or supports available for feedback from the actual stakeholders instead of developing a big new program, releasing it in its entirety, and realizing that despite the best intentions, it doesn’t deliver what the need assessment process showed was needed or needs to be modified based on actual client/user/stakeholder feedback. 

In fact, SSIR itself published a great article “The Promise of Lean Expectation” in 2015 which highlighted a nonprofit that embraced the MVP idea and benefited from it immensely. 

We thought, in addition to that example provided in the 2015 article, we would share a few other real examples that we have seen of nonprofits using as “minimum viable product:”

• A draft of a grant application – We have seen this start as v1 (rough draft with questions/comments in the margin) and then as the product increment grows each sprint, it ends up in v3 (smoothed out narrative that has gone through grammar edit and is approved for submission). There is no surprise feedback at the end of the process that results in having to redo entire sections of the proposal which might otherwise be likely if stakeholder input wasn’t allowed until the end of the process.
• Testing hands-on activities for students – A nonprofit that runs in-person STEM programming camps for middle schoolers pivoted to virtual programming during COVID. They wanted to send a box of activities that students could do on their own with no parental involvement. Rather than test all the activities in the box at one time, they started with one. The first was to replicate thee s’mores at the campfire experience. They wanted to see if students would be able to make at-home solar ovens so they had their children test the idea using a pizza box, tin foil, small stick, and piece of wax paper. 
• Releasing new intake forms to clients – A nonprofit that was redoing its intake form questions updated one question at a time in their online portal to test the question and see what responses/feedback/issues came up with each from both the client completing the form and the staff utilizing the completed form. This minimized the volume of issues the team had to address at one time since the changes were incremental and allowed for learning from one change to be reflected in the next update to the intake questions. 

These are three very different examples of what a minimum viable product may look like in your organization. Regardless of the type of work your organization does to achieve your mission, the way to think of minimum viable product is what is the smallest increment you can deliver of value that your community member/client/patient/stakeholder (or a stand-in) can use/touch/read and give feedback on.

What are the ways that YOU have seen minimum viable product used in nonprofit settings?