How do you manage launches when the product team has a difficult time sticking to timelines?

I would bake in as much buffer time as you can in your marketing timelines. If they have a track record of not shipping on time, I'd start assuming that. If your product partners get upset about that, explain the marketing dependencies that you can't deliver results when timelines are always in flux. 

This is super frustrating and I feel your pain. Perhaps you can also find other leaders who sympathize and don't want resources to go to waste to help you make your case and begin to shift the culture and expectations around timelines.

Your product team is not unique! I've never heard of a product team that sticks to deadlines exactly. The best lesson I've learned on how to mitigate this in enterprise software is that you can launch a product many times. 

There are different ways to do this: pre-announce at your conference with a preview/waiting list, beta launch, general availability launch, internal re-launch with your sales team with new training and collateral, momentum launch with PR on usage and metrics...it goes on.

If you're in a communication lapse because it's been awhile since a new product was launched, think about how you can get more juice out of the old products, customer stories, new blog posts, support offerings, or other angles. 

There are lots of ways to communicate with customers and the market without relying on new product offerings. Stop thinking of product marketing as just launching new products, and start thinking about it as turning company strategy into revenue growth, and you will find many things to communicate. 

At the same time, put some pressure on your product team to deliver the goods. In person events are a great forcing function for this. Conferences, sales kickoffs, roadshows, keynotes, etc.

It's very common -- particularly in modern software companies -- for product teams to move timelines based on engineering constraints, customer feedback in the beta-testing process, and more. All product marketers wrestle with this situation. So, realize you're not alone!

I recommend explaining what's in it for the product-engineering-design team. Do they want much-anticipated recognition for and usage of the product they've toiled for so many months on? Then, let's set a date. Do they want a lot of help -- not just mention in a monthly newsletter, but also a dedicated email campaign, media-relations support, an ad campaign, etc. -- from the greater marketing department? Then, let's set a date and work back 30 days with all of those stakeholders. Do they want the customer-success leaders to stop getting upset with them for moving dates all of the time? Let's set a date. 

This can be a huge challenge, and I certainly feel for you. Overall, I think it comes down to open and transparent communication between Product and Product Marketing, and the organization at large.

Overall, I think there are a few things you can do to get ahead of this:

1. Transparent Roadmap - This will depend on the culture of your organization and how transparent you can be, but ideally the more the better. If you can keep a roadmap that everyone has access to and contains key timelines it will naturally help with the communication across the company. 
2. Separate launch date, from the marketing "go live" date - Clearly there are some things that need to happen in unison with the actual launch, like internal enablement. But if the shifting of launch dates causes down stream challenges with the broader marketing team (i.e. a webinar was planned, and now has to be moved) then you can separate these two events. This gives you as a PMM some flexibility and also builds in some buffer for Product if timelines are a challenge.
3. Cross-Functional Teams - Internally at Iterable we have "Tiger Teams" for key launches and major initiatives. These teams have representatives from each functional area (Customer Success, Sales, Marketing, Product, Etc) and PMM will drive the meeting and transparently share launch updates. As a result, the representative from each team can help cascade information down across teams when a launch date changes. More so than just a launch date changing though, this cross-functional team helps increase communication and collaboration in the lead-up to a launch.

The misalignment comes from what product GA means versus what marketing GA means and confidence level. And this alignment should come from the top—Head of Product and you, with the support of the entire GTM team and executive. Establish two definitions for GA, and align on confidence levels for each stage of product development. These two things should be agreed upon by the Head of Product to every leader in the org. She has to be accountable to you on this framework. 

Working from a place of positive intent, some R&D teams may not realize that launch activities are as much work at building a new product/feature. They don't see all the planing and activities that go into it. 

Whether or not you have program managment function: build a clear project plan for gtm activities, circulate it and create rituals to ensure it's on track. If you break down any GTM delivery into talks, it'll naturally create trip wires. 

ex/ team needs final UX to build help docs and marketing assets. If that's not delieverd by an agreed upon date, it sends red flags early on risk to the timelines. 

One organization that I was in had seirous challenges with meeting goals, but also focusing on too many big bets vs tackling the smaller wins, being experimental. They implemented the 6-week cycle model (I'm a big fan). There are quarterly goals and in each quarter there are 3 cycles. The PMs are responsible for defining the deliverables for the cycle during week 5 (ideally collaborating with the rest of the R&D team). Ideally there is a meeting with R&D leadership and PMMs to review these goals for the upcoming cycle weeks and accomplishments from the previous cycle. We got really good at being realistic and transpartent. 

Same! In my case, I was also dealing with phased launches--bits of the solution released every few weeks. And I understand why–when you're working with a developer audience there's less appetite for a big splashy release, and more interest in a phased roll-out of a given feature or product just to get hands on it ASAP and iterate as quickly as possible. That was tough to get used to. I would start by finding out a little more about what's causing those delays in product.

If it's intentional, to phase releases in order to get beta feedback, I would consider setting up a power user group. Same group of 20-30 developers that agree to test most things that come down the pipe and provide feedback in a private Slack channel. That might provide more confidence in on-time releases.

If this is something the product team ALSO wants to fix, and maybe it's just an engineering resourcing issue, I would have them commit to not releasing anything without your knowledge at least a week in advance. That will give you enough time for customer comms and enablement, which are your most important tick boxes. In a previous role, I realized that my product team thought that product marketing was just about blogs and social media posts, because they would say things like, "we don't really need marketing for this release," and then would launch without my knowledge. Ensure your product team knows that half of your job is awareness, and retention, and you can't accomplish either without being in the loop.

Once the thing is out the door, don't feel like it's "too late" for a larger marketing campaign. Even a quarter or so later you can bundle a number of things that have already lanched and create a larger campaign.

This is pretty common. In my previous life as a PM and now as a PMM, I don’t try to manage the product team and the schedule. I try to get ahead of these challenges by announcing new capabilities while they’re in development and positioning it as “coming soon”, then continuing the drumbeat all the way from the beta release to general availability. This allows us plenty of flexibility when it comes to timelines shifting.

It seems to be a common pattern across our industry too. You’ll see companies announce new features and products at their user conferences, but the products are not ready to use. However, you can sign up for the waitlist and get notified as soon as it is ready. And in the meantime, they will send you updates along the way to keep your interest piqued.

I understand in some cases you’ll want to make a big splash where new capabilities are kept under wraps and press releases are shared under embargo. In this case, you might want to delay announcing anything for weeks till after the product is released internally and thoroughly tested. More and more companies are adopting feature flagging as a practice to hide functionality till it’s ready to be unveiled. It might be worth speaking with your PM and engineering leaders about similar practices.

While I don't want to discount the personal thrash this puts on you, I’d suggest you quantify the impact in a manner that is around the health of the business. Showcase that there is an opportunity cost to the inability to stick to timelines. Example: When you have a regular cadence in communication, do you see list sizes growing and can you maintain a standard conversion rate? Compared to when you have lapses in communication are you seeing adoption suffer? 

How you’ve described this seems to me like your product team isn't aware of the unintended consequences that are happening by missing deadlines. If you can showcase how this behavior is negatively impacting the company, you can help to showcase the value of not only sticking to timelines but also of the PMM function and of your deliverables. 

Managing product launches when the product team struggles to stick to timelines can be challenging but it is a common thing to navigate through. Here are some things I do to make sure everyone's on the same page:

1. Chat with the product team early on: Figure out their timeline and make sure we're all on the same page about what's important, what can wait and how to deal with delays.

2. Build in some extra time: Things don't always go according to plan so it's good to have some extra time in case of delays.

3. Focus on the MVP: Not everything has to be perfect at launch. Get the most important features out there first and then add more later.

4. Stay close: Meet regularly with the product team to see how things are going and if there are any changes to the plan.

Apply agile sprint thinking to launches. You can do this by creating themes just like agile has a sprint (my team is moving to quarterly message themes). These themes encapsulate at a high level the features that the product team is working on.

This approach has a couple of benefits. First, your product folks should appreciate agile, which will make them more likely to buy in and maybe meet a few more of those deadlines. Second, you get to execute a launch with some flexibility. Communicating the aggregate of features mitigates your risk in the event that some things don't make it out in time. And then when they do make it to production you can roll them into your existing theme.