Telling Stakeholders Unwelcome News: Timing, Framing and Follow-Through as a PM

Sooner or later every product manager has to tell stakeholders something they will not want to hear. In a product manager interview, you are asked how you handle that. Walk through your approach: how you decide when to raise the news, how you prepare, who hears it first and in what setting, how you frame the message, and what you do afterward. Support the approach with an example from your own experience where you can. ```hint Think about what the listener does next The moment of delivery matters less than what the stakeholder can do once they know. Work backward from the decisions they will have to make after hearing it. ``` ### Clarifying Questions - Who are the stakeholders: senior leaders I report to, partner teams whose plans depend on my work, or groups outside the product organization? - What kind of bad news should I assume: a slipped date, a cut feature, a failed experiment, or a problem that has already affected users? - Was the cause within my own team, in another team, or outside anyone's control? - Should I walk through my general approach, a specific time I did this, or both? ### What a Strong Answer Covers - Timing: raising the news as soon as it is reasonably confirmed, and how to handle news that is still uncertain - Preparation: the facts, the impact on each stakeholder, the cause, and options with a recommendation - Delivery: the headline first, the right channel and order of conversations, and ownership without blame - Follow-through: a recovery plan, a committed next update, and how trust is rebuilt - A concrete example with an outcome, including how the stakeholders reacted ### Follow-up Questions - A senior stakeholder reacts angrily and insists on the original commitment. What do you do in that meeting? - When, if ever, would you hold back bad news for a while before sharing it? - How do you deliver the news when another team caused the problem and they are in the room?