Every founder we work with has a long list of features they’d love to build. Dashboards, integrations, notifications, admin panels, reports, mobile apps and a dozen clever extras. It’s a sign of genuine enthusiasm. It’s also one of the quickest ways to spend months and a large budget building something before learning whether anyone wants it.
That’s why we encourage startups to begin with a minimum viable product, or MVP. Deciding what goes into that first version is one of the most important product decisions you’ll make. Here’s the method our team uses to help founders get it right.
What an MVP actually is
An MVP is the simplest version of your product that solves a real problem for real users well enough that they’ll use it, and ideally pay for it. Its purpose is learning. You put something real in front of people, see how they respond and use that feedback to decide what to build next.
An MVP is not a half-broken product, a mock-up nobody can use or a stripped-down version that solves nothing. “Minimum” refers to scope, not quality. What you include should work reliably and feel trustworthy.
Start with the problem, not the features
Before listing features, write down in one or two sentences:
- Who your first users are, as specifically as possible
- What problem they have today
- How they currently deal with it
- What outcome they want
For example: “Independent physiotherapy clinics in Goa manage appointments through phone calls and paper diaries, which leads to missed bookings. They want patients to book and reschedule without calling.”
This statement becomes your filter. Any feature that doesn’t help solve that problem for those users can wait.
Map the core journey
Next, describe the single most important journey a user takes to get value from your product. In the clinic example, it might be:
- Patient opens the booking page.
- Patient chooses a service and an available time.
- Patient enters their details and confirms.
- Clinic sees the booking and patient receives a confirmation.
That’s the heart of the MVP. Everything that’s essential to complete this journey belongs in version one. Everything else goes on a later list.
Sort your feature list
Take your full wish list and sort every item into one of three groups.
Must have
Features without which the core journey doesn’t work. For the clinic: service list, calendar availability, booking form and confirmation.
Should have later
Features that make the product better but aren’t required to test the idea. For example: automatic reminders, patient accounts, online payments or reports.
Nice to have
Ideas that may never be needed, or only once you have many users. For example: loyalty points, multi-language support or a dedicated mobile app.
Be ruthless. If you’re unsure whether something is a must have, ask: “Could early users still get the main benefit without this?” If the answer is yes, it can wait.
Fake it before you build it
Some features can be handled manually at first. This is often called a “concierge” or “Wizard of Oz” approach. Instead of building automatic reminders, the clinic could send a quick WhatsApp message by hand. Instead of a full admin dashboard, the founder might check a simple spreadsheet.
Doing things manually early on is slower per user, but it’s much cheaper than building automation for a feature you’re not sure people need. It also teaches you exactly how the feature should work if you do build it.
Choose technology that lets you move quickly
For an MVP, speed of learning matters more than a perfect technical setup. That might mean:
- Using a reliable framework your developers already know well
- Using existing services for payments, email, login and hosting rather than building your own
- Building a responsive web app before separate iOS and Android apps
- Using no-code or low-code tools where they genuinely fit
Keep an eye on the future, though. Choose tools that can grow with you, and keep the code clean enough that you can build on it rather than throw it away.
Decide how you’ll measure success
Before launch, agree on what you want to learn and how you’ll know. For example:
- Do clinics actually share the booking link with patients?
- How many patients complete a booking once they start?
- Do clinics keep using it after the first month?
- Will they pay for it, and how much?
Set up simple analytics and plan to talk to users directly. Conversations often reveal more than numbers.
Launch to a small group first
You don’t need a big public launch. Start with a small group of early users who have the problem you’re solving and are willing to give honest feedback. Support them closely, watch how they use the product and fix issues quickly. Their experience will shape your next steps.
Common MVP mistakes
- Including features “because competitors have them”
- Spending months polishing before anyone outside the team has seen it
- Building for everyone instead of a clearly defined first user
- Treating the MVP as the finished product and not planning for iteration
- Cutting quality on the core journey to squeeze in more features
Conclusion
A good MVP is small, focused and genuinely useful. Define the problem, map the core journey, sort your features honestly, handle some things manually and launch to a small group so you can learn quickly. What you learn from version one is what makes version two worth building.
If you’re planning a new product and want help shaping your MVP, our team at xRapid Media LLP works with founders to design and build web and mobile products. Call us on +91 9767196309 or request a free consultation through our website.