If you are a Product Manager, then Continuous Deployment seems like an obvious win.
When you adopt continuous deployment, you take everything that you love about Agile Product Management— the rapid iterative processes, the increased product quality and market viability, the accelerated rate of collecting and incorporating customer feedback into products—and you supercharge it.
For example: If you follow a traditional Agile framework, then you are going to aim to release new product iterations every 1-2 weeks. When you upgrade to Continuous Deployment, you will start to iterate your product a few times per day by releasing code as soon as it’s been thoroughly tested and deemed ready to commit.
This is a huge leap forward, and the benefits of evolving to Continuous Deployment for Product Managers are clear. They include:
- You get to A/B test new features in real-world environments even faster than before.
- You can incorporate customer feedback into your live product in near-real-time.
- You are able to create reliable products with few (if any) code-level faults.
All of these benefits directly translate into the thing you care about most— releasing high-quality products and features that align tightly to your customer’s deepest needs.
Evolving Your Agile Product Management Seems Like an Easy Sell, Right?
Well, as great as Continuous Development appears for the core work of Product Managers, there is this other thing to keep in mind before you rush to try to adopt the framework…
For better or worse, there’s a lot more to your job than just creating great products for your customers. You also need to lead your Features Team to get them to actually create those great products and features. You need to get (and keep) your Business Analysts onboard with every product and feature you want to make. And you need to give Marketing a suite of products and features that they understand and know how to share with the world.
As much as Continuous Deployment can make your life easier when it comes to releasing all those great products you manage, it can also create a lot of friction between you and all of those other people who you also need to manage as a big part of your job.
So let’s take a quick look at why you will likely face some pushback from your stakeholders if you try to evolve towards a Continuous Development framework, why the conventional wisdom for disarming their concerns doesn’t really work, and how you might actually get them to adopt Continuous Deployment alongside you.
Let’s start by taking a look at each of their concerns, one at a time.
Why Your Marketing Department Might Push Back on Continuous Deployment
Marketing departments traditionally follow a Waterfall approach to collaborating with Product Managers. They like to perform a lot of market research upfront. They like to get involved in a predefined project planning phase to incorporate their single round of customer research. And then they like to have a well-defined product with static features, benefits, and value propositions that they can easily understand and push.
Continuous Deployment dissolves all of these structures, and forces Marketing departments to become nimble, responsive, and adaptable to daily changes in the products and features they are selling. It’s a big adjustment in approach, and it’s natural for Marketing departments to feel unwilling to throw out everything they know and relearn their profession.
Why Your Business Analysts Might Push Back on Continuous Deployment
Business Analysts operate pretty similar to traditional Marketing departments. BAs like to have a lengthy discovery phase upfront. They like to extract a clean set of product requirements, and to enshrine them into a fixed document that acts as a binding agreement between “the business” and the developers. This document gives them some control over the whole process, including a fixed set of outcomes to track project success against.
Continuous Deployment blows away the concepts of fixed requirements, static product descriptions, and project success being linked to checking boxes on an internal contract. It takes control of the project away from the BAs, and places it into the hands of the product team— who are themselves being directed by the direct feedback of users. It makes sense that BAs might be reluctant to give up their control over product development.
Why Your Own Features Team Might Push Back on Continuous Deployment
If anyone should embrace Continuous Deployment with open arms, it’s your Features Team. But often they will push back more than anyone else when you try to make the shift to Continuous Deployment— even if the team already operates from a traditional Agile framework!
Some of this pushback is just inertia. Your Features Team has refined a set of workflows over the years, and they don’t see the point in adopting new tools and processes just to fix a way of doing their job that (from their perspective) isn’t broken.
But some of it runs much deeper. Continuous Deployment changes the Feature Team’s job description. Instead of building towards well-defined product milestones—and defining success by how quickly and accurately they hit those milestones—Continuous Deployment shifts Feature Teams off development and onto testing and bug fixes, while forcing them to adapt to a much more ambiguous definition of whether or not they are excelling at their jobs.
Disarming Each of These Objections (It’s Not as Simple as It Might Look)
If you’re going to adopt Continuous Deployment as a Product Manager, then you’re going to need to convince each of your stakeholder groups that it’s a worthwhile change. And—contrary to the advice you’ll find if you search through the development community’s discussions on this topic—convincing these three stakeholder groups to toss their old way of doing things and adopt Continuous Deployment is not as simple as:
- “Explaining the pros-and-cons of Continuous Development.”
- “Changing your organization’s culture.”
- “Communicating more.”
We don’t mean to be flip here, or to poke fun at anyone who is offering genuine advice. We’d just like to point one thing out— while these actions are necessary elements of any change management program, they don’t really address the deep concerns your stakeholders feel about adopting this new Product Management methodology. No amount of pros-and-cons lists that outline why Continuous Development is great for you will address the fact that:
- Your Marketing department is worried because they don’t know if they are selling a product or feature set that has already dramatically changed since you last spoke.
- Your Business Analysts are worried that you are going to waste a lot of time, money, and manpower building products with no clear use case.
- Your Features Team are worried that 90% of their job is going to become fixing bugs and cleaning code instead of hitting targets that they can point to during a performance review.
These are not shallow concerns that you can paper over with platitudes or educational sessions on the value of Continuous Deployment. These are deep, material issues that you need to find a way to address for your stakeholders before you can evolve your Agile Product Management with scrum and reap the benefits of Continuous Deployment.
How to Disarm Your Stakeholders’ Concerns About Continuous Deployment
The answer is simple, but not easy. You have to really dig into each of their concerns, and proactively find a way to solve their problems for them.
You need to fold Marketing into your day-to-day work so they are aware of what you are developing, what changes you have planned, and how soon you will be giving them new products and features to place their campaigns behind. You need to share the customer experience feedback that is informing your decisions, so it can inform Marketing’s messages too.
You need to bring your Business Analysts in too. You must justify the expense of adopting new tools, team members, and training protocols to develop a Continuous Deployment capability. You must then proactively quantify and report on the ways your faster iterations will create a more viable and profitable product suite that remains aligned to the business, its strategy, and its regulatory frameworks.
Most important, you need to take care of your Features Team. You must make sure they don’t miss their development milestones because they are constantly cleaning code. You must make sure they still build and deploy new features and not just new test cases. And you must give them both the training they need to adapt to Continuous Deployment methodologies, and a centralized platform that automates, streamlines, and accelerates their most critical new workflows.
Continuous Deployment represents a big leap forward in Product Management. There were growing pains when the field moved from Waterfall to Agile, and it’s wise to expect—and proactively handle—this new set of obstacles as you evolve to the next stage of Agile product lifecycle management.
