What should a minimum viable product (MVP) include, and what should I leave out?

An MVP is not a "half-finished" product; it is the smallest version of a solution that allows you to deliver value to your users and learn from their behavior.

Here is how to distinguish between what to include and what to leave for later.

What to Include (The Core)

Include only the features essential to solving the single primary problem you are addressing. Ask yourself: "If I remove this, does the product still solve the core problem?"

• The "Core Loop": The essential path a user takes to achieve the primary goal. If you are building a ride-sharing app, the core loop is: Request ride → Ride happens → Payment processes. Everything else (user profiles, ratings, ride history) is secondary.
• The Primary Value Proposition: The one thing that makes people want to use your product. If this isn't clear and functional, the rest of the app doesn't matter.
• Basic Security and Reliability: Even an MVP must be usable. It should be stable enough that a user can complete the core task without the system crashing or compromising their data.

What to Leave Out (The "Nice-to-Haves")

Anything that distracts from the core experience or isn't required to validate your hypothesis should be cut.

• "Scale" Features: Don't build for 100,000 users if you don't have ten yet. Ignore advanced caching, complex microservices, or custom load balancing early on.
• Polish and Perfection: Avoid "pixel-perfect" UI, complex animations, or extensive customization options. Your focus is on function, not aesthetic perfection.
• Edge-Case Functionality: Don’t build features for the 1% of users who might need a specific, complicated workflow.
• "Future-Proofing": Avoid building systems that accommodate features you might want in a year. You will likely change your mind based on user feedback anyway.
• Non-Essential Integrations: If you can manually export a CSV or perform a task behind the scenes while you test the concept, don't build a robust API or automated integration yet.

A Simple Framework for Deciding

Use the MoSCoW method to categorize features:

1. Must have: Critical for the product to function. (Include these).
2. Should have: Important but not vital for the launch version. (Save for V1.1).
3. Could have: Desirable but not necessary. (Save for later).
4. Won't have: Exclude entirely for now.

The golden rule: If you aren't embarrassed by the first version of your product, you launched too late. Focus on gathering feedback as quickly as possible, then iterate based on what users actually do, not what they say they want.