The most expensive scoping mistake isn’t building slowly — it’s building the wrong size. Try to deliver the whole vision in a proof of concept and you run out of time with nothing working; deliver a broad set of half-features and you prove nothing. The winning move is a single vertical slice: the one workflow, end to end, on real data, that makes the customer believe — plus the discipline to fake or defer everything else. You have a two-week budget and a wishlist. Choose what goes in the POC, and watch whether it will actually prove value in the time you have. This is the scoping discipline from the discovery handbook, made playable.
a timebox + a wishlist · include the vertical slice that proves value · fake/defer the rest · fit the budget
vertical slice
One workflow built end to end on real data — the thing that proves value. The must-have of any POC.
timebox
A fixed deadline for the POC. The best scope-cutter there is: it forces decisions about what to leave out.
must vs nice
Must-have = required to prove value. Nice-to-have = everything else, to fake or defer.
defer
Explicitly moving a request to a visible “later” list, so the customer feels heard without it eating the budget.
scope.js — least you can build that makes them believe
Scope the POC
You have a 10-day budget for the proof of concept. Toggle features in and out. The verdict checks two things: does the scope include the vertical slice that actually proves value, and does it fit the timebox? Aim for the smallest scope that clears both.
0
days used / 10
no
has the slice?
—
verdict
How it works
The simulator is a tiny constrained-selection model, and it captures the core tension of scoping a proof of concept: value versus budget. Each candidate feature has a cost in days and a role. Exactly one is the vertical slice — the core workflow, built end to end on real data — and it is the only feature that actually proves the point of the whole engagement. Everything else is a nice-to-have: a second workflow, a polished UI, auth, edge-case handling, an admin dashboard. Now the deadline bites. The timebox (here, ten days) caps the total cost, and a good scope has to satisfy two conditions at once. First, it must include the vertical slice — a POC without the core proves nothing, no matter how much polish surrounds it, because you’ve built the frame of a painting with no painting in it. Second, it must fit the budget — overload the plan and you don’t get a broad POC, you get an unfinished one, which is worse than a narrow finished one because it demos as broken. The interesting insight the model surfaces is that the best scopes are usually lean, not full: the core slice plus at most one carefully chosen nice-to-have, leaving slack. Slack isn’t waste — it’s the buffer that absorbs the integration surprises and messy data that every real deployment throws at you, and it’s what lets you actually finish. So the optimal play is almost never “use every day”; it’s “prove the value with room to spare, and put everything else on a visible later-list.” That’s why an experienced FDE, handed a long wishlist and a short deadline, spends the first move deciding what not to build — because in a POC, subtraction is the skill.
1
One feature proves the value
Of everything on the wishlist, exactly one — the core workflow, end to end, on real data — is the vertical slice that proves the point. The rest are nice-to-haves.
2
The timebox caps the total
A fixed deadline caps how much you can build. It’s not a constraint to resent — it’s the forcing function that makes you choose.
3
Two conditions to clear
A scope proves value only if it includes the vertical slice AND fits the budget. Skip the core and you prove nothing; overload and you ship nothing.
✓
Lean beats full
The best scopes leave slack — the core plus at most one nice-to-have — because slack absorbs the integration surprises every real deployment brings. In a POC, deciding what NOT to build is the skill.
Must-have
the vertical slice
Skip the core
prove nothing
Overload
ship nothing
Best scope
lean, with slack
The code
# Scoping a POC is constrained selection
budget = 10 # days (the timebox)
features = [
{"name": "core workflow (real data)", "cost": 4, "is_slice": True},
{"name": "second workflow", "cost": 4},
{"name": "polished UI", "cost": 3},
# … more nice-to-haves
]
chosen = pick(features)
cost = sum(f["cost"] for f in chosen)
has_slice = any(f.get("is_slice") for f in chosen)
proves_value = has_slice and cost <= budget # both, or it fails# leaner (more slack) = more buffer for integration surprises
Quick check
1. You scope a POC with a polished UI, auth, and an admin dashboard — but not the core workflow. What happens?
A POC exists to prove value, and value lives in the core workflow done end to end. Surrounding it with polish, auth, and dashboards while omitting the slice is building the frame with no painting — impressive-looking and completely beside the point.
2. Why is a lean scope (core slice + slack) usually better than a full one that uses the whole budget?
Real deployments always hit surprises — messy data, an auth handshake that fights you, a network that blocks egress. A scope that uses every planned day has no buffer for them and ends up unfinished. Leaving slack is what lets you actually deliver the slice you promised.
3. What is the first thing an experienced FDE does with a long wishlist and a short deadline?
In a POC, subtraction is the skill. The move is to identify the one slice that proves value, cut or fake everything else, and put the deferred items on a visible list so the customer feels heard. A tight, finished slice beats a broad, unfinished plan every time.
FAQ
How do you scope a proof of concept?
Pick the single workflow that best shows value, cut it to the smallest end-to-end slice a user could try, and timebox it. Everything else — extra workflows, polish, auth, edge cases — goes on an explicit "later" list, not into the build. A good POC does one real thing convincingly, not ten in mock-up. The question: what’s the least I can build that makes them believe it’s real and valuable?
What is a vertical slice?
One workflow built all the way through — from real input, through the core transformation, to a valuable output — rather than building every layer horizontally across the feature set. A narrow slice that actually works end to end is far more convincing than a broad set of half-working features, because it proves the whole value chain is real. In a POC, the vertical slice is the must-have; everything else is optional.
Why is a timebox useful for scoping?
A hard deadline is the best scope-cutter there is: it converts an open-ended "what should we build?" into concrete decisions about what to leave out. Without a timebox, scope creeps and the build never finishes; with one, you rank features by value-per-day, keep the essentials, and defer the rest. Announcing a demo date early is a common FDE tactic precisely because it forces the cuts.
How do you handle a customer who wants everything in the POC?
Capture every request on a visible "later" list so they feel heard, but tie POC scope to the discovery success metric and judge each ask against it: does it help prove that value, or is it a separate phase? Then say no to the timing, not the idea: "great idea — to protect the demo date, let’s put it in the next phase." A finished POC that proves one thing beats an unfinished one attempting everything, and shown the trade-off, most customers agree.