What should my MVP include?
Most founders start with a feature list. I think that's the wrong place to start. Here's the question I'd answer before building anything.
Short Answer I think most founders ask the wrong question. They ask, "What should my MVP include?" I'd ask something else. "What is the smallest thing I could build that makes someone say, 'I'll give this a try.'" That's your MVP. ❌ Not the product with the most features. ✅ The product with the lowest barrier to trying.
Why I think this? I've noticed something after building products for founders across education, healthcare, real estate, legal, publishing, and marketplaces. The founders who succeed don't build for thousands of people. They build for one person - One teacher. One lawyer. One real estate agent. One school owner. Then they ask, "What's the smallest thing I can build that makes this person's life a little easier?" Take ReferralMate . Jacob had already built the first version himself. Agents could post referrals. Browse opportunities. Create profiles. The product worked. But before rebuilding it, we stopped and asked ourselves one question. "Why would an agent try this instead of just calling someone they already know?" That became the MVP. Not another dashboard. Not AI. Not more features. Just making it incredibly easy for an agent to trust the platform enough to post their first referral. Today, more than 13,000 agents use ReferralMate. Then there was Merit Academy . Harshitha already knew her teaching method worked. Parents loved it. Students were learning. She wasn't asking us to build a better education platform. She wanted another teacher to teach exactly the way she did. That completely changed the MVP. We weren't building software. We were trying to answer one question. "Can another teacher deliver the same experience?" Everything else could wait. I saw the same thing while building a legal platform YourCharteredAI Lawyers weren't asking for AI. They were tired of copying hearing dates from PDFs into their calendars. They hated writing meeting notes after every client call. The first version wasn't trying to change how lawyers worked. It simply removed two jobs nobody enjoyed doing. That was enough to make people start using it. After working with dozens of founders, I've realised something. People don't try products because they have more features. They try products because one part of their day becomes easier. That's all your MVP has to do. A Zappify Principle Whenever we define an MVP, we never begin with features. We begin with one sentence. "The only thing we're trying to find out is..." If you can't finish that sentence, you're probably not ready to build. If you can, your MVP becomes surprisingly obvious. Every feature should help answer that one question. If it doesn't, it belongs in Version 2.
FAQs
How do I decide what features to include in my MVP?
I'd start with one sentence: "The only thing we're trying to find out is..." Then I'd keep the features that help answer that question and cut the rest. This is where good product thinking matters. A developer can build the feature list you give them. Someone needs to help you decide whether the feature list itself makes sense.
How many features should an MVP have?
There is no magic number, and I'd be suspicious of anyone who gives you one. A useful MVP might have three features or fifteen. What matters is whether those features work together to solve one real problem. If removing a feature doesn't stop the user from getting the main value, I'd probably leave it out.
What should I leave out of my MVP?
I'd leave out anything that makes the product nicer without helping someone get the main value. Advanced settings, extra user types, complex dashboards, multiple payment options, notifications, and "we'll probably need this later" features are common examples. The hard part isn't deciding what to build. It's having the discipline to say no to things that can wait.
Do I need UI UX design for my MVP?
Not necessarily. You can build an MVP with very simple UI if the goal is to test whether the product solves a real problem. What I wouldn't skip is mapping the user journey. You should know where the user starts, what they need to do, and what success looks like. A polished interface can wait. A confusing product journey shouldn't.
Should I hire someone to design my MVP before I build it?
If you don't know how to map the product yourself, I'd get help before development starts. That could be a good freelance UX designer or an experienced product agency. I would not pay someone to spend weeks making beautiful screens. I'd pay them to understand the problem, map the user journey, challenge the feature list, and turn that into something a developer can actually build.