Scoping & Kill Criteria

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:

1. What decision is this output going to inform? If they can't name one, the work is decorative. Don't build decorative things.
2. Who's the consumer? An exec consuming via a board deck is a different artifact than an analyst consuming via a dashboard.
3. 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 — [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 — [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.

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.