How to Scope an MVP in One Week

Almost nobody misses an MVP deadline because the design was slow. They miss it because the thing being built was never four weeks of work, and nobody said so out loud until week three.

Scope is the failure mode. It is also the cheapest thing to fix, because fixing it costs a week of thinking rather than a month of building. This is the method we use for that week, written so you can run it yourself.

Quick Summary (Key Takeaways)

• Scope kills MVPs, not execution. The build was fine; the list was too long from the first day.
• One core flow, one platform, one user role. Every extra role is roughly another product.
• Write the plan before the backlog. A backlog is a list of wants. A plan is an argument about order.
• Cut by moving work out of the product, not out of the flow. A human doing it manually for the first fifty users is a feature, not a failure.
• Decide what would prove you wrong. If no result would change your mind, you are building a demo, not an MVP.
• A week is enough. Longer discovery is usually avoidance dressed as diligence.

Why MVPs Get Too Big

Four causes, and none of them is laziness.

• The founder is answering investor questions, not user questions. Investor decks reward breadth. Products reward one thing working.
• Every stakeholder adds one small thing. Five people adding one small thing each is a second product.
• Admin is invisible until it is not. Somebody has to approve, refund, moderate or fix. That is screens nobody scoped.
• Nobody wrote down what the MVP is testing. Without that, there is no principled reason to say no to anything.

The One-Week Method, Day by Day

Five days, one designer or product person, and the founder available for two sessions. The output is a written plan, not a Figma file.

Monday: The Bet

One session, ninety minutes. Write down, in one sentence each: who this is for, what they do today instead, and what has to be true for the product to work. That last one is the bet. Everything in the MVP exists to test it, and everything that does not test it is a candidate for cutting.

End of day you should be able to finish this sentence: "We believe [these people] will [do this thing] because [reason], and we will know within [time] by looking at [signal]."

Tuesday: The Core Flow

Map the single path from a person arriving to the moment the product has delivered its value once. Not the whole app. One path, end to end, including the boring middle.

Most products have exactly one of these, and most teams cannot draw it on the first attempt. That difficulty is the point of the exercise. If two paths seem equally central, you have two products and should pick one.

Wednesday: The Cut

Take everything that is not on that path and sort it into three piles: before launch, after launch, and never. Be aggressive with "never"; it is the only pile that saves real time.

Then apply the four cuts below, which do most of the work.

Thursday: The Shape

Now, and only now, decide what it is made of. How many screens the core flow actually needs, which of them are new, which are variations of one screen with different content, and where the product has to talk to something external.

Count roles here. An admin who approves things is a second interface, and it is the single most commonly forgotten one.

Friday: The Plan and the Number

Write it down: the bet, the flow, the screen list, the cuts and why, the sequence, and an honest estimate. If the honest estimate is nine weeks, the plan says nine weeks. A plan that flatters the calendar is worse than no plan, because it converts a scoping problem into a delivery failure two months later.

Four Cuts That Do Not Gut the Product

Cutting features is the obvious move and usually the wrong one, because it removes the thing that makes the product worth using. These four remove work without removing value.

• Do it by hand. Matching, moderation, onboarding, approvals - a person doing this manually for the first fifty users buys you weeks and teaches you what the automation should actually do.
• One platform. Web or native, not both. Cross-platform is not twice the work, it is more, because the two diverge under real use.
• Defer the second role. If both a user and an admin need an interface, ship the user's and run the admin's side out of a spreadsheet for a month.
• Skip settings. Almost every settings screen in an MVP is a decision the team did not want to make. Make the decision and delete the screen.

Signs Your MVP Is Still Too Big

• You cannot describe the core flow in one sentence without an "and".
• There are two user types with different screens.
• The word "dashboard" appears before the product has data to put in one.
• Nobody can say what result would make you stop.
• The screen list has grown since the last time you looked at it, and nothing was removed.

What the Plan Should Contain

Six things. If it has all six it is a plan; if it has three it is a wish list.

• The bet, in one sentence, with the signal that settles it.
• The core flow, drawn end to end.
• The screen list, with new versus variation marked.
• The cuts, with a line on why each one is safe to defer.
• The sequence, so work can start Monday without another meeting.
• An honest timeline, including the parts that are not design.

The plan is the deliverable. It should be useful to whoever builds the thing, including a team that is not the one who wrote it.

Doing It Yourself Versus Buying the Week

Run it yourself if you have someone who can hold the room and say no to the founder. That is the actual requirement, and it is a personality more than a skill.

Buy it if the scope argument is already going in circles internally, if nobody can play referee, or if you want the estimate to come from people who will also have to deliver it. Ours is Discovery Week: one week, $3,500, and the plan is yours to keep, including if you take it to another team. If you then start the four-week build with us, the fee comes off it.

Either way the week is the cheap part. It is the month afterwards that costs money, and this is the only reliable way we know to stop that month from being spent on the wrong thing.

Frequently Asked Questions

How long should scoping an MVP take?

About a week for most products. Less and you are guessing; much more and you are avoiding the build. The exception is genuinely regulated or hardware-adjacent products, where the constraints take longer to surface.

What is the difference between a plan and a backlog?

A backlog lists what could be built. A plan says what will be built, in what order, and what has been deliberately left out. The second one is what stops scope creep, because it records the reasons.

How many screens should an MVP have?

Wrong question, and it is the one most quotes are built on. The number falls out of the core flow and the number of user roles. One role with a clear flow is usually somewhere between eight and fifteen screens; two roles roughly doubles it.

Should the MVP look finished?

It should look trustworthy, which is not the same thing. Users forgive missing features and do not forgive an interface that looks like it might lose their data. For anything investor-facing, that difference has a price.

What if scoping says the MVP is not four weeks?

Then you have saved yourself the four weeks. The right response is to cut until it fits or to plan for the real length, not to start and hope.

Conclusion: Decide the Bet, Then Cut to It

An MVP is not a small product. It is a specific question with just enough product wrapped around it to get an answer. Write the question down first and most of the scope argument resolves itself.

Then be harder on the list than feels comfortable. The features you defer are still there next month; the month you lose to a bloated first build is not.

If you want the week run for you, Discovery Week is how we do it. If you would rather compare who else could, we keep an honest list of product design agencies and one for AI startups.