How to Scope an MVP: The Core-Workflow Method

TL;DR

- MVP scope is the decision about what goes in the first build and what waits, and it is the single biggest driver of how long and how much your MVP takes.

- Scope to one core workflow: the single sequence a user must complete for the idea to be worth testing. Everything that does not serve it is version two.

- Cut with one question per feature: does removing this stop us from testing the core assumption? If not, cut it. The features you cut are the cheapest you will ever build.

- A locked scope and a fixed delivery date are the same promise. You cannot commit to a date on a scope that keeps moving.

- MoSCoW and RICE help you rank; they do not tell you where to stop. The core-workflow test does.

What is MVP scope?

MVP scope is the defined set of features and workflows included in the first shippable version of a product, and, just as importantly, what is deliberately left out. Good MVP scope is narrow on purpose: enough to test one core assumption with real users, and no more. If you are still clarifying the concept itself, start with what a minimum viable product is.

The short answer

Cut your MVP to one core workflow, the single thing a user must be able to do for your idea to be worth testing, and build only the features that workflow needs. Then lock it. A scope you keep reopening is a scope that cannot ship to a date.

Most founders scope by addition: they list every feature they can imagine and ask which to include. That is backwards. Scope by subtraction: start from the one workflow that proves the idea and add only what that workflow cannot run without. Eric Ries built the whole Lean Startup argument on this: the MVP is the version that lets you start the learning loop with the least effort, not the version that impresses.

The core-workflow method

This is a method a non-technical founder can run in an afternoon. Four steps.

Step 1: Name the one core workflow

Write down the single sequence a user must complete for your product to have any value. For a marketplace it might be "find a listing, book it, pay." For a SaaS tool, "import data, run the analysis, see the result." If you cannot state it in one sentence, you have not found it yet. Everything else in your product exists to support or extend this one path.

Step 2: List every feature, then test each against the workflow

Dump the full wishlist. Then run every item through one question: if we remove this, can a user still complete the core workflow and can we still test our core assumption? If yes, it is out of the MVP. Not deleted: parked on a version-two list, where most of it belongs.

Step 3: Keep the supports, cut the extensions

Some features are not part of the workflow but the workflow cannot run without them: auth so a user has an account, a payment step if money changes hands. Keep those. Everything that makes the workflow nicer, faster, or broader (settings pages, dashboards beyond the core screen, second and third workflows) is an extension. Extensions are version two.

Step 4: Lock it and write it down

A scope that lives in conversation drifts. Write the included features and the parked features into a one-page scope document, and treat additions as trade-offs, not free wins. Every feature added after lock either moves the date or pushes something else out. Naming that trade-off out loud is what keeps a timeline honest. That written lock is the same discipline behind how we work.

A worked example

Say you are building a tool that helps freelancers send and track invoices. The wishlist has fifteen features: invoicing, recurring invoices, expense tracking, multi-currency, client portal, reminders, reports, tax export, team seats, and more. Run the method. The core workflow is "create an invoice, send it, know when it is paid." That needs: create-invoice, send, a paid/unpaid status, auth, and one email integration. Five things. The other ten (recurring, expenses, multi-currency, reports, seats) are extensions. They go on the version-two list. You just turned a six-month build into a three-week one without cutting anything that tests the idea: will freelancers switch to your tool to get paid?

For SaaS-shaped products specifically, the same cut applies; see our SaaS MVP walkthrough once the workflow is named.

Why scope equals your delivery date

Here is the connection most scoping guides miss. A fixed delivery date is only possible on a fixed scope. You cannot overlap design and build, the trick that compresses a timeline from months to weeks, if the requirements are still moving, because every change ripples through work already in progress.

This is why an open-scope, time-and-materials engagement cannot credibly promise a date, and a locked-scope one can. The fixed scope and the fixed date are the same promise wearing two hats. It is also the whole reason a 21-Day MVP Development model can commit to 21 days: the scope is locked on day three and not reopened. See how that plays out day by day in our 21-day MVP timeline. For the contract side of that promise, read fixed-price vs time and materials.

Where frameworks fit (and where they don't)

MoSCoW (Must, Should, Could, Won't) and RICE (Reach, Impact, Confidence, Effort) are useful for ranking features once you have a list. Productboard and Railsware both cover those frameworks well. But ranking is not scoping. A ranked list still tempts you to include the top "shoulds," and shoulds are how scope creeps. The core-workflow test gives you a hard line: if it is not a must for the one workflow, it is out, regardless of how high it ranks. Use frameworks to order your version-two backlog, not to decide the MVP line. Intercom's Des Traynor has made the same point for years: start from the job, not the feature pile.

An MVP is also not a prototype or a proof of concept. Those answer different questions; the lines are drawn in MVP vs prototype vs proof of concept. When you are choosing who helps you hold the line, use how to choose an MVP development company.

Not sure where your MVP line is?

Book a free scoping call. We will name your one core workflow, tell you which three or four features actually test your idea, and give you a locked scope you can build to a date.

Frequently Asked Questions

What is MVP scope?

MVP scope is the defined set of features and workflows in the first shippable version of a product, and what is deliberately left out. Good scope is narrow on purpose, enough to test one core assumption with real users and no more.

How do you define the scope of an MVP?

Name the one core workflow a user must complete for the idea to be worth testing, then include only the features that workflow cannot run without. Test every other feature with one question: if we remove it, can we still test the core assumption? If yes, it is version two.

What should be included in an MVP scope document?

The one-line core workflow, the list of included features, the parked version-two features, the core assumption being tested, and the definition of done. One page is enough; the value is in the decisions, not the length.

Why is MVP scope so important?

Because scope drives both cost and timeline. An open scope makes a build expensive and slow; a locked scope is what makes a fixed delivery date possible. The scope and the date are the same promise.

Should I use MoSCoW or RICE to scope my MVP?

Use them to rank your version-two backlog, not to draw the MVP line. Ranking still tempts you to include high-scoring extras. The core-workflow test gives a harder line: if it is not required for the one workflow, it is out.

Can MVP scope change after it is set?

It can, but every change is a trade-off, not a free add: it moves the date or pushes something else out. Lock the scope, write it down, and treat additions as explicit swaps so the timeline stays honest.