How to handle a product/business crisis?
Start by understanding the problem, bring the team together to deliver a resolution, do a retrospective to avoid the crisis again.
Why It’s Important
You will encounter crises, and when you do everyone will look to you for direction on how to handle them. Teams that successfully navigate a crisis are strengthened by the experience. Those that don’t risk not only worsening the crisis, but also reducing their effectiveness as a team.
How to Use This Principle
It can be hard to assess the scale of a crisis when you’re in one. Recognize that crises typically fall into three categories: People, business, and organizational. Focus on understanding the problem through data and research rather than simply reacting. Quantify the problem to put it in perspective and bring the team together to iterate through possible resolutions.
Real-life application by Victoria Ku, Senior Product Manager at Airbnb:
I used this principle to solve a sticky situation where 3 teams coincided with 3 feature launches, on 3 form factors.
If that sounds general, let me paint a more visual picture for you: three different teams were trying to push three different features (a processing change, UX form changes, and a company-wide design initiative) on the same three different platforms (web, Android, iOS).
Anyone who has worked on launching features as experiments knows that to properly attribute value, the set up of that experiment needs to be pristine, with no experiments impacting the results of another.
In this case, the overlap was plenty, and my team was confused and blocked as to how we would actually launch our change. We were stuck between the two other teams, with lots of dependencies and different timelines.
In order to unblock my team, I immediately assembled a team of selected experts to figure out the path forward: a web engineer and a mobile engineer (both who knew the intimate details of the UX changes), and the data scientist who was in charge of experimentation and logging. Together we brainstormed all the possible ways to uphold the business goals, meet the necessary requirements, and to unblock ourselves so that we could launch our newly built UX form without waiting months for other teams to complete their experiments.
This should conjure up mental images of people staring and drawing on a large whiteboard! A lot of “but what about [this scenario]…” and repetitive erasing and writing.
We were able to create a matrix of complexity—an outline of how all teams could launch their features, under what conditions, in what order of operations, and what would be compromised. We took an entire afternoon to map out the many permutations, and once we finalized the best paths forward for each form factor, I outlined the plan of attack in a memo that I first reviewed with the other product managers before finalizing in an email to leadership. This required crisp and concise communication skills, both in presentation and written form.
The result was alignment, decisive action, and sweet sweet clarity. Not only were the teams of engineers able to move forward with development and sprint planning, but product managers were able to move forward with timelines, data science could attribute the value of each launch properly, and leadership could rest easy knowing the business goals could be upheld with minimal escalation.
At the next appropriate meeting, I brought up the scenario as a form of productive discussion on how we could get ahead of blockages created from overlapping scope from multiple teams and company initiatives. This was assuming that a crisis like this could potentially be a yearly issue if we didn’t get ahead of it now, which turned out to be true years later. Thankfully, Airbnb has a great culture of discussing post mortems and so we were able to nip this crisis in the bud.