Phase two is not a graveyard.

Process · 5 min read

Every client I've ever worked with has had more ideas than their MVP can hold. That's normal. If you've been sitting on an app idea for months or years, you've had time to imagine every feature, every edge case, every nice-to-have. By the time we sit down together, you've got a fully-formed vision in your head. And then I tell you we need to cut most of it.

That conversation is always hard. Not because the client doesn't understand the logic. They do. They get that an MVP should be lean. They understand the budget constraints. They agree in principle. But when it comes to actually removing a feature they care about, it feels like giving up. Like admitting the idea isn't as good as they thought.

It's not giving up. It's sequencing. And the way you manage that sequence determines whether your project feels like momentum or sacrifice.

Why cutting feels worse than it is

When you've been living with an idea for a long time, every feature feels essential. You've imagined users relying on it. You've thought about how it connects to other parts of the app. Removing it feels like pulling a thread that unravels the whole thing.

But here's what I've seen over and over again. The features clients fight hardest to keep in the MVP are almost never the features that matter most to users. They're the features the founder is most excited about. Those are different things. The feature you're most proud of might be the one nobody uses. The feature you thought was basic might be the one that makes people come back every day.

You won't know which is which until real people use the app. And you can't get real people using the app if you're still building features that should have waited.

Make the roadmap visible

The trick I've found is to make phase two visible. Not a vague promise of "we'll get to it later." A documented, specific list of features with clear descriptions and a rationale for why they're in phase two instead of phase one. When a client can see their idea written down, acknowledged, and planned for, the sting of deferral goes away.

I had a client who wanted document scanning in the first release. It made sense for the product. Users would absolutely use it. But the development complexity was significant and it would have added weeks to the timeline. So we put it in the phase two document. Described what it would do. Noted the technical considerations. Made it real enough that the client could see it wasn't being forgotten, just scheduled.

That document became motivating. Instead of feeling like the MVP was a stripped-back compromise, it felt like version one of a bigger product. The client could see where the app was going. The roadmap wasn't a consolation prize. It was a plan.

How to decide what waits

Not every deferred feature belongs in phase two. Some belong in phase three. Some belong in "maybe never." The way I sort them is simple. Does this feature need to exist for the core experience to work? If yes, it's in the MVP. Does this feature make the core experience better but isn't essential? Phase two. Does this feature sound great in a pitch but hasn't been validated by any user research? Phase three at best.

The hardest category is the features that touch legal, privacy, or technical complexity that you're not ready to handle yet. Things like recording audio, integrating with government APIs, or building payment systems. These features aren't bad ideas. They're just ideas that need more research, more budget, and more careful design than a first release allows.

Shipping is about subtraction. The features you don't build let you ship the features that matter. Say "phase two" confidently. Mean it. And then actually build phase two when the time comes.

Sources
The First Rule of Prioritization: No Snacking (Nielsen Norman Group) - How to prioritize features that deliver real value over quick wins.
Half, Not Half-Assed (Basecamp) - Building half a product well is better than building a whole product poorly.

Related blog posts:

What is an MVP? →

The difference between a feature and a solution →

The recording problem →