When I built this, the number of systems, processes, and stakeholders to keep in the loop was continuing to grow. It was not a simple 2-3 bullet point list anymore, so there was an increasing risk of missing things.

This list ensured consistency and helped PMs plan their customer awareness, readiness, and adoption strategy. Now, PMs can think about anything they can do to enhance the user experience and build better customer engagement from within the product & external channels. It also helps bring in Marketing, Sales, and Support stakeholders earlier to provide relevant input and update any processes on their end.

In terms of botched launches, we haven't ever had something go horribly wrong. The biggest challenge we face is that new features simply don't get used. Octopus is a technical product used by DevOps engineers, and it's not easy for them to simply adopt something new. They often need to make changes to an existing deployment process, migrate some data, or enable some new settings. This checklist is meant to help with some of the already high friction that exists in our new feature adoption.


I definitely recommend having a DRI for a checklist template like this, but the whole team should be able to contribute edits to it. At a larger organization, the Product Ops team might be in charge of owning this document. Octopus is currently very small, so we just try to review this quarterly and keep it updated as a PM team when we have time.


Since launching our enterprise tier, that's added a lot of complexity to our GTM process. We're now finding that a checklist isn't robust enough. Today, we actually create custom support and sales playbooks to accompany each new enterprise feature launch.


Before this, PMs would only consider go-to-market planning activities after a feature was ready to ship. This would not give enough time for a thoughtful plan and would inevitably cause chaos and delays. This prompted PMs to plan this as soon as they had started work on "solution scoping."


Our sales, support, product, and engineering teams are relatively large compared to marketing, which is still quite lean. We currently have 10 PMs but only 1 product marketer. Because of that constraint, it's up to the PM to drive a lot of our product and content marketing efforts.

At larger companies, I've seen product marketers dedicated to specific product groups or teams. That works really well, and I hope Octopus gets there one day, but for now this lean method makes the most sense.

Reliability refers to metrics on whether the site is available and is performant (e.g. API-related metrics, speed of deployments, etc.). Essentially, we want to be sure that it all works and does not impact the basics. Usability, on the other hand, is really about the user experience and behavioral data. Is the feature in its current shape easy to use and solves a pain point? Functionality is to understand if there are pieces missing or if there's part of the problem we haven't quite solved. We want to know not just that the feature can be used, but whether users are actually getting a lot of value from it.

If you break down the types of things we ship, there are roughly 3 buckets: net new features, enhancements to existing features, and bug fixes/security patches. For new features, we put a lot of effort into GTM and prepare Support really well. This checklist is just the beginning — we also now have Support and Sales playbooks to educate our internal teams on new capabilities. But each PM does this really differently (live presentations, slack messages, documentation, etc.), and this won't scale if we get too much bigger. We still need to do a lot of work on Support and Sales enablement.


From my experience, getting customers to adopt new capabilities in a B2B context is much tougher than in a B2C context, mainly as B2B has low numbers of customers with many complex and niche use cases.

In B2B (especially with a technical product), your users are typically getting paid to use your product, because it makes their job easier. In this niche, they aren't always going to be digging for new ways of doing things. They want the tool to provide the best practice. So we're always building guardrails into our features so that users are always on the happy path.

Ships Mahindra

I created this checklist to help PMs plan their customer awareness, readiness, and adoption strategy for new technical features.

A Product Manager's Go-to-market Checklist

The purpose of this checklist and how to use it

When starting a new initiative, as PMs we should be thinking about how to launch it 

so our customers are aware and can start using it

. Depending on the impact and effort of what we are delivering, there can be a number of things that go into the preparation of launch. This checklist attempts to encapsulate some of that.

Feel free to bring it into your tool of choice and customise for your initiative and team.

PM Go-to-Market Checklist from Octopus Deploy

A Product Manager's Go-to-market Checklist

Go-to-market Checklist

⚽When you are kicking off an initiative

✍️ 4-6 weeks before launch

Sign up to see more