Product Manager: Diplomatic Hostage Negotiator

Photo by ev on Unsplash

It’s late on a Thursday night. It’s been a long grueling week attempting to reach the masked gunmen holed up in the bank. You were flown in months ago to get your countrymen to safety for what was told would take “just a coupla weeks.”

You’re fielding calls from the hostages’ family members, Congressman back home, the local government, and the press. The local police force is incompetent and refuses to be helpful.

You’re sweating.

You trained for this exact scenario, except the training had everybody safe and sound in just a few days.

So far, nobody’s died on your watch, but as the hours and days creep along, you have a pit in your stomach. You don’t know how much longer you can keep people safe.

Except you’re not a hostage negotiator. You’re a product manager. The hostages? The software product you were meant to ship.

The masked gunmen? 3rd party engineers brought in after an unexpected downsizing cost you your original team. The unhelpful police force are the freelance UX designers, also unexpectedly brought in on a part-time basis after the same downsizing cost you your original designers.

All the screaming politicians, worried family members and upset local government are your boss, the CEO, stakeholder VPs, investors, all wondering why the hell you can’t ship your product when you have the same number of engineering and design resources as you originally requested in your project proposal. They all bought in to your vision and agreed your product would save the company millions. Why can’t you ship?!

Oh, and the press is wondering the same thing, since your marketing department told them a month ago that this new product launch would change the whole damn industry.

No deaths yet, but you’re worried the project will be descoped, deprioritized, or worse, canned completely, and haunt you the rest of your career.

This is a fictional story. This might be a little exaggerated for some. For others, this might ring a bit too close to home.

It doesn’t always work this way. And there are things you can do to prevent this kind of situation. You can’t always prevent a team getting cut, or resources changing— hell, that happens way more often than not. But you can help your situation, and you can keep everybody cool so there’s no worry of anybody getting hurt.

1. Include everybody in the kickoff. Even marketing. You don’t know what the marketing department will end up hearing about the project, and from whom. If they hear from the CEO or CMO that this project is launching soon and needs a press release, they’ll have to do their job. The kickoff will make sure everybody in the room knows you’re the key point of contact, in charge of all communication and updates.
2. Set expectations. Using vague language around details such as the number of engineers or designers you need can get you in trouble. Pick your engineers and designers who are the domain experts and list them as your team leads. Make sure stakeholders know why they’re important for hitting the ship date. If things go awry, speak up quickly to communicate why changing the team will change the target date.
3. Don’t expect reality to follow the book. Like Bruce Willis running around barefoot in a Santa hat, reality might deviate from the original requirements. If things go sideways, you might need to change the scope of the project and ship date. You might need to cut some of your favorite features which aren’t as critical to pushing the KPIs as the others. Do it quickly, before somebody gets hurt.
4. Keep cool. When tensions run high, it’s your job to keep everybody cool. Speak to all parties on their level, understand what they want out of the project — or life — to make sure you ship. The CEO does not want the same thing as your new outsourced 3rd party development team. The designer does not want the same things as the engineer.
5. Roll up your sleeves. I have never met a product manager who didn’t have some sort of technical skill. Whether it’s engineering, QA or design. I myself have a background in UX and used to build Drupal websites. Maybe it’s been a few years since I wrote some code, but hey, how hard can it be? Nothing boosts morale and keeps the team pushing forward than the PM attempting to fix things herself. You’ll quickly be told to keep out of things. But in all seriousness, if you have a strong technical skill, jump in and help push things forward.
6. PR is important. The hostage-takers have access to all the same news sources you do. You don’t want them to see misinformation out in the wild. Internal PR is just as important, too. Make sure you communicate effectively to all teams and stakeholders on a continuous basis so nobody’s surprised about the situation on the ground. You don’t want a trigger-happy hostage-taker losing it and pushing to production without thorough QA...
7. Bring a pizza. As things are getting heated and people are pushing the clock to bring the hostages home, lighten things up. Bring pizza. Donuts. Let them see that you’re appreciative of their hard work and give them an energy boost to keep going.
8. Keep everybody safe. Don’t let your project get canned. Don’t get caught up in the politics. Keep moving things forward. Get on dailys, or even twice a day meetings. Understand where everybody is, what issues are present, and figure out how to remove blockers. Don’t lose sight of the mission. Get it done.
9. Throw a party and show some gratitude. When all the hostages are home safe and your product has launched into the wild, make sure everybody who worked on it gets recognized. Make sure C-suite, VPs and all the other “politicians” know what the developers and designers who hustled did to get this product live.

What’s your product management horror story? What tips do you have to keep things going, even when things get dicey?