Scoping a One-Week MVP

Four reasonable features that add up to three months

Here is a one-week plan that isn't one: a route optimiser, a driver mobile app, text-message arrival times for customers, and an ops dashboard. Each item on its own is reasonable. Together they are two or three months of work, started before anyone has checked whether the data supports any of it. The plan fails in a quiet way, because nothing about it looks wrong until Friday arrives with nothing to show.

What should a week buy instead? A one-week MVP proves one workflow end to end on real data. One user does their actual job with it, on the customer's actual records, and the result can be compared with how that job went before. Polish, coverage and extra features belong to week two and later, once the first week has shown the idea holds.

The scoping move that gets you there has two parts. First, three cuts: one user, one data source, one decision the software will improve. Second, two statements to the sponsor: what you deliberately left out and when it comes back, and what the demo on day five will show. The rest of this lesson tests each piece on a concrete brief.

The food distributor that asked for route optimisation

A fictional regional food distributor runs 45 delivery routes a day to restaurants and grocers. The operations director says: "Our deliveries are late and customers are angry. Build us something to optimise routes." Every number below is made up for the example.

Why the first plan has nothing to show on Friday

The tempting answer mirrors the request: "Week one: pull GPS, orders and customer data into a warehouse, build a routing engine with time windows, a driver app showing the optimised sequence, and a dashboard for the director."

Count what that needs. Four systems, and two user groups (drivers and the director) that nobody has asked anything yet. A live GPS feed of unknown quality. Probably an app install on driver phones, which means the customer's IT and likely a device policy. Any one of these can eat the week. If the GPS feed drops pings near the depot, for instance, the week is gone and there is nothing to show on Friday.

Finding the six routes that matter

Start by asking what "late" means. Say the answer is that many customers, restaurants especially, have receiving windows, such as a kitchen that accepts deliveries only from 7 to 10 a.m. Late means outside the window. Drivers' handheld scanners log arrival and completion at every stop, exported nightly as CSV, and the customer table holds each window.

Compute the baseline before cutting anything, because it tells you whether a week is worth spending and where to spend it. Over the last four weeks, 3,200 stops had a receiving window and 448 missed it: 448 / 3,200 = 14%. Grouping misses by route shows that 6 of the 45 routes account for 270 of the 448, about 60%. Those 6 routes had 1,100 window-bound stops, so their miss rate is 270 / 1,100, about 24.5%. The pain is concentrated, which is good news for a one-week plan.

Three cuts and a script

Now the cuts. The user is the dispatcher who sets each route's stop order at 5 a.m., on the assumption (to check on Monday) that drivers follow the printed order; drivers, customers and the director come later. The data source is eight weeks of scanner CSV plus the customer windows table, with no GPS, no live feed, and nothing written back into the customer's systems. The decision is the stop order on the 6 worst routes, and specifically which window-bound stops the planned order puts at risk.

The build is a script run each morning. For tomorrow's planned order on those 6 routes, it estimates each arrival from historical median drive time between consecutive stops and median service time per stop, flags stops projected to miss their window, and proposes a swap. The dispatcher gets a spreadsheet at 5 a.m. and accepts or ignores each suggestion, and every flag and decision is logged. The core of it is small enough to read in one go:

from datetime import datetime, timedelta

def flag_window_misses(start, stops, drive_min, service_min):
    t, prev, flags = start, "DEPOT", []
    for stop_id, window_end in stops:
        t += timedelta(minutes=drive_min.get((prev, stop_id), 15))
        if window_end and t > window_end:
            flags.append((stop_id, t.strftime("%H:%M")))
        t += timedelta(minutes=service_min.get(stop_id, 10))
        prev = stop_id
    return flags

day = datetime(2026, 10, 19)
plan = [("S1", None), ("S2", day.replace(hour=9)),
        ("S3", day.replace(hour=7, minute=45))]
drive = {("DEPOT", "S1"): 30, ("S1", "S2"): 25, ("S2", "S3"): 20}
service = {"S1": 20, "S2": 15}
print(flag_window_misses(day.replace(hour=6), plan, drive, service))
# [('S3', '07:50')]

The 15- and 10-minute defaults cover stop pairs with no history. In the real version you would log how often they fire, because a route full of defaults is a route the script knows nothing about, and its flags deserve less trust.

Five days, one table

Laid out by day, the week looks like this. Each row ends in something checkable, so a slip shows up on the day it happens.

The backtest numbers in that table say the flags would have caught 190 of the 270 misses, with 85 false alarms. Is that good enough? For a tool that suggests rather than decides, yes: a dispatcher can dismiss a false alarm in seconds, while a missed window costs a restaurant its morning delivery.

Saying the cuts out loud, and defining Friday

The cuts go to the director on Monday, in writing. Each one carries the week it comes back:

• Optimising all 45 routes: weeks two and three, once the time estimates hold on six.
• A driver app: only if dispatchers adopt the spreadsheet; it needs IT approval for phone installs, so the request starts in week two.
• Customer arrival texts: needs a live GPS feed, and nobody has checked that feed's quality yet.
• A dashboard: the decision log is the dashboard for now.

The demo is defined on Monday too, before any code: "Show last Thursday's six routes with the misses that happened and the ones the script would have flagged at 5 a.m., then this Thursday's live run with the dispatcher's accepted swaps." The acceptance test is the director agreeing to a four-week pilot measured by window-miss rate on those six routes, against the 24.5% baseline. Writing that sentence early matters because it is the real definition of done, and both sides know it before the work starts.

How to cut any request down to a week

The distributor case generalises into a short sequence. Start with the workflow that has the most measurable pain, using a baseline you can compute on day one from the customer's own records. If you can't compute one by Monday afternoon, the first week's MVP is the measurement itself.

Then make the three cuts. For the user, if two people could use the output, pick the one whose decision comes first in the day, since their choice shapes everyone else's. For the data source, prefer a read-only export the customer already produces over any live integration. For the decision, name the moment the user chooses something and what they choose.

Before promising anything, run a size check. A read-only export into a script and a spreadsheet fits a week. Each of these adds days to weeks: writing back into a customer system, a second user group, an app install, a security review, a new vendor contract. If the plan needs any of them in week one, it is not a one-week plan, and the honest move is to say which one you are deferring.

Use real data from day one. A demo on synthetic data proves the code runs, and says nothing about the customer's records, which is where the week's risk lives. Finally, write the cut list with when each item returns, say it to the sponsor before building, and define the demo on Monday in one sentence the sponsor agrees to.

Where week-one plans quietly become month-one plans

The expensive failure is scoping a month and calling it a week. The tells are more than one user group, more than one integration, any write-back, and anything that needs procurement or an install. An interviewer will ask, "What does Wednesday look like?" A plan that cannot answer day by day was never a week.

Cutting silently is the other big one. The director asked for route optimisation and on Friday gets a spreadsheet for six routes. Without the cut list, that reads as under-delivery. With the cut list sent Monday, the same spreadsheet reads as judgement, because the director saw the trade and agreed to it.

Two smaller failures are worth naming. A demo with no comparison ("here is the tool working") gives the sponsor nothing to decide on, so show the baseline next to the result. And an MVP chosen for technical interest over measurable pain, such as starting with the GPS feed because it is the most interesting data, spends the week where the money isn't.

Drill: the maintenance-request mess

Try a fictional brief. A property-management firm with 2,000 rental units says, "Maintenance requests are a mess. Tenants complain, technicians are double-booked, and we want an AI that handles all of it." Take 15 minutes. Write one user, one data source and one decision, then fill in a five-day table like the one above. Add the cut list with when each item returns, the one-sentence demo, and the baseline you would compute on Monday, naming the table or export it comes from.

A strong answer picks one user such as the coordinator who assigns requests each morning, one source such as the ticketing export with created and assigned timestamps, and one decision such as which technician gets which request. Its baseline is something like median hours from request to assignment. If "tenant chatbot" appears anywhere outside the cut list, cut again. Rehearse it aloud with the FDE AI coach in thita, or run it as an FDE mock round and let the interviewer push on Wednesday.

How this shows up in the interview

Scoping is a named rubric line in decomposition rounds. For Palantir, Aced reports the round asks for an MVP in roughly one to two weeks, and a Blind thread describes a London taxi prompt that asks for a deployable first cut in one week. It also shows up in take-homes, where scoping is the hidden test. OpenAI's reported take-home, per Aced, runs about a week and expects working code, a running app and a recorded walkthrough, followed by a live deep-dive. A narrow app that works and that you can defend beats a broad one with holes.

Interviewers probe it by squeezing: "You have three days, not five," or "Their IT won't approve any installs." The credit goes to cutting again, out loud, and saying what moved to week two. They also ask "why not all 45 routes?", which the 60% concentration answers. A sentence to have ready: "For week one I'd give one dispatcher a 5 a.m. spreadsheet for the six worst routes, built from the scanner export, and measure window misses against the 24.5% baseline. The optimiser and driver app come after that holds."

Check yourself

• What are the three cuts, and what was each in the distributor example? Answer: One user (the 5 a.m. dispatcher), one data source (the scanner CSV plus the windows table), one decision (stop order on the 6 worst routes).
• Why compute the 14% and the 24.5% before building anything? Answer: The baseline shows whether the problem is worth a week, points to the six routes holding 60% of misses, and is what Friday's demo gets compared against.
• The interviewer says IT won't approve any installs. What changes in the plan? Answer: Nothing in week one, because the MVP is a script plus a spreadsheet. The driver app moves later and its IT request becomes a named risk.
• Why send the cut list on Monday rather than explain it on Friday? Answer: Sent first, it lets the sponsor agree to the trade, so the narrow result reads as judgement. Explained after, the same result reads as a gap.