I recall extremely early stage where you’d build a feature, realize it was awesome, then the next day write a blog post for it. At some point you start to move from that to more coordinated launches. A larger coordinated launch allows you to reach a bigger audience, can lead to bigger deals, and help expand your overall market. But perhaps more importantly by the time you hit full launch you’ve message tested and ensured it’s going to resonate in the way you expect.

The process itself will both help amplify and validate/refine your message

This is often a more gradual process than a sudden single change, you’ll introduce new parts of this in time. And for many what an entire launch process looks like comes by trial an error, to help shorten that learning curve here’s key areas I pay attention for a launch and process followed by a rough timeline.

Product first

Making sure the product is in the right shape is key to any big launch. You don’t get a second shot and if the product isn’t in shape customers often won’t take a second look at it later. For this reason I strongly prefer to have your product locked and loaded before you even start talking launch times, or at least be in the bug clean up phase. This means you’ve built a feature, validated with alpha users or private beta, and are ready to open it up to the world.

If you have to set a launch date without the product or feature being already done allow padding. Sometimes it’s good for the team to know the padding, sometimes it isn’t. When you have extra time it’s not uncommon for your development to magically consume exactly that amount of time and still result in a small scramble towards the end.

A good driver I’ve found is needing to have it fully like to demo a few weeks out from the launch itself, such as during analyst pre-briefings.

Crafting your message

Every launch is an opportunity to tell your core message and value prop. If you miss this opportunity for focusing on a single narrow feature you’ve missed the biggest opportunity you had in a launch. You can’t relaunch your full product every time though–you do need some big improvements or feature that you can highlight, but you should still hit your core message.

First you should know that your feature solves some specific problem, you should know this from the alpha/beta testing and if it doesn’t solve this problem you’re not ready to launch. Yes, some people will launch a product before the product is completely there–this is common in a marketing driven company as opposed to a product/engineering driven company.

Your message should lead with the problem you’re solving, not the laundry list of features. The best launches lead with some broader thematic message, even better if it’s an altruistic world changing one. A rough example of this:

To the point to the product, and probably over generalized as boring:

• Connectify brings a new way of taking your dumb devices at home and turning them into intelligent connected devices.

In contrast, broad thematic message, followed lightly by the product.

• We live in a connected world, and with new connected devices there’s the opportunity not just give you more data but help you improve how you live your life. Connectify helps you at bringing the devices that matter together with ease.

Testing your message

You should treat your message just like a product, testing it gradually along the way. Once you’ve got some initial framing of it, test it internally, then with friendly customers or community members. Leading up to the launch I usually have a timeline and get all the content and communication rolling about 3 weeks out. I’ll give a bit of a timeline below but first some more around message testing

Analysts

If you regularly use any analysts you should absolutely use them to help with a launch. Several weeks out is a great time to test key messages with them, get feedback, and if you’re lucky you may even get them to provide a quote for the launch.

Keep in mind here a inquiry is an opportunity to test your message and get feedback. You should talk roughly half of the time here, they should be talking the other half. In contrast briefings before launch you should have your message fully baked and should simply be pitching your message and possibly demo-ing.

Friendlies

This may be more contentious, but at least at early stage sharing drafts with friendly community members is a great way to get feedback and refine your message. Here you should be especially concious of the request of their time and expect to have some delay before they get back to you. Being top secret about your message ahead of time won’t add much value to it being a home run, where as better ensuring it resonates will help it to be more successful.

Customers

Customers I call out as a separate bucket. Customers have less incentive to leak your news than friendlies, but also fall somewhere on the other spectrum of analysts. A key piece about customers is there is an opportunity for them to be a launch partner. And so on to that topic:

Launch partners

Press and others like seeing and knowing you have external validation. Similarly many see the benefit of being part of a launch, after all it’s more free press for them. For a launch partner there are various levels, though for most providing some quote is a pretty common level.

The best way to do this is talk to them about what they like about the feature/product and take a first stab at the quote for them from their feedback. Some may very much want to wordsmith their own which is fine, but minimizing the work required of them while–trying to hit something they’d say as well–as a message that flows can best be done by you taking a first pass.

Further there’s varying levels of value with quotes and references. In descending order:

1. Customers
2. Analysts
3. Community Members

The other details

During launch week I mostly want to be dotting i’s and crossing t’s, meaning: I want the product done. I want documentation done. I want the blog post finalized. I want to be in the mode of send internal announcements, prep internal teams, talk to media.

Prepping internal teams

Obviously the engineering and product people involved will be in the loop. But you need to notify many others some of which should have been in the loop already, some less so:

• Support - There’s a new product surface area, support should be top of your list so they can field the tickets and questions that come in
• Sales - Even if there is no price change or impact, new features allow sales to communicate value to customers

Timeline

Finally what’s the end to end timeline look like with all the little details. Here’s a rough one that’s fully built out. IF you’re smaller and don’t have a regular cadence of analysts in hand then just expect that doesn’t apply. IF your support team is the product and engineers maybe that’s lighter weight. Basically feel free to take out parts, but expect your process to grow to something of this size.

• 4 weeks out - Outline of blog post with key messages
• Test that outline internally
• 3 weeks out - Start to get a rough draft in place
• 3 weeks out - Share internally and with friendlies. At this point you’re explicitely looking for message feedback. Tell people to not waste time on nitpicks of words or grammar, it will be 98% re-written by the time you’re done
• 2.5 weeks out - Analyst inquiries for message testing
• 2.5 weeks out - Start putting together product demo
• 2 weeks out - Start putting together documentation
• 2 weeks out - Start nailing down blog post for final messages
• 1 weeks out - Start to put final touches on blog post for grammar
• 1 week out - Analyst briefings
• 1 week out - Update support
• 3-5 days out - Stage blog post
• 3-5 days out - Stage new documentation
• 2-4 days out - Make sure PRs are ready or feature flags, in short the switch is there or live but not public
• 1-3 days out - Update sales
• 1-3 days out - Interall communication to all@
• 1-3 days out - Media briefings
• LAUNCH DAY - Sit in a room and watch all the things, engage with twitter/HN/etc.