How do I decide which features to cut from my MVP?

Deciding what to cut is often harder than deciding what to build. To make the process manageable, I suggest focusing on the core value you are providing. Here is a calm, direct way to approach the pruning process:

1. Define the "Core Problem"

Strip away everything until you are left with the single, most important problem your product solves. Ask yourself: If I remove this feature, does the product still solve the primary problem for the user?

If the answer is yes, that feature is a candidate for cutting or delaying. If the answer is no, keep it.

2. Use the MoSCoW Method

Categorize your feature list to bring clarity to the chaos:

• Must have: Non-negotiable features. Without these, the MVP is broken.
• Should have: Important, but not vital for launch.
• Could have: Desirable, but can wait for future iterations.
• Won’t have: Features you are consciously choosing not to include right now.

Be ruthless about moving items into the "Won’t have" column. It doesn't mean they aren't good ideas; it just means they aren't part of this version.

3. Evaluate by User Impact vs. Effort

Plot your features on a simple 2x2 grid:

• High Impact / Low Effort: These are your MVP priorities.
• High Impact / High Effort: These are often "V2" features. They are valuable, but they take too much time to build for an initial test.
• Low Impact: Cut these immediately, regardless of effort.

4. The "One-User" Test

Imagine your ideal user sitting in front of the product. If they have to click through three features they don't need just to solve their core problem, you have built too much. Cut anything that creates "noise" or distraction from the main user journey.

5. Shift Your Mindset

Think of your MVP not as a "smaller version of the full product," but as the smallest possible experiment to see if your idea works. If you can test your hypothesis with a landing page, a manual process, or a prototype, you don't need a feature-rich app.

A final thought: You can always add features later based on actual user feedback. It is much harder to remove features once they are built and users are relying on them.

Does one of these methods feel like it would fit the stage your project is currently in?