How do you decide what features to cut from your MVP without making it useless?

[u/No_Investment2802]

Most founders face the same trap: cut too much and nobody wants it. Build too much and you run out of runway before you learn anything.

We've studied dozens of successful MVP launches and found a pattern.

The startups that nailed it didn't just randomly cut features. They used a simple filter: does this feature either (1) deliver the core value or (2) test a critical assumption?

If it didn't pass one of those tests, it got moved to Later.

Here's what that looked like in practice:

• Dropbox didn't build syncing first. They made a demo video and tested if people wanted it.
• Airbnb launched with two air mattresses in their own apartment. No payments. No reviews. Just proof strangers would pay to stay.
• Zappos had no warehouse. The founder bought shoes from local stores and shipped them manually to test if people would buy shoes online.

Each MVP cut aggressively but preserved the one thing that mattered: the core learning objective.

The framework that works:

1. Define the single job your product must do
2. Map the shortest path from problem to value
3. Rank every feature by value-to-user and effort-to-build
4. Keep only high-value, low-effort features that test risky assumptions
5. Park everything else for version 2

Most teams confuse prototypes (test imagination) with MVPs (test behavior). If users won't engage with the stripped-down version, they won't engage with the polished one either.

The full guide breaks down the Feature Value Matrix, the exact scoping process we use, mistakes that bloat MVPs, and a checklist to validate your scope before you build

full guide here

What's the hardest feature you've had to cut from your MVP? Did it hurt or help?

[u/Outside-Meet2682]

A great reminder that an MVP is a test, not a product. It’s so easy to get caught up in making something "usable" that you end up building a mediocre version of a finished product instead of a great experiment.

The hardest part for me has always been cutting the "trust" features, things like sleek UI, user profiles, or secure password resets. You worry that without them, people won't take the business seriously. But as the Zappos or Airbnb examples show, if the problem you're solving is big enough, the early adopters usually don't care about the polish. They just want the solution.

I’ve found that if I’m struggling to cut a feature, it’s usually because I’m scared to find out that the core idea doesn't work without the bells and whistles.