The Feature Cut Nobody on the Team Wants to Make

Every MVP scoping conversation has the same quiet dynamic: there's usually one feature everyone privately suspects should be cut, and nobody wants to be the one to suggest cutting it, because "I don't think we need that" sounds like it's dismissing someone's idea rather than making a scoping call. So the feature survives, the launch date slips, and three months later everyone agrees — in hindsight — that it should have been cut from day one.

The reason these conversations stall isn't disagreement about VALUE. It's that "should we cut this" is being debated as an opinion when it should be answered as a cost question: how many days does this feature actually cost to build, and does that cost make sense against a real launch date.

Turning the opinion into a number

The fix isn't better negotiation skills — it's putting a real days-to-build estimate next to every feature on the list, so "should we cut this" becomes "this costs 4 days and delays launch by a week, is that the tradeoff we want" — a completely different, much easier conversation to have, because now it's about the calendar, not about anyone's idea being dismissed.

This also surfaces the opposite case just as usefully: sometimes the "obviously non-essential" feature turns out to be genuinely cheap, and the debate was never worth having in the first place.

MVP Scope Cutter takes your real feature list and produces an actual MVP scope vs. cut list — with the exact days saved by each cut, not just a gut-feel recommendation.