How to Scope an MVP Without Losing Product Value

Written for founders, product owners and CPOs with a large product vision and a first release that can't hold all of it.

To scope an MVP is to decide which complete user journeys a first release must support, and which features, screens and audiences can wait, without breaking the product for the people it serves on day one. This article walks through how we did it on Magic Markets, a sports prediction market with an exchange order book.

Every ambitious product arrives with more ideas than its first release can hold. On Magic Markets, which we have helped shape since 2025, those ideas came from three different audiences at once, and each brought its own version of the product.

Cutting features to fit a deadline is easy. The harder part is cutting them without leaving a screen nobody can reach or a feature with nothing behind it. That starts with deciding which experience has to stay intact; how much you remove follows from it.

At Flatstudio we scope MVPs from complete user journeys, use high-fidelity wireframes to expose what a feature list hides, and agree the result with the three people who own it. The examples below come from Magic Markets.

Live product. The product is live today at magicmarkets.com. What launched differs in places from the scope described below, and that is part of the point: this article covers the scoping work we did together, including directions that were explored and set aside. Three labels mark status throughout the series: Live product for what runs on magicmarkets.com today, Design exploration for directions we designed and compared, and MVP direction for what we proposed for the first release.

TL;DR

• Products built for several audiences sprawl by default: every audience brings its own entry points, data and interactions.
• An MVP is the smallest coherent version of the product: a complete journey rather than a shortened feature list.
• High-fidelity wireframes make dependencies, missing states and alternatives visible before development, while changes are still cheap.
• Every cut is checked for coherence: no screen without an entry point, no feature without the tools it needs.
• Scope is agreed by product, engineering and design together, and nothing that is cut gets lost.

Why Do Ambitious Products Outgrow Their MVP?

Scope creep is usually described as a management failure. In complex products it often starts earlier, with the audience.

Magic Markets was designed for people with very different levels of market knowledge. During discovery we worked with three audience profiles:

• Pro users need market depth, exact prices, limits and fast control over their positions.
• Aspiring users want to grow into advanced tools without facing all of them on day one.
• Info users come to explore: live events, shifting probabilities, markets that catch their eye.

Each profile is reasonable but also implies its own product. A Pro user starts from a specific market and an open position. An Info user starts from a sport, a live match or a trending market. Even when both end up on the same market page, they arrive by different routes and expect to see different things first.

This is how a vision grows without anyone proposing a frivolous idea. Market discovery is one line on a feature list. In the wireframes it became a personalised For You view, an in-play filter, sport and league navigation, global search, and bookmarks to sports, leagues, teams or single matches, each a sensible answer to one audience's needs.

By the time the team turned to the first release, each of these features was defensible on its own. The real question was which journeys had to work completely on day one.

How makers, takers and different levels of expertise shaped the Magic Markets architecture is a subject of its own, covered in Betting Exchange UX: How to Design a Product as a Decision Tool.

What Is the Difference Between Cutting Features and Scoping a Product?

MVP scoping is the process of defining the smallest complete product experience that delivers core value to a specific audience and can realistically be built and extended.

Cutting features starts from the list: remove items until the release fits the budget. Scoping starts from the user: decide which journey has to work end to end, then keep what that journey needs.

Even the most basic task shows the difference. In Magic Markets, placing a bet could mean accepting an available price, or posting an order at your own price and waiting for someone to match it. The first needs an accessible betting flow. The second brings in price controls, available liquidity and order management, and both run on the same market. Removing advanced features was therefore only part of the work: we also had to find out which parts of the market interaction could be simplified without breaking the exchange.

A complete journey is the unit of scope. For a user taking a price on an exchange, the core journey might read: find a market, understand its price and the volume behind it, place a bet, then see whether it was matched and what position it created. Every proposed feature is then judged against that line, at one of three levels:

• Essential. Without it, the core journey breaks or a critical requirement fails.
• Supporting. It makes the journey faster or more comfortable, but the task can be completed without it.
• Future. It extends the product to new workflows, audiences or capabilities.

These labels belong to the release rather than to the feature. Saved filters are a convenience in an exploratory product and essential in a tool professionals open several times a day.

Not everything essential is visible, either. Authentication, data availability, security and regulatory requirements belong in the MVP even though no user will ever ask for them.

Why Are Wireframes a Scoping Tool?

A feature list is easy to agree on because everyone reads it differently. "Users can find and save markets" means a search bar to one person, a personalised feed to another and folders of bookmarks to a third. Engineering reads it as data relationships and persistence.

Wireframes remove that ambiguity. For complex products we work in high-fidelity wireframes: realistic content, real data density and real states, without the final visual design. The team argues about logic rather than colour, and the logic is specific enough to disagree with.

Wireframes force answers to the questions a feature list leaves open, and each answer can change the size of the MVP:

• Where does the user enter this flow, and what do they need to see there?
• What happens after the main action?
• Can they move between related objects without starting again?
• What does the screen show when a market is empty, suspended or gone?
• Which components are shared across journeys?
• Does this feature quietly add screens, settings or dependencies?

Design exploration. On Magic Markets, comparing navigation models side by side made the trade-offs plain. A persistent sidebar gave every category a permanent home at the cost of some width, while the top-bar and hybrid models hid most leagues behind hovers or stacked several navigation layers. We recommended the collapsible sidebar, with search in a modal, and the client later launched with a simpler sidebar of its own. Drawing bookmarks, meanwhile, turned a one-line feature into a structural question, which comes up again in the section on cutting scope.

Why wireframes save time and money

The case for wireframes is ultimately economic. In a complex product, a change to the logic (a new entry point, a different structure for positions, a navigation model that doesn't hold up) touches many screens and states. The later such a problem is found, the more already depends on it: polished screens, shared components, specifications and eventually code. Wireframes let a team challenge those decisions before investing in detailed UI and implementation.

So we settle what a product does before deciding how it looks. Reworking logic in a finished design rarely pays off; working it out in wireframes is part of the job.

What wireframes can't tell you

Wireframes expose incomplete journeys, conflicting requirements and interaction problems. They can't prove that people want the product, that an audience will pay for it or that an integration is feasible. That takes research, validation and engineering input.

For interactive products, wireframes also work best connected into flows rather than reviewed screen by screen. Nielsen Norman Group describes this format as wireflows.

How Do You Scope an MVP Without Breaking the Product?

Once the journeys are mapped, the cutting starts. On Magic Markets the client assessed every round of scope against its size and complexity. Our job was to make sure that whatever was removed, the rest still worked as a product: no page left without an entry point, no feature left without the tools it needs.

We run four checks on every cut.

1. Every screen keeps an entry point. A screen that exists in Figma but can't be reached is not a feature. When dedicated team pages moved out of the proposed MVP, every route that would have led to them (from search, from bookmarks, from an event) needed a new destination.

2. Every feature keeps its tools. Saving a market is only half a feature. The user also needs to find it again, tell it apart from other saved items and understand what happens when the event is over. In Magic Markets the wireframes showed how much hides behind that one line: saving sports, leagues, teams and single matches raises questions about how different objects are displayed together, what happens to them when a match ends and how the user gets back into the main journey. A simplified answer is fine for an MVP; a missing one is not. We kept basic bookmarking in the proposed MVP scope and deferred automatic grouping of saved items, so the basic return path had to work on its own.

3. Every primary action has a next step. After the user places an order, saves an item or changes a filter, the product has to respond in a way that makes sense. That might be a panel, a changed state or a confirmation rather than a new page, but the flow can't simply stop because the next screen was cut.

4. Every critical state has a decision behind it. Filters that match nothing, a suspended market, an empty list of positions, data that hasn't arrived yet. None of these needs an elaborate design, but each needs a decision. Otherwise engineering has to invent one during the build.

The same checks work in reverse. Cutting a feature but keeping the screens built around it lowers the feature count without lowering the work. When something goes, its dependencies should go with it.

Who Decides What Goes Into an MVP?

Scope is a product decision, but no single function has enough information to make it alone. Three owners have to agree.

• Product owns ambition and usefulness: who the first release is for, what value it must deliver and what the business needs to learn from it.
• Engineering owns the constraints: what data exists, which integrations are ready and what fits the timeline.
• Design joins the two. It turns ambition into journeys and checks that those journeys survive the constraints.

The roles overlap but can't stand in for each other. A designer shouldn't decide which audience matters most commercially, a founder shouldn't assume a feature is cheap because its screen looks simple, and engineering shouldn't have to make product decisions because a flow was left undefined.

Where the conflicts happen

Most scoping friction follows a few patterns. Product wants to add an audience, which brings new entry points and journeys with it. Engineering finds that a promising feature depends on data that isn't available yet, and the team has to meet the same user goal another way. Design finds a gap in a journey, and the right fix turns out to be simplifying an earlier decision rather than adding a page. Two good features compete for the same space, and the choice becomes one of hierarchy rather than priority.

MVP direction. On Magic Markets, the clearest example was the customisable For You view. The feature clearly supported the product vision, and the design made sense: a personal view built around the markets each user cares about. It was also one of the most complex pieces of the whole project. Weighed against the core journey (find a market, place a bet, see the position), the personalisation didn't have to be there on day one. The MVP kept a simpler For You page with a fixed structure, and the configurable version was deferred to a later release.

These conversations move faster when everyone is looking at the same flows. Wireframes become the shared table: nobody has to debate what "simple navigation" means when two versions of it are on screen.

What Happens to Everything You Cut?

Founders often resist cutting scope because it feels like giving up on the vision. In practice nothing is lost: the first release and the long-term product simply do different jobs. We keep three levels apart.

• The MVP. Complete journeys designed in detail: flows, states and specifications ready for development.
• The near-term roadmap. The likely next extensions, understood well enough to know their dependencies.
• The long-term vision. The broader direction, kept at concept level.

On Magic Markets the plan was to keep the agreed MVP screens in a separate Figma file, aligned with the development team's staging work. Everything explored around them, such as the personalised homepage, team and player pages, a full portfolio view and automatic grouping of saved items, stayed documented and ready to come back as the product grows.

What not to sacrifice for a smaller MVP

Some decisions are cheap to postpone. Others become expensive to reverse.

• Core data relationships. If the product is built on events, markets, outcomes and positions, how they relate has to be right from day one.
• Navigation architecture. It should serve the first journeys without blocking the planned ones.
• Workflow assumptions. An MVP can't be built on an interaction model its users don't actually work in.
• Shared behaviour. Key interactions and states should be consistent across the product rather than one-off exceptions waiting to be replaced.

You don't need to design every future feature. You do need to know which future decisions your MVP would make harder. For another example of how underlying data relationships shape an interface, see Domain Modeling Before a Single Screen.

If you are starting from a broad concept, our MVP Design & Development work starts at this point: product architecture, essential flows and a coherent design engineering can build. If the product already exists and its structure has drifted, Product Audit & Discovery looks at what is there and where it needs to change.

In Short

Judge an MVP scope by whether users can do something meaningful with the first release, whether the business can learn from it and whether the architecture leaves room to grow. How much was removed along the way says very little.

Planning a first release for a product with a large vision? Our sports analytics product design work starts from the journeys that have to survive the cut. Let's talk.