How to Avoid Team Chaos When Your Product Plans Change

product manager crisis communication plan

Let’s set the scene. Your team is prepping for a major product launch. Marketing has been working on the go-to-market activities for weeks. Sales has been teasing the new functionality with customers. And engineering has been polishing the experience. Then the worst scenario — two days before launch, a major bug is revealed. A stop-everything-you-are-doing kind of bug.

It will take days to fix. No way the launch will happen on time. You get busy hustling and rallying the product team around what needs to happen. After all, your focus is on the product, right? Yes. But you also need to get in front of all cross-functional teams involved — otherwise, chaos will truly ensue.

Chaos does not happen simply because the plan changed — it happens because you have lost control and stop communicating what’s next.

This can happen all too fast. The plan changes, and instead of going to teammates immediately with the update, you begin to work on the new plan. In the absence of hearing from you, teammates turn to each other for intel. There are whispers — but no concrete information. Rumors start to swill, and before you can explain what has happened and what it means for the launch, there is chaos.

As a product manager, you need to take control. This starts with thinking through who will be affected by the change and how to communicate that efficiently. You need to give the same attention and consideration to this that you do to working with engineering to solve the underlying challenge. In other words, you need a crisis communications plan.

Start by considering and writing down these four factors:

Think broadly about your stakeholders — who will be affected by the change? This can often be dozens of cross-functional teammates. To keep things organized in your crisis communications plan, document every team that will be impacted and the names of their team leads. Each of those leads can serve as a point person for delivering the information and making sure everyone has the resources they need to change course.

Once you have identified your stakeholders, you need to know the best way to communicate with them — whether it is a phone call, instant message, or a quick web meeting. Ideally, you are working in a company that has a functioning product team, so you have open channels to communicate with the larger audience simultaneously. Otherwise, document how to reach out to each person using via their tool of choice. This will help ensure that they are responsive.  

Quick action is the key. Nearly everyone will want to know right away, but there are some people who have more immediate dependencies. Think through all the cross-functional work and how it will be impacted by the change. Then, include in your plan the order in which people need to be told. For example, if marketing is ready to push an announcement about the new feature that day and that feature gets delayed last minute, they should be at the top of your list.

Communicate the “why” behind the change as clearly and directly as possible. And share everything you know about what will happen next. Not immediately sure of the exact next steps? This is okay, but at least give a timeline of when you will know. This will help everyone feel secure in the plan — even if it is different from the original one — and prevent people from spreading their own stories behind the change.

Change is almost always inevitable — but chaos does not need to be.

The way that you communicate unexpected events can prevent or prompt team chaos. So, think beyond the bits that make up your product. Consider a crisis communication plan so you can be the team’s greatest defender against the chaos.

Not only does this keep the work moving forward, but it also shows your teammates that you value their time and work. And that is something worth planning for.

What else should be on a product manager’s crisis communication plan?

Your product is crying for Aha! so start a free 30-day trial.

About Ron and Aha!

Ron is a product guy. He is the VP of Product Management at Aha! — the world’s #1 roadmap software. He previously founded and sold his own company and has been on the founding team of multiple venture-backed companies.

Sign up for a free trial of Aha! and see why more than 300,000 users worldwide trust Aha! to build products customers love.

We are rapidly growing and hiring!

  • Customer Success Managers (product manager experience required)
  • Product Marketing Managers
  • UX Designers
  • Rails Developers

Work from anywhere and be happy. Learn about our team — see current openings.


  1. Eugene T

    Thanks for writing this article! I am personally experiencing this myself most recently, but at least every Sprint!

    I’ve also read somewhere, especially in the agile manifesto that we should welcome changes to requirements, no matter how late in the game. I don’t necessary agree with that statement. It’s also not always feasible with big features and big budgets with multiple stakeholders.

    Also, sometimes even the communications with the best intentions fails. People might not understand reasons, people have their own agendas, quotas or targets to meet and getting aligned might not be possible in the near term or ever.

    I feel like Product Management’s job is to manage the chaos. Building a new product or maintain a old one inherently is managing chaos. There will never be a truly right answer, only one that is right at the moment with the information at hand. You can only do your best, but it takes time, it take patience.


Leave a Reply

Your email address will not be published. Required fields are marked *