How a PM Decides When to Ship Fast and When to Harden a Release

As a product manager, how do you decide how hard to push for fast delivery versus how much engineering time to spend making a release robust? Describe how you handle that trade-off. ```hint Not all work fails the same way Think about what makes one change safe to ship rough and another dangerous to rush, and how the team could agree on that before a deadline forces the choice. ``` ### Clarifying Questions - Is the work on the core database engine, where a defect can lose or corrupt customer data, or on surfaces around it such as the cloud console, drivers or tooling? - Does the change ship through the managed cloud service, where a fix can reach every customer quickly, or in self-managed releases that customers upgrade on their own schedule? - Is the pressure for speed coming from a customer commitment, a competitor's launch or an internal deadline? - Would you like my general approach, a specific time I made this call, or both? ### What a Strong Answer Covers - A way to classify work by blast radius and reversibility, with a different quality bar for each class. - The qualities that are never traded for speed in a database product, and why. - Release practices that let the team ship sooner while containing risk. - How the call is made jointly with engineering and communicated to sales and customers, illustrated with a concrete example. - How shortcuts are tracked and repaid, and the signals that the balance has drifted too far either way. ### Follow-up Questions - Sales has promised a large customer a feature by a date that engineering says is unsafe. What do you do? - Your team has shipped fast for two quarters and incidents are rising. How do you reset the balance? - What metrics would tell you the team is being too cautious?