The feature they killed to save the one that mattered.

Strategy · 5 min read

Every client has a feature they're emotionally attached to. Something they've been imagining since the first day they had the idea. It's the thing they describe with the most energy. The thing they keep coming back to in meetings. The thing that lights them up.

And sometimes, that feature has to go.

I had a client who wanted to build a visual creative tool into their app. Something interactive where users could build and personalise a visual output. It was a great idea. They'd thought it through, mapped out the prompts, and could see exactly how it would work. The problem wasn't the idea. The problem was the budget.

Screen budgets force real decisions

Design packages come with a screen limit. That's the reality of working within a fixed scope and timeline. You can't design fifty screens when you've been scoped for thirty. So every feature has to earn its place. And some features take more screens than others. A simple list takes one screen. A visual creative tool takes five or six minimum, plus developer complexity that goes well beyond the design.

When we laid it all out, the creative tool would have consumed a significant chunk of the remaining screen budget. And the client had another feature, one that no competitor in their space offered, that also needed those screens. Something that would genuinely set the product apart. A differentiator that came from their own industry knowledge. The kind of thing users would download the app specifically for.

So the client made the call. They parked the creative tool. "Let's save it for version two," they said. And they put everything behind the feature that would make the app unique. That decision, more than any design choice I made, is what shaped the product.

Cutting features you love is the hardest part of MVP

Everyone talks about cutting features for MVP. But most of the advice is about cutting the stuff you don't care about. The admin dashboard nobody will use. The settings page with twelve toggles. The onboarding flow with five animated screens. That's easy. You don't lose sleep over cutting fluff.

The hard cuts are the ones you care about. The features you've been daydreaming about. The ones you've already explained to your friends and family. The ones that got you excited about building the app in the first place. Cutting those takes a different kind of discipline. It requires you to separate what excites you from what the product needs right now.

And that's the word. Right now. The feature isn't dead. It's deferred. There's a version two for a reason. But version one has to prove the concept. And it can only prove the concept if it's focused on the thing that matters most. Not the thing that's most fun to build.

The best clients make these calls themselves

I can guide the conversation. I can lay out the trade offs. I can explain what each feature costs in terms of screens, complexity, and development time. But the best outcomes happen when the client makes the call themselves. Because they know their product better than I do. They know what their users will actually care about versus what sounds impressive in a pitch.

This client didn't need convincing. They looked at the two features side by side, thought about which one would make someone download the app, and made the decision in the meeting. No back and forth. No agonising for a week. They understood that protecting the differentiator was more important than building the dream feature. And they were right.

If you're in that position right now, ask yourself one question. If your app could only do one thing well, what would it be? Whatever your answer is, that's your version one. Everything else is version two. And version two only happens if version one works.

Sources
Inspired: How to Create Products Customers Love (Marty Cagan, SVPG) - Product teams must ruthlessly prioritise for the minimum lovable product.
Building Minimum Lovable Products (First Round Review) - The features you cut define the product as much as the features you keep.

Related blog posts:

What is an MVP? →

Your app only needs one thing the others don't have →

Scope creep starts with "while we're at it" →