Disruptions to the Release Process, Pt. 2: Scope Creep
Photo by John Schnobrich on Unsplash
Unfortunately for Product Managers, product development doesn’t happen in a vacuum. There are a handful of common disruptions that impact the release process. Last week, we focused on the problem of finding critical bugs in production. This week, the focus is on avoiding scope creep due to ad-hoc feature requests from internal stakeholders.
The problem
Ideally, you have gotten write-off and validation from all departments and appropriate customers for your product release long before it is developed and pushed for testing. However, the world keeps turning while you are heads-down on your release, constantly breeding and inventing new problems, ideas, and requests. It is common that product releases end up threatened by outside demands and opinions.
It is your job to protect the product requirements and release dates. You cannot do that if you allow the scope of your project to grow and grow.
It is important to remember that scope creep attempts made by internal stakeholders come from a well-meaning place. Everyone on your team should want a stellar product. While it may feel like these last-minute requests are brought up to make your life a living hell, they are not actually sinister in nature. Knowing this piece is important in how you handle yourself while dealing with this issue. Avoid going into this conversation feeling offended.
The Solution
The key here is to explain, explain, and explain some more. As the Product Manager, you are the one who is involved in customer conversations, industry research, competitive analysis, and PRD compromises along the way. Internal stakeholders in other departments are not always privy to these background discussions and happenings. Product is not in their wheelhouse so you need to be prepared to explain your decisions in order to protect your release.
It is also important to understand that people focus on what they are able to see. It is easy to see your team of developers writing code and bringing products to life. Therefore, it is easy for internal stakeholders to believe that it is straightforward or even simple to add features at any given time. Meanwhile, it is harder for them to see the hidden aspects of a release such as the analysis, validation, and iteration of a product spec that needs to happen months before it gets into the hands of developers.
It is up to you to help your company understand how products get developed, when iterations are accepted, and when specifications for a product can no longer be changed.
Methods
Familiarize yourself with the word, “No.” Say it out loud a few times in the mirror. Write it on your hand in permanent marker. Don’t be shy. This is a time where you have to set boundaries in order to maintain the integrity of your product and its timely release.
Take the time to explain your product process from the inception of a problem to the validation of the solution, including spec planning, design iterations, and handoff to development to those who are asking for additional features after development has begun.
Come prepared with a potential new release date if Product were to go back to the spec planning and design iteration part of the product process and implement this new proposed feature. If it truly is a make-or-break feature that will impact the success of your product, then it will be worth the time to go back, validate the feature, and make necessary changes, even if that means the product release is delayed by a month. Showing how ad-hoc features delay a release is a strong method to curb these requests and to keep your product release on schedule.
Suggest a compromise that follows your product process. Does their suggested feature need customer validation before it is developed? You can propose that the product release scope remain unchanged and that you will collect customer feedback on possible feature expansion opportunities after the customer has used the new product. This follows the MVP methodology and ensures that you do not build unnecessary and non-validated functionality in your products.
Finally, bolster your relationship with internal stakeholders by reiterating their importance in the product process early-on and how/when they are best able to impact releases. Your constant reinforcement and explanation of the product process is important because it can help avoid last-minute feature requests in the future.
Conclusion
It cannot be stressed enough that making people feel heard, being transparent about decisions, and showing evidence are the key aspects for avoiding scope creep attempts from internal stakeholders. No one on your team wants to waste development time or have a release delayed due to a non-validated feature addition at the 11th hour. While these ad-hoc feature requests can create product and social tension, remember that confidence comes from knowing the facts and communicating them clearly. You have the data. Now get the support to release that product on time!
