Re-Planning a Feature Launch When Its Schedule Is Halved

A product or feature you own now has to launch in half the time you originally planned for. What would you do? ```hint Not everything shrinks Before cutting anything, ask what the new date actually requires, and which steps of the plan would take just as long even if the feature got much smaller. ``` ### Clarifying Questions - Why did the date move: a customer or partner commitment, a competitor, a regulatory date, or a leadership target? - Is this a software feature that can ship and improve through later updates, or does it depend on hardware, suppliers or safety validation with fixed lead times? - How far along is the work, and is the team fixed or can I ask for more people? - Is the original scope a firm commitment to customers, or can I redefine what launches on the new date? ### What a Strong Answer Covers - Validating the new date: who needs it, what must be true on that day, and whether a partial delivery meets the need - Re-estimating the remaining work and separating fixed-duration steps from work that shrinks with scope - Scope and sequencing decisions tied to the customer outcome, with explicit non-negotiables such as safety and compliance - Stakeholder communication built on clear options and trade-offs, and knowing when to push back - Running the compressed plan: risk tracking, team sustainability, and delivering the deferred work after launch ### Follow-up Questions - Leadership insists on the full scope by the new date anyway. How do you respond? - Halfway through the compressed schedule you are behind again. What do you do? - How would your plan differ if the feature needed a hardware change rather than a software update delivered to existing customers?