Launch Planning

Launch preparation should commence well in advance of the launch itself.  At a minimum, start this process 30-90 Days prior to Dev done.

Plan the Launch

If you have planned your launch properly, you will have detailed answers for each of these questions.

• Develop a Marketing Communications Plan

  • Determine the target audience for the release.  Who are the users?

  • Determine which platforms (JVM) the project is going to run on.

    • Target one of the Open Source JVM's.

  • Learn about the segment of the community that is interested in the features planned.

  • Create the product site look and feel with Lorem Ipsum text.

  • Create the message for the product.  Why is the product valuable for the audience?

  • Identify the channels that will be used to announce the release.

  • Identify what blog activity will take place prior to the release

    1. Number of blog posts

    2. Topics & sites the posts will be put on: Reddit, LinkedIn, 

    3. Author - who will write the blog posts?

    4. Timing of posts running up to launch

    5. Traffic generated from Blog posts should point to product site.

• Develop a documentation Plan

  • For every product, and every platform needs an installation guide. Ex: Windows/Oracle JVM v 9 + product - we need a 'How to install' 

  • What kind of documentation is needed?

  • What format will the documentation take?

  • What kind of user help / in application documentation is needed?

  • How will users access the documentation?

  • Who is going to write the documentation?

Execute Marketing Communications Program while Development is taking place

You may not know when Development will be done, but the goal is to be ready, and be creating buzz while development is in flight.

• Build Product Site

• Create blog content & Push to social media channels

• Update GitHub Repository readme to the product site

• Create Gitter Channels, any chat channels in the plan

• Develop Support Program

  • Who will be moderating forums and chats?

  • Is there an internal response SLA for Critical defects?

  • Is there an internal response SLA for Pull Requests?

  • Have to figure out what the repo structure is.

  • Public repo & private repos

  • Someone to review the code, manage the merge

  • Determine if the fixes coming in are working. 

  • Can't ignore or fail to merge fixes coming in from the community.

  • How is this all staffed?

Prepare the Engineering Release

There are a series of steps to finalize an Engineering Release.  These are separate from a product launch.

• Complete internal Release Readiness Review

  • Is the code of high quality?

  • Has it been tested?  How thoroughly?

  • Are there any known issues with the product?

  • Are any of the known issues blockers?

  • Builds installer via CI nightly

  • Have built what we set out to build at the onset? Does the release match what we have communicated in the launch plan?

  • Have we executed against the Documentation plan?  Aka - is documentation ready?

• Show the release to the membership

  • Trial run: In Dev Standup with Greg 

  • Forum: Community hangout (trial run in Dev Standup)

  • Review documentation about the release (release readiness review)

  • Demo to Members

• Pull the package for download link

Execute on the Launch Plan