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 intended. Product, you can make it happen and then keep making it.
The term is weird because, if you work at a nonprofit, you aren’t shipping anything and nobody is buying it. You don’t have a product. But you do have a mission, and you have 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. That is your product. So the question in front of you is never what can we ship. It’s what is the smallest version of this new thing we can put in front of the people we serve, that genuinely helps them, and that we can still be doing 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 with an MVP goes wrong because somebody held onto one of them 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. 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. Hold onto that table. We’re coming back to it more than once.
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 product, 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. That is a good place to start. It is a bad place to stop, and the difference between those two ideas is 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 and the part almost nobody publishes.
The sentence he’s interested in is “hey, can we just add…”
By the time anyone asks that, you have systems for adding things. You’ve done it before, so you can estimate it, and the estimate is honest (which is what makes it dangerous). Ask a game designer what it costs to add one more weapon and you’ll hear one more item file and half a day of work, and that’s true. 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, and the QA pass that now has to test the thing against every other piece of gear in the game. Those costs land on the final thing, not just on the calendar.
“Every feature we add, every piece of content we add has a greater cost than the feature itself.”
Mark Darrah, “Hey, can we just add…”
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 can make your project something people actually want and that meets their needs.
Not all three cost the same
Now go back to the example of the table, because the same reasoning runs in the other direction and almost nobody thinks that through.
Here’s one version of what minimum might look like: 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 thing 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 thing down until all you have left is a plank and four sticks with screws through them.
Then there’s product, which means you have to make it.

Product means produced. On a regular basis. With the budget you have, the staff you have, the volunteers you have. If the answer to every difficult scenario is somebody else — we’ll just hire a third party, we’ll bring somebody in on retainer — then you’re not producing anything. You’re buying products, and it is no longer your minimum viable product.
Hire the carpenter and you get a table. What you don’t get is any way to build the next one. And “on a regular basis” was in the definition.
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? By not asking these questions you’ve cut yourself off at the knees, and what you’re holding is minimum, barely viable, and no longer meets the need.
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 product and you might as well stop now since you’ll never launch.
Questions are cheap; regret isn’t
Which is why this starts with an open hand rather than a knife.
Everything is on the table. You are not cutting for the sake of cutting. Throw in everything you can think of, and ask every question you can think of, because questions are cheap. Guests, an heirloom, whether it matches the room — none of those cost anything to ask in advance, and all of them cost something to find out late. You won’t get all of them. Identifying every question that will eventually come up is impossible, so ask as many as you can anyway, and then strip away the things that genuinely will never show up.
The difference is whether you wrestled with the question 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.
An MVP is genuinely difficult to design. But once it’s designed, it is the easiest thing you will ever build, because it’s the minimum: the least you can implement that meets the needs and mission of your organization, and the least you can do that gets out the door. The table you design still only takes a weekend to build, but now it’s actually useful. Every question got answered before anything got cut, so the build is just cutting.
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, I want you to take some time to ask some simple questions that might change the work you’re doing. Name the thing you’re transitioning through. The thing you’re working on right now, this month, that could use the scoping time. The thinking time. The analytic time.
That’s the part worth doing.

