How to launch products

8 actionable tips for PMs on releasing and launching your products successfully

👋 Hi, I'm Jaryd. Welcome to this weeks Slice— the free weekly newsletter about product, startups, growth and working with people.

If you’re not as subscriber already, join below. It’s free. 👇

If you enjoy this newsletter, and know someone else who also might, you can share it below👇

Share The Product Slice

Your job as a PM is to ship products that have customer and business impact. The more things you launch that drive growth, the more successful you'll be. 

Working with your engineering and design team during development will have its challenges, but it also feels safe and comfortable because you're still working on the idea, “perfecting” it, and holding it back from the wild where it can break and be criticized. 

As long as something is in development, it's not having any impact. To get there you have to release, and you should be trying to release to your customers as quickly as possible. 

The perfect is the enemy of the good. Too many PMs and founders wait until their product is absolutely “perfect” before releasing and putting it in front of people. Wanting to impress your stakeholders and the market with a great set of features and a polished UI is totally understandable, but waiting until you reach “perfection” is a mistake and will cost you. 

It's worth noting that releasing and launching are similar, but not the same. 

  • Releasing is setting the code free. It simply involves an engineer pushing the code out to the live version of your site. Done, it's released. Trivial features and improvements are released, and don't require big picture thinking, long checklists or the involvement of people across teams for them to be successful.

  • Launching is a strategic release with a clear plan. The act of releasing the code is the same, but there's more planning in place to coordinate the release process and what happens afterwards so the product is a success. Larger projects are launched.

Now that you have your “let’s launch it already!” mindset, here are some ways to make sure your launches are a success:

  • Consider three important dates

  • Treat launch dates as a range

  • Use launch checklists

  • Consider the whole experience

  • Keep cross-functional teams updates

  • Launch reviews

  • Celebrate the win

  • Post-release feedback loops

Let’s dive in.

Consider three important dates 📅

Most of your stakeholders will only care about when the product is going to be finished and in customers hands. They want the launch date.

There are other important dates you need to know that will drive the launch date —dates other stakeholders will care about. 

  • Ready for QA/Testing. This is the first date you should know from the day your project kicks off. This comes from your engineering team’s original estimates and is when they tell you all the code should be completed and ready for QA. During development, this is the primary date you're aiming to hit on time. 

  • Ready for Release/Merge. This date is dependent on when everything has gone through testing, code review, and has been approved to go out. If there is a lot of feedback during QA that requires fixes and changes — it takes longer to be in a position to release. Depending on whether you're working in Scrum or Kanban, the scope of work, who's working on your project and your experience with release cycles on the team – you can estimate how long you think it will take to go through QA.

    I usually provide this date to people once I've spoken with the QA engineer/manager and the technical lead for the project and there is alignment around when we're in a position to release. When I know when we're able to release, I usually share the expected launch date too.  

  • Launch date. This date could be the same as the date above, but it often isn't. There may be an exact date you have to launch on, or there could be another major product release happening at the same time and you hold off on yours.

Treat launch dates as a range 📏

Every time I've said that a product will release on an exact date more than 2 weeks out from that day, I've been wrong and had to go back and communicate an updated time to people.

You should treat launch dates as a flexible date range. Things come up, last minutes bugs that block the release take a day longer to QA than expected, or the releasing engineer is out or pulled into something urgent and the release gets pushed. 

It happens more often than not and a best practice to save you going back and forth and only set expectations once is to say, “We've planned our launch to be between X date and Y date."

Your range will have a lower and upper bound, meaning it could happen earlier, or it could be later. 

How you get to these dates shouldn't be a thumb-suck. You should work closely with your team to figure out what needs to be true for the earliest date to happen, and what could go wrong or come up that can push it to the later end. 

You should do this unless you have a hard launch date requirement, in which case you need to work your plans and execution around releasing on that date.

Launch checklists ✅

As a PM, you need to stay on top of every piece of work — across all teams — that needs to be done before launch day. 

When you're focused in on building the product, it can be easy to forget the other areas of the company that will be impacted, and you want to leave as little as possible to chance when releasing a new product.

A launch checklist is an important remind of all the action items you need to have done before you can release to customers, and it helps you keep your launches consistent, avoid forgetting things, and making mistakes. 

The team you're on may already have a launch checklist template in place. If not, you should create a checklist for yourself well before you get to the launch date. 

These are some examples of areas to consider in your checklist.

  • Product. Has it gone through testing? Has the code been reviewed? Have key stakeholders been walked through the product? Do you have analytics and reporting ready?

  • Marketing. Has your G2M plan been created approved? Is your marketing team fully aware of all the elements of your G2M and ready to execute?

  • Support. Does the support team know about the release? Are they trained and familiar with the new changes? Is there internal documentation? Are there customer-facing help articles ready?

  • Sales. Is your sales team aware? Do they have sales collateral?

  • Legal/Finance. Have any policies been updated? Does legal or finance need to review this before launch? 

Once you figure out what sort of checklist works well for you and the team, you can create a template and introduce it as a new process going forward. 


Consider the whole experience 🤩

The new product you're launching isn't just about the technology you've built. There is a whole lot more that creates a complete customer experience. 

Yes, people will use the website or app and that experience is extremely important, but there are other touch-points that make up how customers end up perceiving and experiencing the product.

The product should be fully supported by marketing and support. Think about the emails, push-notifications, help articles, landing pages, and support conversations. 

The more you think holistically about the customer value, the better the whole product experience will be for people. These areas should all be addressed in your launch checklist. 

Keep cross-functional teams updated 💬

People on other teams are going to be working around the launch date of the product. 

From when you start building all the way up until launch, make sure you're keeping people who are involved updated on timelines so they can prioritize their work, be accurate in their communication to other people, and be prepared for launch. 

This communication can be a simple email or slack message and doesn't have to be a full status report.

Launch reviews 🧐

For larger projects that are being launched instead of just released, you should setup a lunch review meeting with senior management and necessary stakeholders. The goal with this meeting is to get final approval to launch the product, however you should expect to get feedback. 

Once you have all your plans in place and the product is in a shippable (or at least presentable) state, aim to set this meeting on the calendar a couple of days before you expect to launch the product so you're able to address the feedback without needing to push out the launch. 

You shouldn't have been building the product in a vacuum, meaning this shouldn't be the first time stakeholders are seeing your go-to-market strategy and nobody should be surprised that this is what the product looks like. In most cases the feedback you should be getting at this point are opportunities to improve something, and suggestions to flesh out something more in the plans. 

As feedback comes, you need to prioritize different peoples perspectives and opinions, and be able to differentiate between what must be done, and what's just an idea. 

Taking feedback from executives and senior stakeholders and managing your communication with them around that is a people management skill that you build overtime.

Celebrate the win 🎉

Generally speaking, outcome should be celebrated, not output. 

Outcome is when the products you ship have a positive impact on customers and the business, whereas output is just something tangible that comes for the hours your team puts in.

For instance, output is when an engineer writes and releases 1,000 lines of code. Outcome is when that code leads to 1,000 new customers paying $15 a month. That's the really exciting stuff that's worth celebrating – when you're getting validation that you're on the right track. 

Output is of course important because it's the building blocks towards impact, but it's possible to be spending hours building and releasing the wrong stuff. Imagine cheering for a marathon runner every mile he finished – that's great, unless he's running in the wrong direction. 

When you get to the point of launching a product, that is definitely a win - and even small wins are worth celebrating for team morale. However, be mindful that you are celebrating output. 

People across the company, many who wouldn't have been involved in the project at all, will be interested to know what this launch is all about and what it means for the business. 

At launch you should definitely make an announcement to the company, and you should have three goals with this initial, output-driven, announcement: (1) to inform, (2) thank, and (3) excite!

This first launch announcement should be a company-wide message that you send out the day of the launch. It should explain what this project is, why the team worked on it and how it fits into the wider company strategy. You should also thank each person who worked on it and acknowledge the team at the company level. The more personal each thank you is to each person for their contribution, the more meaningful it is. Avoid a general message like, “shoutout to the team for their hard work”, and go with a “Shoutout to Jeff for all the thought he put into the designs and time spent prototyping with customers!”. 

Once you have real data, share post-launch updates with the team and company. This is an outcome-driven update, and it's all about the results you're seeing after launch. The data you're seeing could be good or bad news – and it should be shared either way. There is nothing wrong with bad news as long as you're learning and able to take actions based off that. So when you're not seeing the success you expected, make sure to share your insights with the team and let them know what the next steps are. 

Post-Launch Feedback Loops  👂👀

Post-release feedback loops are the engine of incremental product development. The launch is just the beginning. You now begin a cycle of listening, learning, iterating and shipping improvements based on real customer feedback instead of assumptions. 

After your product goes out, you want to make sure you're finding any issues or points of confusion that could be blocking people from discovering, understanding, trying, using or paying for the product. You also want to figure out what the future opportunities are for the next iteration. 

Post-release feedback loops can be broken down into three phases:

  • Gather and listen. Before launch, you have a set of assumptions and hypotheses about your target customers and why your product matters to them. The moment your product is out there and in people hands, things start to become more clear because you can start getting real qualitative and quantitative data. 

    Your first goal should be to collect as much of this data as possible. 

    This qualitative data can come from post-release customer interviews, insights from the support team, and keeping an eye on forums and social media.

    Your quantitative data can come from in-app micro-surveys, larger surveys, usage analytics and log reporting. 

  • Understand and learn. The next step is to go through your new data set and use it to answer a specific set of questions. 

  • Use it to drive what's next. Take what you’ve learned and create a set of action points. For instance if you find out that your subscription pricing page is too complex, work with a designer and figure out how to simplify it.

Have any thoughts, questions or feedback? 👇

Leave a comment

Every week, I write about product, startups, growth, working with people, and anything else that I’ve found helps me have a happier and more meaningful career in product management

If you’re not as subscriber already, join below. It’s free. 👇

If you enjoy this newsletter, and know someone else who also might, you can share it below👇

Share The Product Slice