You're facing technical issues during a product launch. How do you juggle conflicting priorities effectively?

It's worth considering whether the issues impact new features or are regressions in existing ones. Breaking something that already works is generally far worse than delaying the launch of something new. Also, you need to ask whether the identified issues are the whole story - maybe this is the tip of the iceberg and you need to dig deeper before you can effectively assess impact.

As product are launching and found some issues, do some risk assessments to understand first what's the impact towards mass production and potential customer use. This could be an opportunity as well to improve the product. If the impact is only towards manufacturing area, it cam be fixed. Just ensuring more test filtration before sending out to field.

Product launches always gives me an adrenaline rush. Every. Single. Time. I'm stoked to deliver what we've set out to do. I'm betting you feel this excitement too. When we run into issues, that's where the true heroes come through. Any "impact" should be considered against our priorities. Take those priorities and stick with the fundamentals - simply, logically, and pragmatically decide what to do first, second, third, and why. Trust your gut and fix forward.

Communicating clearly during times of crisis starts with taking a breath, calming down, settling in, thinking through the words and way you intend to communicate, and then delivering a succinct and simple message using taxonomy fitting the situation. Focus first on the trust you have with those you're working with, then let your words and the message come through honestly and continue to overcommunicate to ensure the stakeholders are all informed asap.

To explaining ground situation to non-technical people, try to make them understand in more simple and layman term. Which also not to make them get into panic mode which will make the situation worst, try to contain it by letting them know how you can fix or filter before shipping it out. Ensure some reliability test is carried out as well to give more confidence.

Sharing the plan to address, or the plan for building a plan is easily overlooked in stressful situations. Depending on the audience, you might want to share the level of uncertainty in your plan - e.g. best case and worst case. Make sure that you end with a concrete plan for circling back and keep to it. That will enable stakeholders to focus on other things rather than wondering when they're going to hear more.

Get diverse views on what to prioritise from different people and teams. Think about the elapsed time to address (including testing, and the likely level of destabilisation a fix will generate) as part of this - maybe there are some shipstoppers that you need to start fixing today. Communicate the prioritisation proactively so that people know what is going on and can provide feedback.

I would say understanding the product nature and fine tuning it to make it more competitive in the market. At the same time, taking this opportunity to have proper product test spec which does not overkill and not over loosen. This way, product can be stable.

You should always hesitate to reallocate people. There are huge inefficiencies when moving people between projects at short notice. They need time to ramp up, and again when they go back; There are knock on impacts to other projects which need replanning, additional communications that need to happen etc. It hits people's morale and energy etc. And don't forget that 2 times the people working on something doesn't necessarily mean twice the speed - it can often mean things slow down - especially in short time frames. Moving people can be the right thing to do, but it needs to be carefully considered.

Absolutely. But you also need to give your team the time and space to make the fixes - so, make the check-ins predictable, so that people can plan their work around them. Get them to keep bug tracking systems updated with their progress, so you and others can get updates without interrupting them. Remember that it can take a developer 15 mins to get back up to speed after an interruption, so that 5 min check-in actually costs you 20 mins.

Continuous improvement and fixing forward enables you and your team to grow. Even the worst of product launches lead to the greatest successes. Thomas Edison claimed that he had successfully found 10,000 ways that wouldn’t work before he finally developed the first light bulb. That's 10,000 failed product launches. And look at the wonderful effects the light bulb has had humanity.