How do we approach the launch plan that was pre-decided and what changes in approaches would you recommend?
First, let me say that no one in Eng/Product likes product delays. The timing gets screwed up because of poor planning or unpredictable events. So, you have two options:
1. Avoid the coordination tax for smaller launches - so that a delay doesn't affect your launch timeline.
2. Give extra incentive for the Product/Eng team to plan better/meet their committed deadlines.
To avoid the coordination tax on small features/enhancements, I am a big fan of announcing the product after it's shipped. Say with a 2-week SLA, where product/eng fill the PMM backlog with small ships. It's the job of the PMM team to go through that backlog and announce shipped products.
For bigger products/announcements, make it a company goal. Go talk about the launch plan at the company all-hands. Tie your launch plan to company events and revenue outcomes. That way, your product/eng teams will do everything they can to keep with the launch timeline.
Hope this helps.
I know this pain!
Part of working at a product driven company is that this will happen and it's ok. The health of the product should come first and that will disrupt markeitng plans for time to time. Stick it out. Don't stop doing product launches just because the timelines didn't work out a few times.
Other things you can do (which we have done) are seperate the marketing launch timeline form the product launch timeline a bit. Maybe the product goes into open beta a month before the launch starts. People won't really notice and it gives you a huge buffer to work with.
Also, maybe you do the launch, PR goes out and an add spend starts, but other launch material goes out later that month as it's ready. There is value doing as much as you can in one day / week - but spacing it out often helps things breathe and gives you flexibility.
I'd recommend to play the "new person card" and ask a lot of questions: what market problems does this solve? How did they ID these market problems? What customers or products have they talked to? What are competitors or doing?
If they can’t answer these questions, there is likely room for you to come in and help and take ownership of the launch plan. Especially if it has been delayed, you can argue that now you have time to do some additional research / market validation to answer the above questions and you can drive the launch. Most PM teams are happy to have the help.
This is challenging indeed and something I've had to deal with at every company I've worked for. What I've fund helps keep me and the business teams sain is to plan to launch features 14 days after the official planned released date. This makes product nervous most of the time, but most of the time they're also delayed so it all works out in the end.
I tend to think that product launches are delayed more often than not. Because of that, the expected delays should already be part of your planning. Also, there are a few workarounds you can use to deal with unexpected delays.
I will go through both below.
1. Planning (or Before the delay happened)
Improving planning
Most organizations push product managers to promise deadlines that are not realistic.
Therefore, there is a lot of value on improving PM’s planning to properly estimate how long a new project is going to take. Ideally, PMMs and PMs should estimate how long past projects took based on complexity and compare it to the original estimations.
Also, it is common for junior teams to forget to buffer for testing, betas and unexpected bugs. Therefore, asking them to do it could improve your planning process.
Adding a buffer for the launch
Based on your previous launches, you can estimate the average delay. From my personal experience, it usually ranges from 2 to 4 weeks. Therefore, plan to launch 2-4 weeks after the date Product gives you.
Creating a plan B
It is harder to deal with a product delay if you do not have a plan B: you have to negotiate with every team (marketing, sales, and customer success) to rethink your launch dates, training sessions, etc. It’s a mess.
Therefore, plan ahead and incorporate a plan B.
- What should you do if the product launch is delayed?
- Which teams are going to be involved?
- Do I need to change the internal training sessions or only the external launch events?
- Can we previously agree on how to deal with a delay with Marketing (e.g., if we need to delay by 2 weeks, which campaigns can we anticipate?) What about other teams?
Adding more touchpoints with the Product team
Another source of improvement for some teams (especially if PMMs and PMs are learning to collaborate) is to discuss deadlines adjustment on your weekly meetings.
If you create a space on the agenda for this discussion at every meeting, PM will feel more comfortable sharing expected delays earlier and you will have more time to replan.
2. Workarounds (or After the delay happened)
However, planning sometimes is not enough and the product will be delayed anyway. There are a few tactics you could use to work around the situation.
Announcing before the launch
The easiest one is to maintain the same announcement day, but launch the features at a later date.
Not much to add here. The pro is that you do not need to change your launch plans, but the con is that your campaign will generate buzz before users can actually try the new features.
To minimize this issue, you should create a CTA that enables you to identify users/leads that were interested in the feature to follow up with them again (through marketing, sales or customer success).
Launching whatever is finished
If your team was not able to finish all the features, you can still launch whatever is ready.
The upside is launching and enabling users to try new features as soon as possible (which could improve satisfaction, churn, etc). Also, your sales team might be needing those additional features to increase conversion rates.
The downside is that the launch story might be weakened if you do not launch everything. Also, it could be difficult to lanch the missing features in the next cycle.
Mixing with another launch
Another alternative is to postpone it and launch on the next cycle (bundling with other features).
The pro is that you do not have to make changes to your overall launching plan.
However, it could become messy if you have launch themes (e.g., security features for month A, new reports for month B), as the launch would become too large and the message wouldn’t make sense.
Follow this rule: Launch is a business decision, not a technical decision. You can still launch, you just won't hit your launch date (as in when we can start booking revenue). You have to get a good sense of your engineering team's ability to deliver on the dates they've committed to. If they have a track record of delays, bake the delays into your launch planning. Have two dates for planning purposes: An internal one for development (with a specific day), and an external one that's loose (like 'Q3').
As you gain confidence the eng team is getting closer to completion, you can tighten up your external date.
In the world of technology, technical delays are a fact of life. Don't try to fix what you cannot change. Just try to minimize the impact on everything else.