Most leadership advice is written for peacetime. It assumes you have time to consult, space to experiment, and trust already in the bank. Crisis leadership operates under different conditions. Resources shrink, decisions land faster than data can support them, and the team is watching your face to decide how worried they should be.

The shift from peacetime to wartime leadership is not just a change of pace. It is a change of mode.

Peacetime optimizes for creativity, consensus, and long-term thinking. Wartime optimizes for speed, survival, and clarity of direction. Knowing when to switch modes and how to do it without destroying trust is one of the rarest skills in product leadership.

This lesson covers the full arc of leading through a crisis: the mindset shift, what survives when resources are cut, how much truth to share with the team, how to manage up when the C-suite is also under pressure, and how to protect your judgment when exhaustion is eroding it. The product leaders who navigate these moments well are rarely the ones who know the most frameworks. They are the ones who could think clearly, communicate honestly, and take care of themselves well enough to keep making good decisions.

How peacetime and wartime product leadership differ

Every product organization operates in one of two modes:

  • Peacetime: It’s the default. The company is growing, resources are relatively stable, and the job is to optimize, experiment, and empower teams to find the best path forward. As a leader, you should encourage debate, tolerate ambiguity, and give teams autonomy over how they reach goals.
  • Wartime: A competitor launches a product that undercuts your core offering, funding dries up overnight, or a global event disrupts your entire market. In these moments, the leadership behaviors that work well in peacetime start to fail. Make decisions faster than full consensus allows, communicate direction more directly, and tolerate less deviation from the critical path.

This is not about becoming authoritarian. It is about recognizing that speed and survival require a different set of tradeoffs than growth and creativity.

The mistake most product leaders make is applying peacetime instincts to wartime conditions, or wartime instincts to peacetime ones. A team that thrives on autonomy will feel micromanaged if you suddenly shift to command-and-control during a stable period. A team navigating a genuine crisis will feel unsupported if you stay in consensus mode when the situation demands clear direction. Reading the environment correctly and adjusting your style to match it is what separates a resilient leader from a reactive one.[1][2]

Use Keep/Stop/Start to reprioritize work in a crisis

Use Keep/Stop/Start to reprioritize work in a crisis

When a crisis hits, teams often default to one of two failure modes.

  • Paralysis: everyone waits for direction while the situation worsens.
  • Thrashing: everyone stays busy doing the same things they were doing before, hoping the problem resolves itself.

Neither approach works. What leaders need is a structured way to rapidly re-evaluate what the team is working on and realign effort around what actually matters now.

The Keep/Stop/Start framework gives you that structure. It is a simple three-part audit you can run with your team when the context has shifted and the old priorities no longer match the new reality:

  • Keep refers to the work that still matters and should continue without interruption. These are the activities directly tied to survival or core value delivery.
  • Stop is for the work that made sense in a previous context but no longer justifies the cost, time, or attention it demands. Stopping things is harder than it sounds. Teams develop emotional attachment to projects, and stopping them can feel like failure. But in a crisis, unfinished low-priority work is a drain on energy that could go elsewhere.
  • Start is for new work the crisis has made urgent, whether that is a retention program, a faster release cycle, or a different communication rhythm with customers.

Running this exercise as a team, rather than dictating the output from the top, has two advantages.

It distributes the thinking, which often surfaces problems the leader hasn't seen. And it gives the team a sense of agency during a moment when many things feel out of their control.

How to make lifeboat decisions when resources are cut

One of the hardest decisions in product leadership is not what to build next. It is what to kill when you cannot afford to keep everything alive. During a restructuring or a funding cut, you will be asked to make lifeboat decisions: choosing which projects survive and which get cut so that others can continue.

A useful way to make these calls is to evaluate each initiative against two questions:

  • Is it essential to deliver your core value in the next 90 days?
  • Does it rely on knowledge that would be lost if the team is cut?

Work that clears both bars stays. Work that fails either one gets cut or paused. The hardest category is work that feels strategically important but is not immediately essential. That is where the most debate happens, and where the leader has to make the final call. What makes lifeboat decisions painful is that good people are often attached to the work that gets cut. Treating those conversations with honesty and specificity, explaining the reasoning rather than hiding behind vague business language, is what preserves trust even in the most difficult moments.[1]

Pro Tip! The debate over what to cut rarely ends in the meeting. Decide the criteria before the room fills up, or the conversation becomes a negotiation.

Survivor syndrome after a restructure

When a company goes through a layoff or restructuring, most of the leadership attention goes to the people who leave. That is appropriate. But the people who stay carry their own psychological weight, and ignoring that weight creates a second wave of damage that often goes unnoticed until it shows up in attrition numbers three months later.

Survivor syndrome describes the guilt, anxiety, and disengagement that remaining team members often feel after a reduction in force. They wonder why they kept their jobs when colleagues they respected did not. They worry they will be next. They feel uncomfortable celebrating wins or committing fully to new work while the organization is still processing the loss. Left unaddressed, these feelings push high performers, who have the most options, toward the exit.

What helps is not cheerleading or forced positivity. It is honesty about what happened and why, visible leadership that does not disappear into meetings after a hard announcement, and a clear picture of what the organization looks like now and where it is going. Team health metrics, things like engagement scores, voluntary turnover, and one-on-one check-in frequency, give leaders an early signal when survivor syndrome is taking hold. Acting on those signals early is far less costly than rebuilding a team after a second wave of departures.[1][2]

Pro Tip! After a restructure, wait 2 to 3 weeks before loading the team with new priorities. Rushing past the emotional reality does not make it resolve faster.

How to balance transparency and shielding when sharing bad news

One of the most consequential judgment calls in wartime leadership is how much truth to share with your team. Tell them too little, and you create a vacuum that fills with rumor, anxiety, and the assumption that things are worse than they are. Tell them everything, including the unresolved uncertainties and internal conflicts that belong in the leadership room, and you create panic and noise that makes focused work nearly impossible.

The most useful framework for navigating this is a distinction between the what and the why on one side, and the how on the other. The what is what is happening: the funding situation, the restructure, the strategic shift. The why is the reason behind it. Both of these can and should be shared with the team, as honestly and specifically as the situation allows. What you shield them from is the chaos of how: the in-progress debates, the contingency plans that may never be needed, the decisions that have not yet been made. Sharing that level of detail does not help the team. It just transfers your stress onto them.[2]

Brian Chesky's communication during Airbnb's 2020 crisis is a well-studied example of this balance.

He shared the core situation and the reasoning behind hard decisions with unusual directness, while managing the strategic complexity at the leadership level. Teams reported feeling informed and respected, even during a deeply painful moment for the company.[3]

Communicate bad news with radical candor

Communicate bad news with radical candor Best Practice
Do
Communicate bad news with radical candor Bad Practice
Don't

Delivering bad news is a skill most product leaders learn by doing it badly first. The instinct is to soften the message, wrap it in context, and delay the hard part until the audience has been sufficiently prepared. This approach usually backfires. When the actual news finally lands, it feels buried, and the audience is left wondering what else is being managed rather than shared. Radical candor, a concept developed by Kim Scott, offers a different model. It describes communication that is both honest and caring, direct without being harsh, and specific enough to be actionable. Applied to bad news, it means stating the situation clearly and early, explaining the reasoning behind hard decisions, and leaving room for questions rather than closing with a motivational summary that undercuts the weight of what was just said.

In practice, this looks like: "Here is what has happened. Here is why we made this decision. Here is what it means for you and the team. I know this is hard, and I want to answer your questions." That structure does not make the news good. But it treats people as adults who can handle reality, which is ultimately more respectful than a version that hedges and qualifies until the message is unclear.

The biggest mistake leaders make with bad news is prioritizing their own discomfort over the team's need for clarity. Vague communication does not protect people. It just prolongs uncertainty.[4]

Manage up effectively when leadership is also under pressure

Most product managers think of managing up as something you do to keep stakeholders informed and satisfied. In a crisis, managing up takes on a different character. The executives above you are also under pressure. They are managing their own uncertainty, fielding questions from the board, and making decisions with incomplete information. If you show up in those moments only as a problem reporter, you become part of the burden. If you show up as a stabilizer, you become someone they rely on.

The shift from problem reporter to stabilizer is not about pretending things are fine. It is about changing the structure of what you bring to leadership conversations. Instead of arriving with a list of problems, arrive with a situation assessment, the options you have considered, a recommendation, and what you need from them to move forward. This format respects their time, demonstrates that you have thought through the problem, and makes it easy for them to make a decision rather than having to extract the relevant information from a status update.

Managing up also means being honest about what you do not know. Senior leaders who have been in product organizations for a while can recognize when someone is managing their perception.

Admitting uncertainty, especially when paired with a plan for resolving it, builds more credibility than false confidence does.[1][2]

Separate your identity from the product's outcome

Product work is intimate. You spend months or years building something, defending it in meetings, and making decisions that shape it. When that product struggles, when growth flattens, when the pivot is announced, or when the project is cancelled, it is almost impossible not to take it personally.

And yet, conflating your self-worth with the product's outcomes is one of the most reliable ways to degrade your judgment precisely when clear thinking is most needed.

The distinction worth holding onto is this: your job is not to guarantee that the product succeeds.

That outcome depends on the market, the competition, the timing, the funding environment, and a hundred factors you do not control. Your job is to make the best possible decisions with the information you have at each point in time. A product that fails after a rigorous, evidence-based process is not a failure of judgment. It is a failure of the hypothesis. The PM who ships a hit through a series of guesses has not proven their skill. They have proven they got lucky.

This is not an abstract philosophical point. It has real implications for how you behave in a crisis.

Leaders who have tied their identity to the product's success tend to defend bad decisions past the point where the evidence has turned against them. They take critical feedback as personal attacks.

They avoid conversations where the data is unfavorable. All of these behaviors make outcomes worse.[5]

Protect your PM decision quality by protecting yourself

There is a failure mode in product leadership that gets celebrated rather than corrected: the leader who works 80-hour weeks, who is always available, and who treats their own exhaustion as proof of their commitment. It feels like dedication. What it actually produces is a leader whose judgment quietly gets worse while they feel like they are doing their best work.

The problem is not just burnout. It is that the decisions do not get smaller in a crisis — they get bigger. A tired PM making a routine prioritization call is a manageable risk. A tired Chief Product Officer deciding which business unit to cut during a restructure is a different problem entirely.

Research on decision fatigue shows that quality deteriorates with mental load, and the dangerous part is that you usually cannot feel it happening.

Protecting your decision quality means treating rest as a professional responsibility, not a reward. In practice, that means blocking time you actually protect, deciding in advance what "off" looks like during a crisis, and being honest with your team about your capacity. It also means building enough support outside work that the emotional weight of hard calls does not just keep compounding.

The other dimension of this is knowing when to ask for help. Many senior product leaders wait far too long to bring in a peer, a coach, or a trusted advisor during a crisis. They frame it as self-sufficiency. It is usually isolation.[6]

Pro Tip! Find one person outside your org you can speak to honestly about the crisis. One unfiltered conversation a week is worth more than ten carefully managed ones.