July 10, 2015
Heavybit Launches The Developer Marketing Guide
Heavybit launched a new Community Project this week: The Developer Marketing Guide. Our mission is to collect the best resources for develop...
One of the most common mistakes for early startups is the failure to account for approvals when building your PR assets. While it’s easy to prep all your assets in one night, it’s not easy to get all your stakeholders to approve them. In many cases it takes several weeks and you need these stakeholders to solidify the value of your product, to tie you into a larger trend, and to legitimize you via interviews and quotes.
This is particularly important if you’re announcing funding or a partner launch. Today’s post will offer you a list of common stakeholders for you press launch and a work back schedule to build your assets with plenty of time for approvals.
Approvers are different than stakeholders. For example, your developer customer might be one stakeholder, but you’re not going to offer them pre-approval rights on your launch posts. Nevertheless, your investors, advisors and partners might fall into both the approver and stakeholder category. Common press approvers include:
If you’re just launching an incremental release, then you might just need some basic tweaks to your documentation, a blog post and a note to users. But if you’re announcing a bigger feature or product release, a partnership, or a funding announcement; then you should consider your timing on approvals.
Core Messaging Doc: At this point you should be in the testing phase of a new product or release and you should have a good idea of the new functionality or value you’re offering to customers. Craft that value in a single page document and answer the following questions in plain language:
Once the core messaging doc is complete, get internal approvals from managers and execs. This document is the master factsheet for subsequent launch material. Circulate it to relevant internal teams including the support and sales people in order to get them prepped and to ensure consistency across their materials.
Draft Release: It may seem a little premature to write this release now, but in order to get partner, investor and advisor quotes and sign off, you’ll have to start the process now. Give yourself ample time to request multiple quotes. Expect these approvals to take at least 3 weeks and expect to make edits along the way.
FAQ: While you’re working with external stakeholders, it’s also important to brief internal teams. Draft a list of technical and press FAQ and be willing to answer each question honestly and in plain language. Technical FAQ might include support-related questions. If your launch requires some sort of additional integration from customers then brief support and sales engineers. Press FAQ tends to include questions that poke holes in what might otherwise seem a somewhat saccharine launch. Questions about security and safe harbor are all fair game. Answering these honestly will offer customers the information they need to make informed decisions. It will also help your sales, support and developer evangelists do their jobs.
Blog Post: At this point you should be circulating a draft blog post for internal review. Don’t get too caught up in the wordsmithing of this post. The facts of your launch are sitting in your core messaging doc and most people will get to a blog post after reading a release or press story. While the blog post is often written conversationally and in the voice of a founder or product manager, you should still use inverse pyramid style and front load the most important information while ending with the call to action.
Landing Page: In the case of new product releases, you’ll want to build a campaign landing page to create a permanent home for this product and track referrals. Some companies will make this page public and include a countdown clock to tease press and customers. Others will simply test this landing page in their production environment and push it live 30 minutes prior to an announcement.
Demo Video and Graphics: If your launch requires a demo video of graphics, you should have these ready with at least 2 weeks to launch. For videos in particular, you might offer journalists a password under embargo to strengthen their understanding of a story. You’d then offer the public launch URL or embed code with the understanding that you’ll take the password off a few minutes prior to launch.
Note to Customers: Craft a note to customers to go out at the same time as your press release embargo lifts. In the case of your largest and most affected customers, you might even pre-brief them under NDA and offer early access and support on upgrades and integrations.
Staff Briefing: Brief staff to help them understand what you’re launching and their role in the announcement. This might be as simple as offering them the facts and asking them to share via social networks upon launch. It might be as complicated as asking that dev ops, sales and engineering test the product in staging and raise flags or plan for additional support.
Pitch: By now you should have a shortlist of press you hope to pre-brief and a series of approved angles and pitches. Each pitch should be tailored to the individual journalist and the person pitching your story should be armed with the FAQ, graphic/video assets, draft release and key quotes to followup with journalists. You should be reaching out to journalists at this time to accept your embargo.
Press Deck: While press decks aren’t necessary, for complicated technical topics it’s best to create a deck and offer it during press briefings. Once journalists have been briefed, PDF the deck and include it alongside your other assets for review and fact checking.
Call Scripts: If largest and most affected users need additional support on upgrades and integrations you’ll need to create a call script for your sales staff and support group. One example might be if you’ve released a European product and need to migrate a portion of your client’s customers over to the new EU service. Your staff should have a call script prepped in order to answer relevant questions and ensure efficient migration.
Sales Deck: All the work you’ve done on your messaging doc, blog post and documentation should be cascaded into your sales decks and presentations in order to ensure that your inside sales team is selling on your newly expanded statement of benefits.
Social Media Updates: At this point everything including your blog post and release should be scheduled to go live. At this point you should craft your social media updates and pre-schedule them through a tool like HootSuite or Sprout Social. You should also know who will be submitting your post to HackerNews and Reddit and at what time they plan on doing it.
Alerts and Monitoring: Monitoring tools like Respond.ly and Google alerts are particularly useful for listening. Create alerts and pre-written queries on the title of your launch product and your company name. This will help you manage questions that come via social media and external communities.
This article is the third in a series on PR best practices. Other articles include: