The Quick-Tweak Scope Triage Playbook

Use this playbook when someone asks for a "small change," "quick tweak," or "just add," and you suspect the true cost is hidden.

Typical triggers:

• A read-only view is asked to become interactive [2406].
• An existing analysis is asked to cover more than it was built for [2411].
• A feature is asked to serve a different audience or context than it was designed for [2415].
• The request is open-ended and could mean several different things [2393].

Classify the request before estimating. Blast radius, not wording, sets the class.

Name these up front so re-scoping is not improvised.

• Scope owner: runs this triage, owns the call to classify a request as net-new.
• Technical lead: owns the migration / API / cross-platform estimate and confirms blast radius.
• Client / stakeholder contact: owns the conversation that locks options and communicates a re-scope.

Read first. Do not estimate or build until every question below has an answer.

[ ] 1. Does it need a DB / SCHEMA MIGRATION? If storing new state
       (e.g. a new perspective on existing data) is required, it is
       net-new, not a tweak. [2411]
[ ] 2. Does it touch EVERY SURFACE the feature already appears on?
       A change to a platform-wide feature must be built and
       regression-tested on each screen. [2406]
[ ] 3. Does it change a READ-ONLY view into an INTERACTIVE one?
       Interactivity is a materially larger feature than display. [2406]
[ ] 4. Is the AUDIENCE or CONTEXT different from the original design?
       A feature built for a community behaves differently for a
       solo user. [2415]
[ ] 5. Is the request VAGUE or open-ended? If it could mean several
       things, it is not ready to estimate. [2393]
[ ] 6. Is this really ONE feature, or several phases bundled together?
       Bundled future phases inflate the current scope. [2431]

Match what you observe to the diagnosis, then take the branch.

Apply the least invasive response that fits the diagnosis. Escalate up the list only as blast radius grows.

1. Clarify the request into concrete, locked options. Turn an open-ended idea into a small set of explicit choices (for example: external link, in-app replay, or both), let the stakeholder pick one, and record that choice as a locked requirement before any build starts [2393].
2. Estimate as separate cross-platform slices. Break the work into backend, web frontend, mobile frontend, and admin panel, each with its own effort, so the true cross-platform cost is visible instead of buried inside the mobile or admin line [2401].
3. Fence a standalone specification that excludes future phases. Scope the work as its own spec that explicitly excludes unrelated future-phase features, so it can ship independently and scope does not bleed in from later phases [2431].
4. Classify as net-new and re-scope. When the request needs a schema migration, touches every surface, or serves a new audience, stop treating it as a tweak — reclassify it as a new feature and re-scope the estimate and timeline accordingly [2411][2406][2415].

Escalate to the stakeholder contact, and say no or defer, when:

• The request needs a schema migration, a platform-wide build, or a new audience, but was booked as a tweak — re-scope before committing [2411][2406][2415].
• The request is still vague after one clarification pass — defer the estimate until options are locked [2393].
• Future-phase features are being folded into the current ask — defer them into a separate phase and fence the current spec [2431].

Say no to building against a vague request. Defer, rather than guess, until the choice is locked and the spec is fenced.

Confirm the classification held before work begins and after it ships.

• Confirm the locked option matches what was recorded, not a later reinterpretation [2393].
• Confirm each cross-platform slice — backend, web, mobile, admin — was estimated and built separately, with none hidden inside another [2401].
• Confirm a platform-wide change was regression-tested on every surface it appears, not just the one that prompted the request [2406].
• Confirm the fenced spec still excludes the future phases it was written to exclude [2431].

Recovery from a mis-classified tweak is complete only when the work has been re-scoped as a feature with its slices and migration accounted for.

Capture, in the scope record:

• The locked option and the date it was chosen [2393].
• The per-slice estimate: backend, web, mobile, admin [2401].
• The blast-radius finding: migration required, surfaces touched, or audience changed [2411][2406][2415].
• The fenced spec and its explicit exclusions [2431].

Stakeholder comms template:

What you have described is a new feature, not a tweak. It needs a database change and touches every screen the feature already appears on, so each screen has to be built and tested separately. We will scope it on its own, exclude the later phases, and give you an estimate broken out by backend, web, mobile, and admin so the real cost is visible. No work will start until you have picked and confirmed the option you want.

Capture what would have caught the scope creep earlier:

• Which triage question first exposed it — migration, surfaces, audience, or vagueness [2411][2406][2415][2393].
• Whether the request was estimated before options were locked; if so, lock first next time [2393].
• Whether cross-platform slices were made visible up front, or discovered mid-build [2401].
• Whether the spec was fenced against future phases before work began [2431].

Lock in the rule: a request that needs a schema migration, hits every surface, or serves a new audience is net-new — classify it that way before you estimate it.