My name is Talia Moyal and I’m the Head of Product Marketing at Airbyte, an open-source data integration platform.
In this article, I’ll walk you through launch basics, but I'll also sprinkle in information specific to how to think about launching to developers. I’ll share best practices specific to launching to the developer community as well.
Here are our main talking points:
- Releases vs. launches: why it’s important to distinguish between the two
- How to tier your launches
- Launch phases and lead times
- What to do post-launch
- 5 best practices specific to developers
Let’s go ahead and dive in.👇
Releases vs. launches: Why it’s important to distinguish between the two
Release: definition
A release is engineering-, product-, and design-driven, and it's a finished product ready to leave the building. It's especially important within developer tools to have this be its own distinguished thing, because you want to have tight iteration cycles.
SaaS products often have high product velocity on the development side and you want to make sure they're not blocked by go-to-market teams. You want them to always be releasing what they have, ready to get feedback from users, and then incorporating this feedback back into the product.
The best way to do this is to give them their own part of the process, call it a release; have some guardrails around the difference between what happens with a release and a launch, but give them space to work at whatever development velocity they want.
I like to make sure releases and launch planning start at the same time, so we're both on the same page and cadence for when features and products are ready to be spoken about externally.
However, I always give myself at least a few weeks' buffer between a release and a launch. This is especially useful if you slip on any release dates.
It gives you time to fix such mistakes so you don't have to move your launch date back, as that's often a lot more impactful than moving back your release date. With launches, you're talking to a lot of external vendors so you want to make sure you're not changing things up on them.
Launch: Definition
A launch is driven by product marketing, packaged goods and its surrounding activities. A launch is all of your content, enablement, ads, webinars, press, everything you're doing, to create momentum around the release.
A launch is not just a single moment in time, it's a ton of activities for a theme you're trying to create and a momentum around in the market.
A launch might have a date where you break your embargo. You're saying, "on this date, we're going to openly speak about the features that were part of that release".
Then, after that date, while no more activities happen for the launch, it's important to speak about how you built your products, and show their value, any changes made, and the workflow to those developers. This is especially important for things like developer tools because there's a lot of cool content you can create after a launch.
How to tier your launches
Everything always starts with a release. A release can either impact new users or existing users.
If it impacts new users, most of the time, it's going to be a tier one launch. This means those top-of-the-funnel folks are going to be excited about this new innovation you're putting out into the world. Also, you're going to treat it with the most amount of resources as it'll be the largest momentum and can be a big turning point for your company.
Oftentimes, tier one launches can also be accompanied with large website changes, brand redesigns, etc.
If the release impacts existing users and it changes the user flow, then it's a tier two launch. If it’s about features your existing users have been asking about but you don't think new users would care about, that's a tier two launch. Those launches are also impactful and can move the needle for your business.
If it changes the user flow but it's visible to the user, that’s a tier three launch. It’s maybe something you want to let your users know about but you don't need to do a ton of enablement or create a ton of content around it, and you definitely don't need to staff it very heavily.
If it changes the user flow and it's not visible to the user, it's likely a release. You don't need to support it on the go-to-market side. It's important to identify features like this because not every release is being accompanied by go-to-market resources, especially with early stage startups.
Launches phases and lead times
Launch phases can be defined in four parts: planning phase, creation phase, execution phase, and then post-launch (which will be discussed in the next section of this article).
Phase 1: Planning
The goal here is to align all your stakeholders and to get organized. Schedule any recurring meetings you need, assign your launch objectives, decide what type of existing materials need to be updated, etc.
Especially with developers, you want to look through all of your demo flows and ensure any new features, no matter how small, are included.
You never know what will resonate with people, so update any sales pitches and cross-functional calendars, and then name your features early. Personally, I also like to have code names for my launches, so that if I do change any naming for features, it doesn't impact the entire project.
For planning, you need to have at least four to six weeks before your launch date. This timeline is average for a tier one and tier two launch.
For tier one launches, I've also had launches that take an entire quarter if you're moving into a new space, like doing a full website or relaunching things requiring about a quarter's worth of work because you're doing a lot of research leading up to it.
Phase 2: Creation
The creation phase is about all of your launch deliverables, so you're creating content, data sheets, blog posts, landing pages, ad creative, anything email related; essentially, anything created is going to happen here.
You have to think about lead times for review. Especially with developer products, you're going to be creating a lot of very technical resources and you'll likely need engineering resources to help review this so give those teams a heads up. They will need to include some of the reviews in their sprint planning.
You’ll also need to identify some folks who can help create content. Personally, I like to do a “how we built this” series for tier one launches and I find that having the engineers write them is especially helpful because they're the ones who built the product and they like to nerd out on it.
It's a great way to create some synergy there and give people a look under the hood of how things were created and inspire them for how to do it on their side as well.
Lead times should be around three to five weeks before launch date; however, three weeks is cutting it close for tier one launches because of the review cycle so keep that in mind.
Phase 3: Execution
The goal of the execution phase is all about shipping the deliverables. In this phase, you’re holding your enablement sessions for your sales team, go-to-market team, engineering support teams, etc.
Personally, I like to have enablement in the weeks leading up to a launch. I have a session every week before tier one launches. This is to make sure that I'm not overloading teams with information.
Specifically for developer tools, I like to include engineers in those enablement sessions to speak through either a demo or the value the product has for them.
Having a Q&A with the engineers and having the sales team ask them questions (such as, how does this impact you? What are you most excited about? Where was the most friction for the product when you first used it?) helps your sales team by hearing how engineers are speaking about the product.
The execution phase is also when you're sending all of your internal communications, shipping out all your resources to your internal teams and your external communications as well as publishing any website changes. A lot of this can happen during the week of the launch.
Phase 4: Post-launch, the response phase
This phase is the most overlooked. I've done it in the past. This phase is important because a launch is not just a single moment in time, it's momentum for a theme and for the value you're creating for your users and you should be thoughtful about how you approach this.
Publish more content
Think about how your product changed your users' lives for the better and how it compares to the competition's.
Having a series of “how we built” this feature, getting into architectural changes and decisions you made is very appealing, especially for developers.
Analyze activities and double-down on what worked
Above is a basic list of metrics I like to have for my launches. I also like to create dashboards for product launches and have these live before the launch to have a baseline to compare to.
This is especially helpful when you have other stakeholders who want to know what happened with the launch (you can point them to the dashboard).
However, remind them the launch is not a single moment in time and that they won’t see a crazy spike in usage the day of the launch, but should expect to see these numbers grow over time in the 48 weeks after your launch.
The metrics I’ve shared above are general but there are definitely some you can think about on the product usage side. Every tool is different so think about what's most important to your company.
Feedback
Look at feedback and ask yourself, “did this launch trigger any Twitter/HackerNews dumpster fire, what happened?”. This can be negative or positive but think about why those things happened and how you can either capitalize on them or what you might need to change on the product side.
You want to think about any media attention you attracted but weren't expecting. Did your support channels blow up? Are people writing that they don't know how to use this product and need help with documentation?
Thinking about where there are breaks in the workflow and what people are asking about is a great opportunity to connect with teams.
On the customer-facing side, is the team getting inundated with questions? Sit in on as many demos and pitches as you can to understand how this product and feature are landing with the market.
Think through, especially on the developer side, what people are getting hung up on. Developers like to focus on specific pieces of workflow and they might ask you for specific features you hadn't launched, so think about the reason why and get a holistic picture of what's going on.
Anthony Witherspoon
Validate pricing
This can be contentious but I believe you can validate pricing post-launch (and you should). What I mean by this is, especially with SaaS products, you're trying to understand the price point people are willing to pay for different tiers of a product.
It's very difficult to get information on this exact price point if you have a small group of people who are testing your product.
I like to publish pricing in tiers. Have your models figured out but validate the actual numbers for those price points during your launch. Don't be scared to change the numbers you publish on your website but keep the tiers the same.
I say this is contentious because a lot of people think you shouldn't change pricing very often. Obviously, I don't think you should be changing the models for your pricing very often but it's okay to change the numbers during the launch, as long as you keep it to two to three times a year.
Above are some discovery questions you can be asking yourself. Think about how much friction there is with pricing, especially with developer tools, as devs have access to all the variables they require in order to put together a pricing proposal.
What I mean by this is, especially with developer tools, you're often charging on data. Sometimes you need developers to be able to estimate the amount of data volume coming out of a product in order to understand how much it's going to cost them to use yours.
This can be difficult so make sure your pricing is as easy to understand as possible. You're not reinventing the wheel with pricing, but it should be something that flows right through procurement teams, is easy to understand and doesn't require a developer to plug-in numbers to understand it.
Breathe, retro, party
Take a moment to breathe, retro what happened, and celebrate your successes and failures.
Failures are also a part of learning and you should celebrate them. For this, there are three things I like to think about:
- Don't iterate too fast: It's easy to get bogged down in making quick changes, especially when you're looking at metrics with the pressure of an external team saying, “why isn't this making the impact we need”. Remind them it takes time for changes to take effect. You want to be aware, make thoughtful decisions and react to those changes but you don't need to iterate on everything or act super quickly.
- Split retro into a few meetings: Especially with the number of people involved in launches, you want each group of people to have time to give you feedback so you can organize around it.
- Do something special for all those teams: Give people gift cards for dinners or send them special care packages. Make sure that everyone feels like they're an important part of the launch and know they should take time to relax as well.
5 best practices when launching to developers
Skip the press release
Obviously, press releases can be very helpful in creating momentum, especially around a business, but for the developer audience, they often don't move the needle.
That's because press releases are focused on the value you've created around the business and often include marketing jargon. If you can't skip the press release, don't spend too much time on it.
It won't be important for the developer audience but it might help you generate press for the business.
Invest in hi-fi demos
This is super important, especially for developers, as they like to see what they're using. If you're releasing any features that are in beta or you're doing any marketing ahead, having high-fidelity demos showing developers exactly how the product is used can go a really long way.
Precision matters
A lot of GTM teams can get hung up on this, especially if they're not technical. You have to ensure you're speaking the language of your developers and thinking through all the nuances in the different types of developer tools.
If you're working for FinTech or for observability, you’re speaking in different ways to developers, even within those groups, so you need to understand their language.
That's why, for the creation phase of the launch, when you're creating content, you need lead times. Have your developers edit them to ensure your language is accurate for the group you're speaking to.
Danni Scott-Duke
Self-serve everything
This is important, even for growing a developer business. Developers should have the opportunity to self-serve from websites to try out your product. Make sure there are no blockers, and they don't necessarily have to speak to a sales team, so they're able to try your product and see what it's like.
This goes a long way with folks if they're quickly trying to figure something out. If you can't self-serve for everything, maybe you don't have the engineering capabilities or resources to do this and can think about creating a sandbox environment people can play in. This can also be helpful.
Plug into their ecosystem
Think about how to partner with other products they're using. This is useful when you're repackaging features. Think about how to get some distribution across partners, and where in your developer's ecosystem this new feature set is going to sit in, and make it clear to them.
When you're creating content, talk about how the new feature set will work really well with the existing workflow they're using, and talk about those other products, even if you're not partnering with them.
Already part of our Slack community? If not, join today to network with other developer marketers, get job offers, and keep up with the latest trends.
Developer Marketing Alliance
