⏰ Deadline Vocabulary

Option B defines "hard deadline" correctly. Key characteristics: (1) external consequence — missing it has real costs (contract breach, legal penalty, public embarrassment, lost revenue), (2) non-negotiable date — the date cannot move; scope must adjust to fit it, (3) correct response — when faced with a hard deadline, the professional action is to reduce scope ("what can we cut to ship on time?"), not extend the date. Examples of hard deadlines: GDPR compliance date, earnings report, trade show demo, regulatory filing. Contrast with "soft deadline" — a preferred target date that has some flexibility. A hard deadline facing a feature that isn't ready leads to MVP scoping, cutting non-essential features, or shipping with known limitations under a feature flag.

Option B correctly explains "soft deadline." Key points: (1) no severe external consequence — missing a soft deadline is inconvenient but not contractually binding or catastrophic; it's often an internal goal, (2) planning flexibility — teams can use soft deadlines as anchoring targets while allocating capacity to hard deadlines first, (3) communication matters — calling something a "soft deadline" signals to engineers that scope negotiation is possible; calling it "hard" signals it's immovable. Common phrasing: "ideally by Q2," "targeting end of March but flexible," "nice-to-have by v2.0." The professional skill is distinguishing which deadlines are truly hard (external, contractual) vs. soft (internal targets, roadmap aspirations).

Option B correctly defines "time-box." Essential concepts: (1) fixed duration, variable scope — the inverse of a deadline. Instead of "finish this work by date X," time-boxing says "work on this for duration Y, then stop," (2) stops overruns — particularly useful for open-ended work (research, refactoring, bug investigation) that could expand indefinitely, (3) Scrum context — sprints themselves are time-boxes: two weeks of work, ship what you can, retrospect and repeat, (4) acceptable incomplete — time-boxed refactoring that improves 60% of the codebase is a success; the alternative is an unbounded refactor that blocks feature delivery for months. Professional phrasing: "time-box the spike to 4 hours," "I've time-boxed my investigation to Friday morning," "we're time-boxing the prototype to one sprint."

Option B correctly interprets "ship by Q2." Breaking down the phrase: (1) "ship by" — a deadline boundary phrase; the feature must launch before this point, not exactly at it, (2) "Q2" — second financial quarter; in most companies this is April–June (Q1: Jan–Mar, Q2: Apr–Jun, Q3: Jul–Sep, Q4: Oct–Dec), though some companies use different fiscal year starts, (3) implicit target — "ship by Q2-end" means June 30 is the latest acceptable date; shipping earlier is better, (4) hardness varies — "ship by Q2" is soft unless it's on a public roadmap, in a sales contract, or tied to an investor commitment. Related phrases: "targeting Q3," "GA in Q4," "MVP by end of H1" (first half = Q1+Q2).

Option B correctly interprets a conditional commitment. This is a key professional communication pattern: (1) conditional commitment — "I can do X IF Y" is not a hedge or evasion; it's precise communication of a dependency, (2) PM's responsibility — when an engineer names assumptions, the PM should: (a) validate the assumptions where possible ("I'll confirm the API docs are up-to-date"), (b) prepare a contingency ("if Friday slips due to the API, we'll scope down to X feature"), (3) vs. unconditional commitment — "I'll have it done Friday, no caveats" sounds stronger but hides risk; when the API docs turn out to be wrong, the PM is blindsided, (4) cultural note — in UK engineering culture, naming assumptions is expected professional practice, not a sign of low confidence. The phrase "assuming [condition]" protects both engineer and PM.