Section C · The hard parts

Scoping & Kill Criteria

The two FDE-DE muscles that win or lose deployments — turning ambiguous customer asks into shippable scope, and recognizing when a deployment should pause or reshape rather than slog on.

Scoping ambiguous asks

The customer says: "We want better visibility into our supplier obligations." That's not a scope. It's a wish.

The scoping move is to ask three questions and refuse to start work until you have answers:

What decision is this output going to inform? If they can't name one, the work is decorative. Don't build decorative things.
Who's the consumer? An exec consuming via a board deck is a different artifact than an analyst consuming via a dashboard.
What's the cheapest test that proves value? The smallest thing the customer can act on. That's your week-one ship target.

If you can't get answers to these three after one round of conversation, you have a politics problem masquerading as a scope problem. Escalate.

The scoping worksheet

When you get a fuzzy ask, run it through this worksheet before you write a line of code or promise anything.

scoping_worksheet.md

# Scoping Worksheet — [Topic / Ask]
Drafted: YYYY-MM-DD by [name]

## The ask, in their words

[Quote verbatim where possible]

## Decision this output informs

What changes if we ship this perfectly?
Who would make a different call than they make today?

→ If the answer to either is "nothing concrete," stop. Push back.

## Consumer

Who specifically will look at this?
How often?
In what format?

## Success criterion (testable)

Not "better visibility" or "more accurate." Something measurable.

Example: "Procurement analyst can identify the 10 highest-value
renewals due in the next 60 days within 30 seconds of opening
the dashboard."

## Cheapest test

What's the smallest thing we could ship in one week that would
prove or disprove the value?

→ If you can't articulate this in 2 sentences, you don't
understand the ask yet. Go ask more questions.

## What I'd ship in week 1

A concrete artifact. Bullet points.

## What I'd defer to week 2+

Things that sound related but aren't on the path to the cheapest test.

## What I'd kill outright

Things the customer might ask for but that aren't worth doing here.
Naming them out loud sets expectations early.

## Open questions

Things I still need to learn before committing.

## My recommendation

One paragraph. What I'd do. What I'd push back on. What I'd defer.

The discipline

Fill this in before you write the week's plan. The act of filling it in surfaces gaps in your understanding. The "what I'd kill outright" section is uncomfortable to write the first time — that's the signal it's the most valuable.

Kill signals

A deployment should be killed (or radically reshaped) when one or more of these conditions hold for more than two weeks. Most deployments that should die continue because no one wants to be the messenger. Don't be that FDE.

Data signals

The customer's source data is materially worse than they described. You can't deliver the SLA against the real corpus.
The customer has critical document classes you didn't know about, and they're outside your platform's range.
Re-extraction quality on remediated documents doesn't improve materially. The technique is at its ceiling.

Political signals

The executive sponsor's interest has waned visibly. They've stopped joining monthly reviews; they've delegated to a deputy who can't make decisions.
Internal customer stakeholders disagree about what "success" looks like, and the disagreement has persisted across two attempts to resolve it.
A reorganization on the customer side has put the deployment under a new leader who doesn't see its value.

Integration signals

An integration the customer needs requires platform-team work no one is going to prioritize within the deployment window.
The customer's IT / security team has gating constraints (e.g., data-residency, audit) that materially change architecture and weren't anticipated.

Velocity signals

You've slipped two consecutive milestones with no defensible explanation beyond "things take longer."
You're spending the majority of your time on customer-side coordination overhead rather than building or analyzing.
The Friday status doc has had the same "in flight" items for three weeks running.

The kill-decision worksheet

When you've identified two or more kill signals, fill this out. Bring it to internal leadership before bringing anything to the customer.

kill_decision_worksheet.md

# Kill Decision Worksheet — [Customer]
Drafted: YYYY-MM-DD by [name] · For internal review

## Recommendation

One sentence. Pause, reshape, or stop.

## Kill signals observed

List each, with evidence.

1. [Signal]: [Evidence — quote, metric, timeline]
2.
3.

## What we've tried

Each remediation attempted, with outcome.

1. [What]: [Outcome]
2.
3.

## What it would take to recover

Specific. With probability.

- [Action]: [Who'd need to do it]: [Probability of success: low/med/high]

## What we've learned

What this deployment taught us — both about the customer's
domain and about our platform — that should land in the next
deployment's playbook.

## Recommended next step

Three options:

1. **Reshape** — narrow scope dramatically; ship something smaller
   that the customer can use.
2. **Pause** — formal pause for N weeks; revisit if [trigger condition].
3. **Stop** — clean exit; document learnings; transition customer
   to lighter-touch CS engagement.

Recommendation: [pick one]

## Customer conversation plan

How we'd deliver the recommendation:
- Who joins from our side (FDE, AE, leadership)
- Who needs to be in the room from theirs
- What artifacts we bring (the learning summary, options doc)
- How we propose to land the message

## Commercial implications

- Existing contract: [obligations, refunds, credits]
- Renewal posture: [likely retain, at risk, lost]
- Expansion potential: [any silver lining]

Delivering the kill conversation

If the worksheet survives internal review, deliver the conversation to the customer. Three rules:

1. Surface internally first

Your AE, your manager, and platform leadership see the worksheet before the customer. They may push back; they may help reshape. The worst version of a kill conversation is one your AE finds out about the day it happens.

2. Bring the diagnosis, not just the verdict

"This isn't going to work" is a verdict. "Here's what we've observed, here's what we've tried, here's why we think the original scope isn't achievable, here are three options" is a conversation. Customers respond to the latter; the former damages relationships unnecessarily.

3. Offer alternatives

Reshape and pause are usually better than stop. Even when "stop" is the right call, framing it as "stop on the original scope; revisit in 90 days when X has happened" preserves the relationship. The customer should walk out of the conversation with options, not a closed door.

The kill conversation script

"I want to share what we've learned. We came into this expecting [original scope]. Over the last six weeks we've observed [evidence]. We've tried [remediation A, B, C]; results have been [outcomes]. Given that, we don't think the original scope is the best use of either of our time. Here are three options I'd want your input on..."

Calm, evidence-based, with agency for the customer. Practice this script with your manager before you use it in the room.

After the kill

Whether the deployment reshapes, pauses, or stops, document everything. The post-kill deliverables:

Learning summary for the platform team. What about this customer / domain / segment did we learn? What would we ask differently in discovery next time? What would we de-prioritize?
Customer relationship handoff plan. Even when stopping, the customer doesn't disappear — they're a reference (positive or negative), a future expansion candidate, a community-of-practice voice.
Working agreement archive. The version that captures the kill decision; what was changed, what was dropped, what was preserved.
Internal retrospective. One meeting with the platform team within two weeks. What signals did we miss? What signals did we catch in time? What's actionable.

Treat the kill as professional craft, not failure. Most senior FDEs have killed two or three deployments; the ones who haven't are usually the ones who haven't been there long enough.

✓ Check yourself

Answer from memory before opening each one.

The customer says, "We want better visibility into our supplier obligations." Which three questions do you ask, and what does it mean if one round of conversation does not answer them?

Show answer
Ask what decision the output informs, who consumes it and what the cheapest test of value is. If one round gives no answers, you have a politics problem dressed as a scope problem, and the next step is to escalate rather than build. See scoping ambiguous asks.
Why does the scoping worksheet ask what you would kill outright, including things the customer has not yet requested?

Show answer
Naming the unwanted work out loud sets expectations before the ask arrives. It is uncomfortable to write the first time, and that discomfort marks it as the most valuable section. See the scoping worksheet.
A single bad week of extraction accuracy appears on the dashboard. Is that a kill signal? When does it become one, and what do you do then?

Show answer
No. Signals count when a condition holds for more than two weeks. When you have two or more, fill in the kill-decision worksheet and take it to internal leadership. See kill signals.
In week eight the sponsor has missed two reviews, the same three items have sat "in flight" for three weeks, and one class is under SLA after two remediation cycles. What do you do first, and who sees it?

Show answer
Complete the kill-decision worksheet with evidence, what you tried and a recommendation, and take it to your AE, manager and platform leadership before the customer sees anything. A kill conversation your AE learns about that day goes badly. See the kill-decision worksheet.
Why does the kill conversation bring a diagnosis and options rather than a verdict?

Show answer
A verdict damages the relationship, while evidence, remediation tried and three options gives the customer agency. Reshape or pause usually beats stop, and even a stop is framed as stopping the original scope with a trigger to revisit. See delivering the kill conversation.
Your manager wants to stop the deployment and the AE wants to keep going to protect the renewal. What decides your recommendation?

Show answer
The worksheet evidence: the signals observed, what was tried, and the probability of recovery for each concrete action. Weigh them against the commercial implications. If recovery looks low-probability, a narrowed reshape or a dated pause usually serves both sides better than either extreme. See the kill-decision worksheet.

Takeaway

A fuzzy ask is a wish, not a scope; get the decision, the consumer and the cheapest test, or escalate.
Fill in the scoping worksheet before you plan the week, including what you would kill outright.
Kill signals fall into data, political, integration and velocity groups, and they matter when they persist more than two weeks.
With two or more signals, write the kill-decision worksheet and take it to internal leadership before the customer.
Bring the diagnosis and options to the customer; reshape and pause usually beat stop.
After any outcome, write the learning summary, the relationship plan, the archived agreement and hold a retrospective within two weeks.

A deployment that survives scoping still has to be operable by people other than you. → Runbook Templates