Product Launch vs Release vs General Availability vs Deployment

These terms are tossed around with gay abandon and, as a result, cause some confusion, particularly in the minds of Sales and Marketing folks.

Here are my definitions:

Product Release	This is when the product has ready to be deployed. For Development (ie Engineering and Testing), their task is complete and they can roll onto the next development cycle.
Product Launch	Product Launch is a marketing announcement. This is the bright lights, drums, trumpets and dancing elephants moment. This is when you want the market or your customer base to know about your new release and to seed your lead generation process
Product Availability or General Availability (or GA)	This is when a customer can use the product.
Product Deployment	This is when it is activated for the customer. Whether a particular release is actually given to anyone or deployed is a decision made by Product Management, not of Development. Agile + continuous deployment means that this decision can be so implemented that it may by-pass Product Management, if due process is weak.
Pre-release	This is a term that is used in two scenarios I think: a) By sales to demonstrate new capability, but to set expectations that this product isn't quite ready for use, but available for demonstration (ie for customer consideration of adoption).< b) By product management to encourage potential beta customers to step forward as beta candidates

Some nuances

There is a difference between GA and Product Deployment is when a B2B vendor needs to ask permission from the customer before the software can be deployed or activated. For example, the new functionality may require the customer to do something (eg all users might have to log off or there might be down time) or the customer's staff may need training or the deployment might need to fit around the business cycle of the customer's environment (eg ecommerce customers dislike new functionality or surprises during the Christmas season for example).


A product may be announced before it's available. This is done to seed the market & to generate enquiries into the sales team. It may be done to spoil the market - eg pre-announce functionality to steal the limelight so that you look like a thought leader and competitors appear to be second to market. Big SaaS providers (think of Salesforce for example) forward announce deployments and their release dates in order to seed their ecosystem of customers and partners with this news.

A product may be announced after it's been available and deployed to beta customers - this allows for the generation of success stories in order to encourage adoption either by the existing customer base or to generate confidence & interest from prospects.

In B2C products, product release = product deployment

Apple famously make Product Announcements on one day with GA on the next day globally. This requires incredible planning (and draconian secrecy) to implement effectively. This can do this because Apple provide single-vendor products - they don't have complex ecosystem of 3rd parties around them (in general). Their secrecy about their product releases is legendary. Indeed, the tech press have taken to tracking shipping consignments from Foxconn factories in the Far East to California to guess product ship dates!

After all, customers don’t really care about releases; they care about availability. Sales and marketing folks don’t care about releases; they care about launches.

Launches must be aligned with the rhythms of your market, not the rhythms of your internal teams. Product marketers should align availability with customer demand.

You can do limited availability any time of the year but broad adoption takes place when the market is ready, not when development is ready.

The mighty Steve Johnson (formerly of Pragmatic Marketing) writes on this topic: Why a release isn't a launch

How to build a Product Release Checklist - expanded

On Tuesday evening, I was one of the panelists at a joint Chartered Institute of Marketing  and Cambridge Product Management Network event on Product launch disasters – and how to avoid them!

Prior to the event, I reviewed other examples of Product Release Checklists (eg New Product Launch Checklist and one of my own Checklists), then I thought that they were too specific for the product / release in mind.

So, as a Product Manager / Product Marketing Manager going through a release, you have to build you own. (Do use the examples above as reference - they aren't bad, just that you don't know their purpose!)

More useful, I thought, would be my technique for Building your own Product Release Checklist - technique that I used when I was brought in as a consultant to help deliver a release for ADP Dealer Serivces from June 2011 to March 2012

1. Determine the impact on all stakeholders

Consider how the release will impact all the stakeholders - both external (eg customers!) and internal . Some are obvious, some are more obscure and requires you, as the Product Manager to know how your company operates. See side panel for the list of (potentially) affected business functions for a B2B product release.

External Stakeholders Customers

• Front-line Users
• Customer Purchasing Decision Making Unit (technical, business, financial)

Channel Programme

• Distributors: Marketing, sales, operational teams, customer support
• Value Added Resellers: Marketing, sales, operational teams, customer support

Internal Stakeholders

• Sales
• Pre-sales
• Marketing
• Sales Operations
• Account Management
• Customer Service
• Contract / Legal team
• Installation Teams
• Finance

 2. What documents will inform stakeholders of the impact?

Imagine yourself as someone in one of these business functions listed in the side panel. What information (and at what density) will this person need in order to understand the product release and its impact on their business function.

For example:

• What product summary does an existing customer require vs a new customer
• Does the product demo need to be modified for either audience?
• Are there sub-sections of the existing customer base that will need a customised 'flavour' of the product release announcement, based their requirements? (Example: This may be necessary when not all existing customers are able to upgrade to this release.)
• What information would the Legal team require to understand the release? If there are no contract modifications required, then the Legal team would appreciate a note telling them so.

3. Build a Library of Reference Materials

As you go about your journey of discovery about a product and its release, you will amass a treasure trove of documents from internal commercial requirements to technical architecture diagrams. I recommend that you use a some sort of repository for these documents (with an index - see my example). Ideally, this should be online, so that it acts as a single repository for others to use.

Do not wait for perfection before you add any document to the repository. If the answer is 'Oh, it's the same as last time', then ask for the old version. You'll be surprised at the number of times the document from last time doesn't exist OR requires substantial revision even if it is merely freshing up the corporate branding and updating the copyright notice.

4. Build an Issues List

In collecting these documents, you will inevitably discover road blocks. Examples:

• 'Well, the product will do X or Y, based on customer Z's stated requirements, which we are waiting clarification on'. 
• 'I can't tell you the final pricing structure until person X has reviewed the operational costing for this year and next'

Note these down in the Issues List with responsibility, blocking issue and next decision date. Ideally I would recommend that you use the same tool as the document management repository because the Issues List and Document Repository are closely interrelated! Other tools that I have used are Excel and sometimes a bug management list works well too although assess to this list maybe limited),

5. Iterate!

Once you have started the document chase, you will quickly find that the Issues List far exceeds the Document Repository. The next step is to work through the Issues List allocating tasks to people and making sure that they understand that what deliverable is required of them and by when. And that you'll be nagging them (and subsequently their boss) for the deliverable.

As you may have guessed, this schedule then becomes a loose project plan for the release. In my experiences, the conflicting interdependencies within project plan (eg if we add feature X then the release will take more time and the training of the sales team will require more time). It's best not to start this project plan too early as you will be creating a rod for your back!

6. Communicate regularly

Communicate your progress on a regular basis.
With everyone

• I recommend that you have an All Hands meeting about the release. This is a great way of flushing out rumours and building enthusiasm about the product release. 
• Frequency: 2-3 months before release and the week before release date.
• With mid-management:
• This is the enabling body in any organisation - this crowd needs to be (a) onboard (b) have the ability to input their concerns and issues and (c) to be seen to be contributing in front of their peers.
• Frequency: every month or six weeks prior to release
• With execs:
• This is the decision making body. You need to schedule time with these guys to drive decision-making between their business functions and to prioritise work effort within their divisions
• Frequency: Every week or every two weeks. Book the time out now, even if you don't know how or what you are going to present!

7. Don't forget to celebrate!

Lots of effort has gone into the release - give thanks and appreciate to where it is due.

8. Conduct a Release Post Mortem

After a suitable period of time after the release, gather the stakeholders together and have an honest review of the release. What worked for each business function and what didn't?

How to build a Product Release Checklist

In review other examples of Product Release Checklists, then I thought that they were too specific for the product / release in mind.

So, as a Product Manager / Product Marketing Manager, you have to build you own.

Here's my technique for building your own Product Release Checklist:

1. Determine impact on all stakeholders
2. What documents will inform stakeholders of the impact?
3. Build a Library of Reference Materials
4. Build an Issues List
5. Iterate!
6. Communicate regularly
7. Don't forget to celebrate!