Two weeks before launch, engineering tells you the feature needs six more weeks. What do you do?

Work out what the six weeks is made of

Do not negotiate the number. Negotiating a number you do not understand is how PMs end up with a compressed estimate that fails again in three weeks, and this time with the team's trust spent. Spend the first conversation decomposing it, because six weeks is never one thing.

Ask what specifically remains, and sort each item into a category that behaves differently. Unbuilt scope can be cut. A discovered technical problem — the schema does not support the case, the third-party API rate-limits at a tenth of the assumed rate — usually cannot be cut, only worked around or accepted. Hardening, migration and rollback work can sometimes be deferred but each deferral is a named risk you are choosing to carry. Blocked work on another team is a dependency you escalate rather than solve. And "the estimate was wrong" tells you the remaining estimate is probably also wrong, so ask what would have to be true for six to become four and what would make it ten.

Ask one more thing before you leave the room: what happens if we ship on the original date with what exists today? Sometimes the honest answer is that it works for the main path and breaks on an edge case affecting a small cohort, which is a completely different decision from "it corrupts data". You cannot make the call until you know which of those you have.

Four levers, not one

Candidates who reach for "can you go faster?" have collapsed a four-dimensional problem into one. Adding people to a two-week runway reliably makes it slower, and asking a team to work weekends buys days at the cost of the next quarter.

Lever	What it looks like	What it costs	When it is the right call
Cut scope	Ship the core flow, drop bulk edit and the admin report	The cut items may never return; a partial feature can read as broken	The value is concentrated in one path and the rest is convenience
Split the release	Ship the backend and the API now, the interface in six weeks	Two integration and QA cycles instead of one	Another team is blocked on the interface, or the risk is front-loaded
Narrow the cohort	Ship on time to 5% of accounts, or to one region, or behind a flag	The launch narrative gets weaker; ops carries two code paths	You want real usage evidence more than you want coverage
Move the date	Six weeks, announced today	Credibility, dependent teams' plans, sometimes revenue	Correctness, security, money or a legal obligation is at stake

The lever you must not pull is quality below the line where the product is wrong rather than incomplete. Incomplete is a product decision; incorrect is a defect you will pay for with support load, refunds and a rebuild. State that boundary out loud in an interview, because scenario questions of this shape are frequently set up to see whether you will trade it away under pressure.

A worked triage

Suppose the six weeks decomposes like this, and the launch is a self-serve billing upgrade flow.

Remaining work, as reported          Est.   Category         Decision
---------------------------------------------------------------------------
Proration arithmetic for mid-cycle    2w    correctness      KEEP - money
Downgrade path                        1.5w  unbuilt scope    CUT - support can
                                                              do downgrades
                                                              manually at
                                                              ~30/month
Usage-based add-ons                   1.5w  unbuilt scope    DEFER to v2
Invoice PDF redesign                  0.5w  cosmetic         CUT
Rollback + reconciliation script      0.5w  risk work        KEEP - required
                                                              to ship at all
---------------------------------------------------------------------------
Kept: 3 weeks. Original runway: 2 weeks. Gap: 1 week.

Cutting has taken six weeks to three, and there is still a one-week gap, which is the realistic outcome rather than the tidy one. Now combine levers: ship the kept scope one week late to ten per cent of accounts behind a flag, ramp over the following fortnight while support absorbs thirty manual downgrades a month, and schedule the add-ons for the next cycle. Proration was never negotiable — the failure mode is charging customers the wrong amount, and that is not an incomplete feature, it is a refund programme.

Notice what made this tractable: an estimate per item and a category per item. Without the categories you are arguing about a total; with them the conversation is about five separate, small decisions, four of which the team can make with you in twenty minutes.

Telling the people who depended on the date

The slip is now a communication problem, and this is where the round is often won. Tell everyone who has a plan attached to your date on the day you know, not at the next review. A PM who sits on bad news for a week to look for a solution first has converted a schedule problem into a trust problem, and support, marketing, sales and the account team all need lead time you are spending.

Write it once, in this order: the new date and confidence in it, what changed and why it was not visible earlier, what you cut and what that means for anyone downstream, what you are doing about the risk you accepted, and what you need from whom. Give the revised date with an honest confidence, and if it is genuinely uncertain give a date for the next update instead of a fake precision. No blame on engineering — you are accountable for the plan, and a PM who visibly hangs the team out in a status note does not get an early warning next time.

If a commitment was made externally to a customer or a regulator, escalate rather than absorb it. That decision has consequences outside your scope and it is not yours to make quietly.

Why the "just cut scope" answer scores badly

Most candidates land on cutting scope within twenty seconds, and it is often right, but arriving there without diagnosis is what separates a mid answer from a senior one. The interviewer knows that in the real version of this scenario some of the six weeks is not scope at all — it is a discovered constraint, and no amount of cutting removes it. A candidate who cuts first finds out in week five that the proration arithmetic was the problem all along and the features they dropped were never on the critical path. Worse, they have spent political capital cutting things the team cared about for nothing.

The second thing being watched is whether you fix the process afterwards. A slip discovered a fortnight before launch is a signal about your visibility, not about the estimate: it means integration and hardening were left to the end, or nobody was asked what they were unsure about, or a demo of working software had not happened in three weeks. Volunteering that — and naming the specific change, such as requiring the riskiest integration to be exercised end to end by the midpoint — is what a senior answer contains and a competent one omits.

Diagnose before you negotiate: the difference between unbuilt scope and a discovered constraint decides which of the four levers is available to you at all.