Who’s Down with MVP? You Need All Three!

Your organization is about to do something it hasn’t done before. The decision is made and now you just need to get started and launch. A new service, a new goal, a leadership transition, a program that has to grow past what it was built for. But before you take your first step, let’s have a serious conversation about what you’re working toward.

A Minimum Viable Product, or MVP, is how you get through work like that and have something standing at the end of it. Three words, and every one of them is a requirement. Minimum, the least you can implement. Viable, it actually works for the people it’s meant for. Product, you can make it happen and then keep making it.

Now, for nonprofits MVP means something slightly different. You aren’t shipping anything and nobody is buying it. You don’t have a product. What you have is a mission and the specific ways you meet it — the counseling hours, the food boxes, the after-school program, the thing somebody rearranges their whole Tuesday to get to. So for the rest of this I’m going to say Minimum Viable Program, and I mean it as a straight substitution: same three requirements, same acronym, a word you already use for the work. The trade keeps what product was hiding and you’ll need it later: a program is something you run, repeatedly, not something you finish.

So the question in front of you is never what can we ship. It’s what is the smallest version of this new service we can put in front of the people we serve, that genuinely helps them, and that we can still be running next month with the staff we actually have.

If you stop reading here, take this much: you need all three, and nearly everything that goes wrong goes wrong because somebody held onto one of these things and quietly let the other two go.

The trap you can’t see

Building is the fun part. That is the entire problem. Building something is creative work, and creative work feels good in a way that planning meetings don’t. And the truth is, almost any work can be exciting at this phase: a new initiative your organization is launching, a new support service added onto what you already offer, a whole new company.

Or a table. I grew up the son of an accomplished carpenter, so when somebody says build, I see a woodshop before I see a project plan. I’m going to keep coming back to a table for the rest of this, and not just because furniture is a tidy metaphor for program design. It’s because a table makes the questions visible. Nobody can look at a plank with four legs screwed into it and fail to notice that only one person is going to sit there. Your new service won’t do you that favor. It will look finished long before anybody finds out what it left out.

So you plan. Then you build. Then you keep building, because there is always one more thing that would make it better, and the building is the part you enjoy. And you never launch. The Winchester Mystery House was under construction for thirty-six years.

The idea itself is simple enough to say in a sentence. Find what it takes to meaningfully meet the need — the minimum viable version of the program, the service, the piece of furniture — and then go meet the need.

Most people hear that as subtraction. Cut everything back. Remove everything you don’t strictly need in order to launch. As a place to start, that’s right. As the whole method, it’s where most of the damage happens.

Because launching was never the goal. Make launching the whole goal and you will launch, on time, under budget, to applause (good for you). The need you built it for will still be sitting there afterward, unmet, waiting for a second attempt that now has to be funded on top of the first one.

There’s a video from one of my favorite YouTubers that helps to tease this out, and it isn’t about nonprofits at all.

Mark Darrah ran big projects at BioWare, a software publisher famous for epic, triple-A video games. He was executive producer on big games like Dragon Age: Inquisition and Anthem, which was better than everybody seemed to think it was. He makes videos now about what it takes to launch something that size, including the parts that went wrong, which is the useful part for leaders like yourself and the part almost nobody talks about.

The sentence he’s interested in is “hey, can we just add…”

By the time anyone asks that, you have systems for adding. You’ve done it before, so you can estimate it, and the estimate is honest — which is what makes it dangerous. It’s the same arithmetic I’d run in the woodshop: I’ve inlaid one decorative band into a tabletop, it took an afternoon, so the second one takes an afternoon. True, and it tells you nothing about whether the second band belongs on the table.

Ask a game designer what it costs to add one more weapon and you’ll hear one more item file and half a day, and that’s true too. What the estimate doesn’t cover is the new model, the new icon, the description, the translation of the description, the animations if what somebody asked for was a flail (those swing-y chain weapons… I’m letting my nerd flag fly here, huh?), and the QA pass that now has to test that weapon against every other piece of gear in the game. Those costs don’t come out of the schedule. They come out of the finished game — the polish that doesn’t happen somewhere else, because the hours went here.

Darrah isn’t telling you to reflexively say no. That’s the part people miss. Sometimes what’s sitting at the end of “can we just add” is the one thing that makes the difference between a service people use and a service people were willing to try.

Not all three cost the same

The inlay band was a question about adding. Run the table the other direction, toward subtraction, and the same blindness is waiting — except this time nobody is watching for it.

So: what do I need this table for? Breakfast in the morning, lunch in the afternoon, dinner in the evening. Fine. Here is what that gets you — a flat plank of wood, four sticks cut off fairly evenly, screwed into the top. Call it a day. That is the minimum viable table for eating dinner (and for eating dinner alone).

Now ask the questions you skipped: Will you ever have guests? Does it look and feel like you? Does it match the rest of the room? Is it comfortable to use? Do you want to hand it down to somebody?

Nobody wrote those questions down, because subtraction never asks you to. That’s the asymmetry. Adding hides its cost in everything the addition touches. Cutting hides its cost in the need you were supposed to meet, which almost nobody spends any time on at all. Same blindness, pointed the other way.

Which brings us back to the three words, because they are not equally hard.

Minimum is the easy one. Subtraction is arithmetic, and anyone can do arithmetic. That is exactly why it’s the word everybody remembers, and why the whole phrase gets read as permission to cut.

Viable is the hard one.

Viable means the program actually meets the needs of the people you serve, which is a different question in every organization that asks it. A place of worship adding a family counseling center for an influx of new parents. A university adding a service center for commuter students who feel disconnected from campus. A food bank adding new food items for an immigrant community it serves, items that need different sourcing than anything on the shelves now. Not one of those is “we’ve done this before, we know how to do this, let’s just add it.”

And the beginning of a project is where this is hardest, which is the opposite of what people expect. There is nothing built yet to reason from. Minimum and viable are both still up for definition, at the same time, by the same people, in the same meeting.

Viability drags in every question you were hoping to answer later. How do we support this with people? How do we support it with software and tools? How do we support it with educational resources? And how does it sit against our mission, our vision, and our values?

That last one is the question that can make or break your initiative. Whether the table matches everything else in the room was an aesthetic question, and you could get it wrong and still eat dinner. Whether a new service matches your mission and your values is the same question with considerably more riding on it. You can’t answer that question by looking at what you’ve built before.

So no, this part isn’t easy. And it is not a matter of stripping the table down until all you have left is a plank and four sticks with screws through them.

Then there’s the third word, and this is where the substitution earns itself.

A product can be a single object. You build the table, the table exists, you’re done. A program can’t be. A program is something that happens again next month, and the month after, with the budget you have, the staff you have, the volunteers you have. That recurrence is the requirement, and it’s the one that gets waved through in scoping meetings because it doesn’t come due until later.

Here’s the test. If the answer to every difficult scenario is somebody else — we’ll bring in a third party, we’ll put somebody on retainer — then you’re not running a program. You’re buying a service, and next year you will buy it again at whatever it costs then, because nothing you built this year taught your organization how to do it.

So a good part of this work is deciding what stays inside. What can you actually do internally? What matters internally? What could never be handed off, because handing it off would mean you were no longer you? What is so essential that it is what it means to be your organization?

Skip those questions and what you’re holding is minimum, barely viable, and no longer meets the need — not because anyone built it badly, but because the part that was supposed to run it next month was never yours.

Lose one of the three and you have nothing. Lose minimum and you get the build that never ships. Lose viable and you get the plank and the four sticks. Lose program and you get somebody else’s work — rented, competent, and gone when the retainer stops.

Questions are cheap; regret isn’t

Which is why this starts with an open hand rather than a knife.

Put everything on the workbench first — not the finished piece, the questions. All of them, including the ones you’re fairly sure don’t apply. Every question from the table earlier costs nothing while the wood is still rough, and every one of them costs something after the top is glued up. You won’t think of all of them; identifying every question that will eventually come up is impossible. Ask as many as you can anyway, and then set aside the ones that genuinely will never show up.

Setting a question aside is not the same as never raising it. The difference is whether you wrestled with it or foreclosed on it.

Years ago, I had a client building a website, and they knew what they needed. Information resources for their subsidiaries. Leadership training. Documentation for their processes. They also knew what they didn’t need.

“No news, no blog. We’re not planning to update it like that.”

So I pushed back, because content management tools are much easier to design and build at the beginning than to add later.

“Are you sure?”

“No, no, we’re fine.”

“What about press releases or events?”

“No, no, we don’t need anything like that.”

Two months later there was a leadership change, and suddenly they needed a way to post a press release to their website. So they paid us to come back and build it. A new engagement, additional fees, for the thing that had been cheap two months earlier.

The mistake wasn’t the answer they gave. They might have been right — plenty of organizations genuinely never post anything, and building a newsroom for them could have been waste. The mistake was treating it as a question that didn’t need asking.

The easy part comes last

Here’s the part that makes all of it worth doing.

A Minimum Viable Program is genuinely difficult to design. But once it’s designed, it is the easiest work you will ever do, because it’s the minimum: the least you can put in place that meets your mission and the need in front of you, and the least you can run that gets out the door.

The well-designed table still only takes a weekend to build. That never changed. What changed is that this weekend produces something worth sitting at, because every question got asked while the answers were still free. All that’s left is cutting, and in a woodshop that has never been the part anybody dreads.

That is exactly what you want. Spend the time on the design.

Next time, I want to get into the tools that get you there — practices for the conversation itself, starting with who is in the room, and AI as an analytical partner in the earliest phase. There are good reasons to use these tools and good reasons not to, and every situation is different. But at the front of a project, when you’re trying to ask more questions than you can think of on your own, an analytical partner is close to essential.

Before then, name the thing you’re transitioning through — the one you’re working on right now, this month, that could use the scoping time nobody has budgeted for it.

Then ask what it would cost you to find out in month nine that you were wrong about what it needed. If you can answer that quickly, you already know which of the three words you’ve been holding onto.