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.
- Front-line Users
- Customer Purchasing Decision Making Unit (technical, business, financial)
- Distributors: Marketing, sales, operational teams, customer support
- Value Added Resellers: Marketing, sales, operational teams, customer
- Sales Operations
- Account Management
- Customer Service
- Contract / Legal team
- Installation Teams
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.
- 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),
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.
- 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?