Product Launch Checklists: How to Better Plan Your Releases
Do you ever get the feeling after releasing a new product or feature, that you may have forgotten something? Do you ever think you’ve thought absolutely everything through, only to realize you haven’t.? If you can relate, then I recommend continuing reading. I wrote this article based on my experience of failed and successful product releases.
With growing experience as a Product Manager, I’ve learned to work more efficiently. Writing a user story as a senior took me way less time after I’d done my homework, research, etc. than as a junior. Ok, this doesn’t count for everyone but I’m sure it does for you. 😉
Formalizing certain processes really helped me to stay on top of things. One example of this is the product launch checklist. In the following, I’ll describe how I prepare and communicate an upcoming product or feature launch. You can use my free downloadable checklist as a template and adjust it to your company’s needs.
Product Launch Presumptions
A successful product launch starts with good planning. That’s why this article presumes that the product or feature that’ll be released has been
researched (market & competition)
validated based on data
prototyped and tested
prioritized accordingly
and more
This list isn’t complete and not every point needs to be covered. That depends on how your company works.
Next, I’d like to focus on two important steps for a product release:
Preparation
Communication
Note: Both parts are covered in the free product launch checklist.
1. Preparing Your Next Product Launch
There are a lot of different products out there. I’ve launched many backend services, web applications, and (my favorite) apps. That’s why I’ll focus on examples using these 3 areas. The “preparation part” of the product launch checklist is also applicable to other products and services such as hardware.
Example:
Let’s imagine we’re working in a B2B2C insurance company. This company offers its customers the best insurance deals via an app and over the web. The app was launched in 2008 and design-wise never touched again.
Guess what: We’ll redesign it. 🎨
The project has been validated and we know it’s the right thing to do. Now we’re moving close to the launch date (approx. 4-8 weeks).
Product Launch Documentation
The product launch documentation covers all relevant information about the product. It’s written for internal use and can be re-used as a template for external material.
Product Documentation (Internal)
I write product documentation in a way that it can be used internally & parts of it externally. The points I cover are:
Feature description & goals
Business & customer value
Research & validation
Functionality & usage
Comparison with the old functionality (optional)
Planned rollout timeline (e.g. staged rollout, customer target groups, beta phase, etc.)
Links to other sources (e.g. Jira board, design files, feature comparison)
Depending on your work and communication style you can add more or fewer points to the documentation. I believe it’s important to have a source of truth that allows everyone to access and find key information.
If you’re interested in “how to write product documentation”, I’ll be writing an article about that in the near future.
Comparison Sheet & Matrix
Looking at our redesign example, we’ve changed many screens in the existing app. Therefore, we’ve created a comparison sheet (e.g. Confluence document) that shows each screenshot with a before and after. I always highlight the main changes especially when functionality has been moved or changed. Creating a document like this can also be very helpful for the Customer Support department. At the same time, your support and operations department can reuse the document for external communication such as support center articles.
In the case of developing a completely new feature, it’s very helpful to create, for example, a feature comparison/matrix. This can help the Sales and Marketing teams to better present and sell the new feature or product.
Frequently Asked Questions (FAQ)
How can you create FAQs before launching a product? Initially, I built this based on assumptions and questions people ask internally. Sometimes you decide to make trade-offs when you redesign a product. Maybe even functionality changes or moves to other places. And yes… It’s not always 100% self-explanatory (even if it should be). Mentioning things in the FAQ section can be very helpful for the Customer Support Team and later on for your customers.
If you build a new feature or product FAQ’s can be helpful to make customers convert. It’s not only about functionality and how-to’s. The better you educate your customer the more likely they are to buy in.
Besides documentation, it can also be very important to educate and train people internally. I recommend doing this for bigger launches in particular.
Note: There are multiple ways to document product launch-related material like videos and tutorials. The list isn’t complete. My intention is to show some possible options.
External Launch Material
Since we’ve done a lot of work covering the internal materials it’ll now be even easier and faster to prepare the external product launch material. I recommend not simply copying and pasting. The language you use with your customers is usually very different from the language you use internally. Do I need to mention not publishing confidential and competitive data? 😉
Release notes
The release notes in the App Stores should contain all relevant changes. A mistake I see very often in release notes is, that they’re written in a very “non-human” way. Please always keep in mind that you’re delivering more/new value to your customers. Instead of calling it “bug-fixes” you can spend 2 more minutes explaining what you’ve fixed and why. Don’t overcomplicate things. Clarity always wins.
Website, landingpages, emails
Marketing! Do I have your attention?
Depending on your company size and structure you might be more or less involved in the marketing of your product or feature. And as a Product Manager, it’s important to stay on top of all marketing activities. I always highlight the USPs, main “selling” points, and customer value in the product documentation. This document/material can then be shared with the Marketing Team. Alternatively, you can create a separate “marketing/sales” document. You as a Product Manager should know what are good ways to interact with your customers and what aren’t. Don’t be afraid to share that knowledge with your Marketing Team. In the past, I’ve assumed that they’re aware of these insights… and I’ve often been wrong. The bigger the organization the more likely it is that the opposite is true.
Support center articles
Based on your product documentation, before/after comparison, and FAQ’s support center articles can be created more easily. If you don’t create these yourself, get in touch with e.g. the Operations Team who will create them. Good communication, exchange, and reviews always helped me to make the best out of every customer phasing documentation.
Having good product documentation in place is the first step. Next, we’ll have a look at when and how to communicate the upcoming product launch (redesign).
2. Product Launch Strategy: Timing & Communication
What’s most important is to make sure that all key stakeholders are updated and aware of the (in our case) redesign launch. Here you can read more information and best practices around stakeholder management. I’d like to highlight the importance of really updating all of them. Over my career, I’ve seen too many occasions where teams and Product Managers launch features without letting key stakeholders know. That’s a no-go! 🚫
Product Launch Communication: Whom to Update When?
Informing all departments a week before the launch is too short term. The bigger the project is the more time in advance I inform the stakeholders. Let’s have a look at some key departments to update.
Marketing Team
The Marketing Team needs to know everything about the product and how to market it. Ideally, you provide them with screenshots or give them access to the beta version. If the design isn’t finished, stay closely in touch with them and provide them with regular updates. Since they need to create landing pages, update the website, and more I’d inform them at least 8 weeks before the launch.
Note: I’m talking about product launch communication. Every stakeholder should know that you’re working on that big feature from day 1.
Customer Support Team
Launching a product without an informed Customer Support Team can be suicidal. At the beginning of my career, we launched (what I thought was) a tiny feature without informing Customer Support. The result: The customers weren’t able to use the old functionality, we deployed a huge bug, and hundreds of people were calling us. I can tell you my boss was everything other than happy about that. That’s why I always update the CS Team at least 6 weeks before and start preparing with them the launch.
Sales Team
It doesn’t matter if you’re redesigning an app or building a new feature, sales want to know. I’d start communication with the Sales Team around 4 weeks before launching. It’s important to share the documentation and to do a presentation of the product. Workshops can be very helpful to build a common understanding and talk about product and feature capabilities. A feature matrix and competition comparison can also be very helpful for Sales Teams. Based on the questions and requests from the Sales Team, I recommend summarizing them in an email. I’ve often heard that salespeople like to sell more than the product actually can. 😉
(Technical) Business Development Team
If your Bizdev Team works with partners and your internal SDKs and APIs, I’d get in touch with them at least 4 weeks in advance too. Sharing technical documentation upfront is very important. For meetings like this, I always add a Senior Developer from my team to talk about the technical changes and do Q&A sessions (questions & answers).
Internal Product Launch Training
The mentioned departments are some examples of how and who to communicate within the run-up to a product launch. If your company is bigger, you might have more departments and people to communicate with. In smaller companies, you can simply bring all the involved people into one room.
I’d like to share three more ways to update bigger groups of people regardless if they’re all part of one department or different ones.
Internal Launch Email
It’s always helpful to announce an upcoming launch (pre-launch mail) and to send an email after the (successful) launch (post-launch mail). If you use other tools like Slack instead of email you can use them instead.
Product Demo Sessions
Some companies have monthly product demo sessions where all employees can either test the product(s) live in a room or via a call where teams present what they’re working on. Or even better: what they’ve finished. 🚀
AMA (Ask Me Anything)
These sessions are great for “interest groups”. People and departments who will be affected will voluntarily join you. It’s an open meeting without much of an agenda. Simple questions and answers. Be prepared. They ask good and tough questions.
Product Launch Checklist Download & Summary
Launching products can become more complex in growing environments. That’s why I always focus on building a basic structure that can scale in terms of preparation and communication across departments. What are your biggest challenges when it comes to launching products and features? Tell me on Linkedin.
