How to Decide What Goes in Your MVP (and What to Cut)
What makes your product different from everything else out there? Now ask yourself a second question: is that thing in your MVP, or are you saving it for later?
Founders do the second more often than you would think. They start with the basics, the obvious features, and plan to add the special part once the foundation is ready. In this post, I'll share a story about exactly that, and then walk you through six steps to decide what goes into your MVP and what gets cut.
A story: the app that did what calendars already do
A founder I worked with built an MVP that organized the busy lives of parents: their tasks and their reminders. It worked, and it looked like a solid start.
So what went wrong?
There was no differentiator. Calendars already do the same thing, so parents had no reason to switch.
The value the founder really intended was something else: a marketplace of vendors with the best offers and instant booking, so parents can find help without any hassle. But that was left for later, because the founder assumed the MVP had to start with scheduling and organization.
So what REALLY went wrong? Parents had no reason to use the platform without the vendor service, and the vendor service was the one thing missing.
My suggestion was to flip it. Start the MVP with only the value proposition: vetted vendors delivered straight into the parents' existing calendars. That way the founder could test the one thing calendars can't do.
What is an MVP, and why does the scope matter?
MVP stands for Minimum Viable Product. Eric Ries, author of The Lean Startup, helped popularize the idea: the smallest version of your product that lets you learn something real from real users.
The key word is learn. An MVP is not a smaller version of the full product. It is a way to test your riskiest belief as early as possible.
Can you succeed by building the basics first? Sometimes. But if the basics are what everyone else already has, you will learn very little about whether people need YOUR product.
Step 1: Write down what makes you different
In one or two sentences, finish this: "Users would choose this over what they use today because..."
If you can't finish it, that is the first thing to work on, before any building.
Remember: If your differentiator isn't in the MVP, you aren't testing your product yet.
Step 2: Find the riskiest belief behind it
Every idea has a belief in its core. In the story above, the belief was that parents would want and use vetted vendors with instant booking.
That belief is the one that decides if the product has a future, so it deserves to be tested first, not last.
Remember: Test the belief that scares you most, not the one that is easiest to build.
Step 3: Question the "foundation first" assumption
"We need to build scheduling first."
"We need accounts and settings first."
Sound familiar?
Ask honestly: does the user need this to experience the value, or do I just feel it is the natural order? Sometimes you can deliver the value through something users already have, like the calendar in the story, instead of building a new foundation.
Remember: Natural order for the builder is not the same as the right order for the user.
Step 4: Cut everything that doesn't test the belief
Make a list of every feature you have in mind. Next to each one, write whether it helps test the riskiest belief. If it doesn't, it goes on the "later" list.
This is hard, because every feature feels important. But it is not a shame to leave things out. You can add them when you've learned something real.
If you are a visual learner/organizer like I am, my Product Ecosystem Diagram could help you align your user journey to the features you want to build, and then you can identify what is critical to test the belief, leaving everything else for later.
Remember: Cutting is not losing. It is how you protect your time and money while you learn.
Step 5: Look for simpler alternatives
Many times you will find that you can build the core riskiest feature on its own, without the basic foundations. But if you need to connect it to the context your users are in, look for alternatives.
In the story I shared above, the users’ context is their current calendars they use. Making the vetted recommended vendors directly from within their calendars is one concept we explored. Integrating an online vendor list to scheduling and the parents’ selected calendar was another.
Remember: your solution is never in silo, and the users’ context is important. But you don’t need to replace it completely.
Step 6: Put it in front of real users
Once the scope is clear, get your small version in front of real users as soon as you can, and watch what they do. Do they use it? Do they come back? Do they ask for more of the part that makes you different?
Their behavior will tell you more than your assumptions will.
Remember: The goal of an MVP is learning, not launching.
Common pitfalls (and how to avoid them)
- Starting with the generic parts. If competitors or everyday tools already do it, it isn't what you're testing.
- Treating "later" as "never tested." If the differentiator keeps getting pushed back, ask yourself why.
- Building a bigger MVP to feel safe. More features don't reduce risk, they just delay the answer.
- Skipping the user conversation. Validate everything before you invest heavily.
Putting it into practice
This week, take your feature list and mark the one thing that makes your product different. If it isn't in your first version, ask what the smallest way to test it would be.
If you'd like help with that, I'm running a Founding Pilot: 4 weeks of hands-on product work for $145, for the first 5 pilot founders. You bring a decision you're stuck on, and we tackle it together. Details are here: https://productsforgood.co/founder-pilot
If you want to go deeper on your own, my Build Your MVP course walks you through the process.
I would love to hear from you. What did you leave for "later" that probably should have been in your first version? Send me a note through the contact page or at Hello@productsforgood.co, and let's compare notes.
Go, go, iterate!