Almost every product starts as a long wishlist. Someone has imagined the finished thing, and the wishlist is a snapshot of that imagination: dozens of screens, every report anyone might want, every nice-to-have toggled on. The wishlist is useful, but it is not a plan. The work of slicing an MVP is turning that flat list into three buckets, Build Now, Future, and Backlog, in a way that gets a real user to a real outcome as fast as honestly possible. This note is the method I use, and it pairs directly with the zero-to-one play for going from a hypothesis to working software.

Start from the thinnest end-to-end slice#

The first instinct most teams have is to grade each feature on importance and keep the top third. That produces a pile of important fragments that do not connect into anything a person can actually use. Instead, I start from a different question: what is the thinnest path a user can walk from the front door all the way to a single valuable outcome?

That path is your spine. It almost always crosses several feature areas, but it only needs the thinnest capability in each one. Everything that is not on the spine is a candidate for deferral, no matter how appealing it looks on the wishlist. If I can get one user to one genuine result end to end, I have something to learn from. A dozen half-built areas teach me nothing.

Cross-cutting platform capabilities usually belong in the MVP#

There is a category of features people are tempted to defer because they are not exciting, and that instinct is usually wrong. These are the cross-cutting platform capabilities that the whole product stands on:

• Secured login and a real authentication boundary
• Role-based access, even a simple two-role version
• Search and lookup so users can find their own data
• Mobile-friendliness, because you rarely know which device the first users will reach for
• A core dashboard or landing view that orients the user and ties the slice together

These feel like infrastructure, and they are, but retrofitting them later is painful and sometimes architectural. Access control bolted on after the fact tends to leak. A search experience added late forces you to rethink how data is shaped. Mobile retrofits ripple through every screen. Building the thin version of each of these up front is far cheaper than adding them once the product has shape. The keyword is thin: the MVP gets one simple flavor of each, not the fully configurable enterprise version.

Polish usually defers#

The flip side of cross-cutting basics is polish, and polish is where the wishlist gets long. These are features that improve an experience the product can already deliver without them:

• Theming and dark mode
• Advanced or custom reporting beyond the one view that matters now
• In-app notifications and alerts
• Deep analytics, what-if exploration, and configurability layered on top of a feature that already works

None of these are bad ideas. They are simply not on the critical path to proving the product is worth building. They go in Future or Backlog, and they earn their way back in when real usage tells you which polish actually matters. Guessing now wastes the budget you will wish you had later.

Keep only the thinnest capability per area#

When a feature area survives the cut, resist the urge to bring its whole subtree along. Most areas on a wishlist fan out into a parent capability and a cluster of advanced children: a management view with five power-user tools hanging off it, an analytics area with six different lenses. For the MVP, keep the parent and the single most essential child. The rest of the subtree is Future.

This is the discipline that keeps an MVP an MVP. It is easy to defer an entire area; it is much harder, and much more valuable, to keep an area but take only its thinnest useful slice. That is usually where the real over-scoping hides, not in the obvious extras but in the depth of the areas you decided to keep.

A working method#

Concretely, here is how I run the cut:

1. Draw the spine. Trace one user from entry to a single valuable outcome and list every area that path touches.
2. Pull the platform basics into Build Now. Auth, roles, search, mobile, and a core view, each in its thinnest form.
3. For every area on the spine, keep one capability. Park the rest of that area's depth in Future.
4. Move all polish to Future or Backlog. Theming, advanced reporting, notifications, and exploratory analytics wait.
5. Sanity-check that Build Now still connects end to end. If the cut broke the spine, you cut too deep; add back the smallest thing that reconnects it.

The output is three honest buckets and a Build Now list that a small team can actually ship, with a user reaching a real outcome at the end of it. Everything you deferred is still written down, still visible, and ready to be reconsidered once usage, not imagination, is telling you what to build next.