Andrew Forbes

Yes, we do! We use a number of frameworks depending on the tier (T1 to T3) of the launch. These have changed throughout the year as we've grown, but at their core they include the information below... * Core PMM Deliverables - Things like a Messaging Source Document (MSD) which outlines our buyers, their pain points, and all of our product messaging * Sales Enablement - This includes the sales enablement resources and tools, presentations to the GTM teams, and the scope of how we plan to ready the sales team for a launch Integrated Campaigns - Includes the marketing plans for the launch (promotion, social, AR, PR, internal comms) * Web - This bucket tracks all the web pages we plan to update or create as part of the launch * Content - Details things like launch blog posts, e-books, datasheets, and other pieces of content we create for the launch Ops Readiness - This includes everything that makes sure we can actually sell the thing (if there's a SKU associated) and track the performance of the launch With each of these we have a number of items that fall into each bucket. In our tracker we track delivery dates, owners, contributors, and other pieces of information relevant to making sure that we are executing on all pieces of the plan for a launch. 

Ah, Sales Enablement. In my opinion, one of the MOST important pieces of a launch. I have no shortage of tips, but for the sake of time, I'll keep it to four... 1. Align with sales leadership early on your enablement plans and make sure they're a part of the planning process. This will help ensure that key things that reps need to know are detailed in your plan that you may have originally missed 2. ROLE. BASED. ENABLEMENT. What your AEs need to know about a launch is different from Sales Engineers and different from your Success teams. They each need to know different things to successfully take a product to market - lean into this. As part of your plan, you should do detailed role-based enablement for each team to ensure that the key actions each role needs to take are covered. For instance, deep pitch practice for AEs, objection handling, etc. But for your Sales Engineers a stronger focus on product capabilities, roadmap, and demo practice 3. USE YOUR SALES LEADERSHIP! Let's be real, we've all heard "why is this marketer telling me about how to sell something when they've never done it" -- To get ahead of this, bring sales leaders and well-respected reps into your enablement sessions. Have them deliver the pitch, have them do an objection handling example, have them walk through an early customer story. This will help a ton and help build trust and excitement around the launch 4. Customer examples!!! You can explain your new launch all day. You can explain the value props all day. You can talk for days about it. But nothing makes a launch real like an example from a beta customer. Share their use-case with your reps. It's so much easier for them to go out and repeat that story than it is to relay your value props. Hope these are helpful :) 

There are a lot of different ways to prioritize releases - and we're currently updating how we do it right now. If anyone else has any tips, let us know!! For the most part, we consider two things: business impact and customer impact. For instance, if something has a large customer and business impact, it's prioritized above other items as a tier 1 launch. Or if a launch has a high customer impact but a low business impact it will fall into our T2 bucket as we likely will need to do a lot of promotion into our customer-base to drive awareness, but the launch doesn't necessarily need press coverage or a large outbound push. We've found the above model to be quite helpful, although subjective if we don't have the data to back up some of our releases. As mentioned, we are working to refine how we prioritize launches, but it'll likely follow this criteria to some extent. 

Hey - Thanks for the question! In my opinion, the best way of telling a great story is to really have an understanding of everything you're talking about - especially the heroes of your story. And to do that, it comes down to meeting with the people who are going to use the product you're planning to tell stories about; learning their pain points, learning what they do every day, learning how your new thing can make their lives better - and building empathy around them as a human and what they're trying to accomplish. With that, there are many frameworks you can apply. Every good story follows a relatively simple framework... You set the stage, introduce the hero of the story, detail the conflict they face, and how your thing leads them to a resolution or better place. As a starting point, here's a simple flow you could use that goes through every piece of a great story. Play around with it, add more to it, and make it your own! Andrew is a... Right now, he struggles with... It's challenging for him because... And it creates a lot of issues, like... It would be so much easier for him if he could... That's where our product comes in, it helps Andrew... Because of this, it's increased/improved metrics like... Now Andrew's life is so much easier! Also, we've helped others with this too, for example...

I think it's safe to say that all product releases come with some sort of delay or scope change, it's to be expected. But, it can oftentimes impact the morale of the team if there are repetitive delays. The biggest thing you can do is be transparent from the beginning. Oftentimes, if you're working closely with your product teams, you can get a sense if things may slip and dates may change. When you get that feeling, it's important to have a conversation with your PMs about it so that you can relay information to your team as soon as possible. I have three tips... First, turn delays into a positive. Not always possible, but when you can, it's a big help. For instance, if a launch slips a month or quarter, position it to the group as an opportunity to do that extra thing on the website that could help increase conversion or write those extra blog posts to be used in social that could drive better awareness. Again, it's not always possible, especially if you work for a larger business where teams workloads are planned out, but it can help. Second, always come with a new plan. This goes hand in hand with the above point, but if you hear from your PMs that a launch is delayed, make sure to go to your stakeholders with new dates and timelines - echoing that they have more time to build out these deliverables. Third, drive home the point that building software or launching new products is really, really hard. Oftentimes, development teams hit unforeseen complications that delay things - it's to be expected. From the beginning, set this tone with the team and let them know that there may be changes in scope and that it's important to be flexible, because at the end of the day whatever you're launching is going to have a great impact on your business or customers. 

This is an awesome question. The way we've gotten ahead of it when I was at Zendesk - which has worked well - is by creating an "Operations Council" who is responsible for reviewing the operational components of a launch. This includes reviews of things like billing readiness, pricing & packaging, and making sure that we have reporting systems ready for us to track the success of a launch. These meetings are staffed by stakeholders in each department as well as their respective leadership. It's a great way of ensuring that as a business we are ready to operationalize a new product line or revenue stream and for us to surface up potential issues that we need to address before a launch. Additionally, we have a number of syncs with different launch stakeholders on a number of cadences; from campaigns to sales enablement to the sales leadership teams. We spend a lot of time with them pre-launch, gathering their needs, refining plans together, and ensuring that launches will be successful. At the end of the day, launching something new is a massive team effort and as a PMM we sit in a great spot where we can bring teams together, share insights, and make sure a launch goes smoothly. 

Great question! Yes, we have historically used a tiering system that's based on two factors: customer and business impact. These two criterion help us determine if a launch is a T1 to T3 launch. Depending on the tier, the scope of deliverables changes quite significantly. Here's how we break it down: * T1 Launch: This launch provides a substantial financial opportunity to the business OR significantly differentiates us in the market. These launches get full integrated campaigns support as well as significant sales enablement backing. * T2 Launch: Impacts an customers experience or workflow OR brings our solution to par with other vendors. These launches are usually an update to an existing product that require us to drive awareness but don't require a full PR push or campaigns push. * T3 Launch: Improve the user experience for our customers, but don't significantly change a users workflows. We usually round these launches up in our quarterly launch programs or release notes, depending on the impact.

Hey - Thanks for the question! Short answer - Early. and. often. Get stakeholders in a room early on and set the cadence with them. When I was at Zendesk, we used a RACI model when it comes to ownership and development of launch assets. Set this and then decide when you want folks to review. My take is that it's always best to share before you're ready. Sometimes it can be hard to do because you receive critical feedback BUT that feedback helps immensely with whatever you're trying to do. As for major launches, we typically get everyone together weekly for an hour and have various stakeholders walk through their deliverables and give the group space to provide feedback. For deliverables that are a bit larger, we sometimes have a detailed track where we meet and talk through feedback on a bi-weekly cadence to ensure things are moving along smoothly. 

This is a tough one! We've worked on so many awesome launches at Zendesk - and as the team who's responsible for our quarterly launch programs, we've had no shortage of fun launches to work on. If I had to pick one, I would honestly say it was my first launch at Zendesk - our analytics product Explore. You could say I was "thrown off the deep-end" with this one. I was relatively new on the PMM team but found myself in a position where I was the sole PMM working on the launch. It's my favorite because it was an awesome way of ramping up on everything product marketing-related and it ultimately was a very successful launch that had great customer adoption, press coverage, and was ranked #4 for the day on ProductHunt.