It should only finish when the product is successfully afloat.
A major issue for product launches in many businesses is that the launch team and resources stick around up to the launch and then melt away just as the product is making its first faltering steps into the world.
All the focus, know-how and momentum stops at this critical point which often results in major problems. Issues that would be easy to solve with the launch team are much harder to resolve once all the infrastructure and experience have disappeared.
Source: Launch of Mauretania II, National Museums Liverpool
It’s nigh on impossible to get everything right upfront, there are always things that are missed or things that change so there will always be issues to sort out after the launch. The cost and time to do this should be planned into the development project right from the start. This needs the participation of all areas, including development, who shouldn’t be let off the hook until these early problems are resolved and the product can be treated as ‘business as usual’.
We believe there should always be another stage after launch where the development team remains engaged for a fixed period or until certain Key Performance Indicators (KPIs) are met. These KPIs could include when a certain number of customers are up and running, the point at which no new major bugs are identified, or reaching a minimum level in customer satisfaction surveys. The cost of doing this is not insignificant however it has to be balanced against the cost of failure i.e. missed market opportunities, bad publicity, and dissatisfied customers.
Why spend all that money on building a product and pull away from the safety net at the last minute?
Ian Lunn
Director, Product Focus
Join the conversation - 4 replies
Key business stakeholders are often interested in KPIs which track the progress of a product launch – once the actual launch date activity has passed.
One thing you may wish to consider are metrics which lend themselves to reporting at regular intervals a “% of launch completed”.
At some point your key stakeholders will want to know that the launch has been completed, so why not keep them in the loop with a “% completed to date” metric?
Neil, you’re correct on the need to keep stakeholders appraised of progress toward launch and I’d always provide them with a project status update. A ‘% complete’ metric can be useful, however my experience is that stakeholders are mainly interested in whether a project is running to a previously agreed plan. To do this, additional project tracking is needed. I advocate using a Red, Amber, Green status with supporting comments to show achieved and forecast progress against plan. Most projects progress in jumps as deliverables are completed or blocking issues are overcome and the use of a ‘traffic light’ status gives stakeholders a feel for the outlook of your launch – flagging an amber or red status gives the product manager a platform for discussing how stakeholders can help removes blockages and keep their launch on track.
Regards, Andrew
Red/Amber/Green helps with discussion around the detail of the launch, but from my experience many senior folks have little interest in the actual detail – aside from the obvious Red/Amber issues and simply want to know “When will the launch be over?”
Unless you are gifted with outstanding communication skills, a ready wit and a commanding presence, you could find that wading through “the detail” will result in your Stakeholder’s eyes glazing over.
Clearly this is not always the case as some folks have a passion for data. 😉
As in all things your view may vary.
Hi Ian, great post.
“The cost and time to do this should be planned into the development project right from the start.” You hit the nail on the head with this statement. It is important to have a clear plan outlined and that all stakeholders (employees, partners and especially customers) are kept within the loop- from start to finish.