Creating a Post Launch Product Plan

post-launch-plan

It seems that so much effort is invested into product launch planning and execution that when a product release occurs, its easy to take a small breath and then jump into it all over again. That being said, there are some loose ends that always exist at the end of any product launch that need to be considered and will help validate the success, and possibly even help plan the next release. Some might argue that this is part of the a product launch plan but since this is not a requirement for launch I’m treating it separately (hence things like field enablement, marketing support, etc. are not listed below). Also, it’s probably not realistic to expect this to all happen in isolation from future release planning and other day-to-day tasks so expect to run this in parallel to other activities. Below are some suggestions on what to consider once your product release has launched. I’ve tried to prioritize the order though to help with items that may be started immediately after a release vs. those that may take time to develop.

Cleanup your work queue

I’ve used Rally quite a bit. JIRA is also another example of software that helps manage User Stories, defects and general tasks that relate to a product release cycle. Post-launch is an important time to go through this list. Typically, in a product release there are plenty of what I like to call “orphaned” items that were assigned to the release but were removed from scope either through a re-balancing effort, or a deferred status. While this may all be managed and agreed to by the team, the administrative tasks of keeping this up-to-date in the software itself may not always be upheld to as rigidly as everyone would like. This is a great time to comb through those items to make sure that they find their proper place. Some may be highly important to the next release (you’ll remember the meeting when everyone agreed that it’s OK to defer this item as long as it gets in the next release…but then in the chaos of getting the release out, everyone promptly forgets this item), some may just need to go back into the backlog for future consideration, or some may tie to a theme for the next release. Although tedious, not losing track of these orphans is helpful for future planning and removing them from the release keeps a clean record of the actual work completed.

Add to your Historical Roadmap

I’ve written a separate post on the importance of creating a historical roadmap so I won’t cover all the details here but needless to say doing this now, while things are still fresh in mind, prevents the need to comb through the software release details at a later date to remember what when out when. This is a simple task of tracking the top features of the release and the date that the release launched.

Hold a retrospective with the team

This is not necessarily the job of Product Management but its something that any team should do when a major project is done. Understanding what worked well, what didn’t and how to improve things next time is a critical step to understanding how to improve teamwork and become more efficient.

Organize any final notes or documents for future reference

Similar to cleaning up the work queue, making sure you have all of your own documents and records organized will help for future reference. I like the concept of electronic folders but other may prefer physical cabinet storage, or software organizational systems like Evernote or OneNote. Whatever you prefer, keeping your files (and important emails) associated with the release organized makes future reference needs much easier.

Measure the impact – Are you getting the return you expect (revenue, PR, client interest)

You set themes for the release right? You have reasons for building the product features correct? Revisit why you chose to build these features over every other feature request in your backlog and determine if your logic was correct and if your goals are on track. You may not know the results of everything just yet. For instance your revenue goals may not be immediate but you can start to gauge progress and understand if you’re on the right track. Are clients adopting? Is sales still excited now that they’ve seen the actual capabilities? Are your PR/Social efforts showing interest? Understanding the path you are on and if that path is a successful one will  help in your decision-making progress for the next release.

Gather feedback and iterate

Speaking of client adoption, as clients start to utilize the new features, pay special attention to potentially new opportunities that may arise. It’s not unusual to discover a new use or a feature that you hadn’t thought of before until you hear about a client using it for their specific needs. This can lead to new feature requests for the next release, or it can even call out new features or areas to add into the product that hadn’t been though about in the past. Also it may make sense to find early adopters for customer testimonial gathering.

It can be tough to complete these tasks when the pressure from the release is off and the next release is heating up but taking some time to wrap up these items can really help with identifying next steps and making sure you are moving down the right path with your strategy and customer feedback.

 

Published by

Pete Dudchenko

Connect with me on Google+