Illustrative. This lesson continues the composite engagement from Discovery: the regional logistics company, the compliance holds, the confident veteran dispatcher. The dialogue is invented to teach the move and contains no statistics.
Discovery gave you a reframe: the real problem isn't slow lookups, it's that a fifteen-year veteran routes hazmat from memory, is sometimes wrong, and nobody catches it. Scoping is where you turn that reframe into a system you'll actually commit to build. Harder, it's where you say no to the three nearby things that aren't it.
The engineer's failure here is the opposite of discovery's. In discovery you rushed to build; in scoping you're tempted to build everything: the reframe plus the original request plus two good ideas that came up. A scope that tries to do all of it ships late, demos as mush, and moves no number.
Before reading on
You're back with the VP. On the table: (a) the routing-check system from discovery, (b) the Q&A assistant they originally asked for, (c) a dashboard the VP mentioned wanting, and (d) auto-correcting the routes instead of only flagging them.
Which one do you commit to, and how do you say no to the other three without losing the room?
You commit to (a) and only (a) for the first version. You say no to the rest by tying each "no" to the outcome the VP already told you matters. Watch how.
Move 1 — commit to the one thing
The outcome is fewer compliance holds. Exactly one of those four options moves it directly: catching the risky routing decision as it's made. So that's the commitment, stated plainly:
You: "Here's what I'd build first: a check that watches a routing decision at the moment it's entered and flags the ones that look risky, before the shipment moves. That's the thing that reduces holds. I want to ship that, well, before we build anything else."
Naming the first version narrowly is not timidity; it's how the thing that matters gets built well while it still has your full attention. And it gives every "no" that follows a reason.
Move 2 — say no by subtraction, with a because
Now the three noes. Each one is refused by holding up the outcome, not by arguing preference:
VP: "What about the Q&A assistant I originally asked for?"
You: "We can add it later, but on its own it doesn't move holds. We learned that on the floor. The people who'd use a lookup tool are already the careful ones. Let's not spend the first eight weeks on the version that demos well and doesn't change your number."
VP: "And the dashboard?"
You: "Worth doing, once the flagging works. A dashboard of a system that isn't catching anything yet is a dashboard of zeros. Let's earn the data first, then show it."
VP: "Why just flag? Why not auto-correct the route?"
You: "Because a system that silently reroutes a fifteen-year veteran's shipment is the fastest way to get the whole thing turned off. We flag, a human decides, and we earn the trust to automate later, if the data ever says we should. Auto-correct is a version-three conversation, and only if flagging proves itself."
Every no landed on the outcome or a constraint you found in discovery. None was "I'd prefer not to."
Bad / Good / Great — presenting the scope
Bad — "we'll build all four; here's the timeline." You said yes to everything, which reads as either inexperience or a fear of pushing back. The build will be late and unfocused, and when it slips you'll cut the wrong thing under pressure.
Good — "let's start with the flagging system and phase the rest." You led with the right first thing and implied the sequencing. Solid. The gap: you didn't defend the cuts, so the VP doesn't yet own the reasoning, and the Q&A assistant will be back on the table next week.
Great — "one thing first: the flagging system, because it's the only option that moves holds. The Q&A tool doesn't touch the number, the dashboard needs data we don't have yet, and auto-correct would get us switched off before we earn trust, so those are later, in that order, each with a trigger." You committed, you cut, and every cut was anchored to their outcome. Now the scope is a shared decision, not your preference, and it'll survive the next meeting.
The probe to expect
VP: "My leadership expects something impressive to demo. A single flagging feature sounds thin."
You: "I hear that. Here's the demo that lands: a real routing decision going in, the system quietly catching one that would've been a hold, and a hold that didn't happen. That's more impressive to your leadership than a chatbot, because it's the number they care about, moving. Impressive-to-demo and impressive-to-your-boss aren't always the same thing, and I'd optimize for the second."
VP: "My boss will ask where the AI is. A flag that says 'risky' looks like a spreadsheet rule. Where's the AI he approved?"
You: "Fair. That's a presentation problem rather than a scope problem, so let's solve it without building the wrong thing. In the demo, when it flags a route, show why: 'this matches a hazmat reclass that changed in March. Here's the rule and the shipment it caught,' the reasoning a spreadsheet can't do. That reads as AI, on the one feature that moves your number. Making the real thing legible as AI beats building a flashy chatbot that looks like AI and changes nothing. If he still wants a showier surface after that, we scope it as a follow-on once the flagging is earning its keep. I just wouldn't lead with it."
VP: "Showing the reasoning is still one text box. My boss sat through six vendor demos with agents and dashboards, and I walk in with a route that turns red? I need something that looks like what we paid for, or I'm the one who bought a rules engine."
You: "Fair. That's a real thing to be on the hook for, and I won't make you carry it on optics alone. So here's a genuine give: I'll add one visible surface to v1, a live board that counts holds-avoided as the flags fire, so the demo isn't a red route, it's a number climbing that your boss can't get from a spreadsheet. That's real scope, about a week of build I hadn't planned, and I'd rather spend it than watch the thing that works die because it demoed thin. I'll give you a real surface instead of the fake one. The chatbot, I still won't build."
The move: this time you actually gave up scope, a week of work you'd rather not spend, because the VP's standing with his boss is a real constraint, not merely noise. That's what separates a real concession from a token one: it costs you something. You held the line on the useless chatbot and conceded a genuine, useful surface. When a customer's neck is on the line, "trust the substance" isn't enough. You buy down their risk with something real.
From scope to architecture
The architecture now falls out of the one thing you kept, shaped by the constraints discovery surfaced:
- It watches decisions as they're made → it hooks into the routing entry point, not a separate chat app the veteran would never open.
- It must not feel like surveillance → the flag is quiet, addressed to the dispatcher first, framed as a second look and not a report to management. That social constraint is a real design requirement, and you note it now so it isn't bolted on later.
- A human decides → the system flags and explains; it never reroutes on its own in v1. That's a guardrail, and it's also the thing that makes adoption possible.
- You have to know it's working → from day one, it logs the flags and the outcomes, so you can show holds-avoided later. That's the evaluation and observability baked in from the start.
You didn't draw the architecture and then justify it. You kept one outcome, let the discovery constraints pick the shape, and the boxes were nearly forced. That's exactly the derive-don't-display move the system-design round grades.
The transferable pattern
Commit to the one outcome, then cut everything else out loud with a reason the customer gave you, and let the architecture fall out of what you kept. A scope is a defended list of noes; an architecture is the shape the surviving outcome forces. Do both from the outcome, and you build the right thing once instead of the whole wish-list badly.
Next: Translating to ROI & Risk. You've committed to a scope. Now put it in the customer's terms of money and risk so they can defend it upward.NextTranslating to ROI & Risk