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 stakeholdersConsider 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)
- Distributors: Marketing, sales, operational teams, customer support
- Value Added Resellers: Marketing, sales, operational teams, customer support
- 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 MaterialsAs 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 ListIn 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'
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 regularlyCommunicate 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!
Post a Comment