Change Management for Product Leaders
Change Management for Product Leaders
Keeping your credibility through a replan
Suppose you are a software product manager working on team with a big release planned for next quarter. One of the testers just mentioned the release has a lot of bugs and there is no way the release is going to be delivered on-time. It sounds pretty certain that the release is going to be delayed. Should you do any change management or should you just let everyone know about the delay?
What is Change Management?
Change management comes in to play after a team commits to a product delivery plan. Once a plan is communicated outside of the product team, then changes to the plan need to be handled in a controlled process. A typical change management process follows these steps:
Recognize and confirm there is a change
Notify key stakeholders of a potential change
Define impacts of the change and any options to mitigate
Recommend steps to address the change
Stakeholders agree to the change
Reset the plan and communicate about the change
These steps can take hours to weeks to execute depending on the size of your team. The need for change management usually arises on smaller teams because larger teams have dedicated program management resources.
Should Product Managers Use Change Management?
Change management is a hidden time saver for product managers. It is key to go through a change quickly and openly with the product team. Avoiding a change or jumping straight to communicating the change can be devastating on your time.
Ignoring Changes has Risks
On the example of a tester stating the release is going to be delayed, you can convince yourself that engineering leadership is going to resolve the issue. Occasionally, engineering leadership is able to add resources or resolve complex problems to hold to the plan. In other cases, engineering leadership is forced to withdraw a key feature or has other customer visible restrictions to hold to the schedule. It would be less effort to find this out now with change management instead of explaining the change just before software release.
Communicating Before Change Management
Communicating right away about a potential delay causes confusion. When there is uncertainty on the release plan, product managers get hit from all directions with requests for status.
Coming back to the example of your tester stating the release is going to be late, suppose you immediately announce internally and externally that the release might be late? You will likely have your boss, the product team and sales people asking for more information and asking for a plan update. In the worst case, customers can hold orders until they know when the release is planned for delivery.
Besides the confusion across the team, your time is spent explaining a potential change. Going through a quick change management process is much less impact on your time!
How to be Honest During a Change Management Event
How do you honestly give status of the plan when you know there is change pending? Maybe it takes days or weeks to go through the change management process. Are you dishonest when you still communicate about the original plan? There are ways to be credible to your product team and customers while you are going through change management.
In the example of a tester stating the release is going to be late, how can you respond to questions about the schedule? In software products, you can represent the schedule as a “target plan” and “subject to change”. If you always represent the plan as a “target” - even if the plan is on track - then you are simply providing a forecast of the delivery. Then you are credible even if change management is underway.
Conclusion
It takes discipline to follow through on change management while holding back communication about a replan. Likewise ignoring a change can impact your credibility and be time consuming. When you are in a product management role, you can consider that a change management event is always pending and represent the plan “as subject to change”. Mentally preparing yourself for a change in your software product, helps you navigate through change management with the least impact on your time and credibility.