Hello friends,

Welcome back to Theory of Change. This is episode six of the new season, where I'm helping you look critically at the accepted wisdom of frameworks and ideas in purpose-driven work.

If you’re new here, subscribe and join 1,000+ others who use Theory of Change to navigate underfunded, human-centred work.

This week we’re looking at the Minimum Viable Product (MVP).

Supposed to be: a quick, scrappy way to learn what works before you over-invest.

Too often: a licence to ship half-baked ideas, prioritise donors over communities, and rationalise “move fast and break things” in contexts where the “things” are often people’s trust.

Eric Ries’ book The Lean Startup was a gamechanger for me and reading it ultimately led me to become the Chief Product Officer of a social journalism company sold for $25m. The instinct to test and learn was fundamental to our work there. But the MVP mantra, imported wholesale into purpose-driven contexts, has descended into utter madness.

So, let’s get into it.

🪫MINIMUM VIABLE PRODUCT🪫

What it’s supposed to be

In Silicon Valley, MVP is gospel. The idea is simple: instead of building a full product, create the smallest version that delivers core value, ship it, and learn really, really fast about what works and what doesn’t.

MVP-land is dominated by phrases like:

• “Fail fast, fail forward.”

• “Launch early, iterate often.”

• “F*ck it, ship it.” (How delightful.)

It makes sense in consumer software: the risks are low, the market is vast, and iteration speed is survival. Dropbox, Airbnb, and Uber all cite MVP lore in their early stories.

But in the nonprofit and public-interest world… oh, boy.

Where it falls apart

Myth #1. “Users = customers.”

In our world, there are at least two sets of stakeholders: the people we serve, and the people who fund it. Optimising for one can quietly harm the other. 

Myth #2. “Move fast and break things.”

The motto that defined Facebook’s rise also fuelled disinformation and surveillance capitalism. When transplanted into public services or journalism or food banks or grassroots contexts in general, “breaking things” generally ain’t good.

Myth #3. “If the market is small, don’t bother.”

MVP logic assumes scale: test small, then expand into a vast market. But public goods aren’t markets. Problems like eviction, benefits access, or domestic violence don’t come with a TAM (Total Addressable Market) slide. Many needs are niche but urgent, socially vital, and profoundly worth solving.

Myth #4. “Pilot first, then scale.”

I’m contradicting myself here, but the opposite to the above is also true. In reality, some answers do need to be designed with scale in mind from the start. But not MVP scale. They require research, coalition-building, and long-term commitment.

A better way to think about it

The appeal of MVP is real: it keeps us from building castles in the air. But we need a different approach for mission-driven contexts.

Firstly, we must design with two lenses: those most affected and the broader legitimacy of the system. One such example is Decidim in Barcelona, an open source platform for participatory democracy, used for budgeting, consultations, and assemblies. It builds legitimacy from transparency, traceability of decisions, and the genuine inclusion of residents in shaping city policy.

Secondly, we should prioritise who gets to participate, whose voices are amplified, and how decisions are shaped. Taiwan’s vTaiwan is an oft-cited example of this process. It used Pol.is to map citizen consensus on ride-sharing and digital policy.

Thirdly, instead of chasing Total Addressable Markets, we need to build with the networks, institutions, and communities where the problem lives, measuring significance by harm avoided or dignity restored, not revenue.

And finally: Think patterns, not products! Think open playbooks and adaptable infrastructure. Think locally owned versions of a proven idea. (A good example is my friends at ChangeX, who connect local groups with proven social innovations and give micro-grants to adapt them).

Try it this week

1. Run a “minimum trustworthy” test.

Before launching anything new, gather your team for a short pre-mortem (Gary Klein’s method is widely used). Ask: If this project failed in a way that harmed trust, what would that look like? Capture answers, then adjust your design until you’d be comfortable explaining it to both a beneficiary and a funder.

2. Read ‘Don’t Build It’

Luke Jordan’s Don’t Build It: A Guide for Practitioners in Civic Tech is a good practical field guide. It outlines why so many civic tech projects fail and how to avoid wasting time and money. Instead of cheerleading “move fast,” it teaches you how to pause, test assumptions, and only build when it’s genuinely the right tool. Ash Mann also wrote a great post on this earlier in the week.

🌊 WAVE GOODBYE 🌊

Thanks for making it to the end. People who enjoy this newsletter often say it gives them a small pause in the middle of a busy week, a chance to step back and reflect. Every so often, someone tells me they tried out one of the frameworks or mental models here and managed to break through a gnarly problem in their organisation.

That’s all I ever wanted Theory of Change to be: a quiet gift for people wrestling with big problems, often on their own.

So here’s my request this week: if you know someone who might be carrying one of those big problems, forward this to them. It might be the pause, or the nudge, they need.

Take care,

Adam

p.s. New here? Welcome! Sign up here to get this newsletter every Thursday.