Why Continuous Delivery and DevOps are Product Managers’ Best Friends "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs 5 May 2020 False Continuous Delivery, Devops, Lean Agile Product Design, Release, Release Train, Mind the Product Mind the Product Ltd 1839 Devops is great for Product People Product Management 7.356

Why Continuous Delivery and DevOps are Product Managers’ Best Friends

In the first part of this series, I explained what these buzzword-y “Continuous Delivery” (CD) and “DevOps” things are and started to touch on why you should care. But really, why should you care about these practices? Here’s why continuous delivery is a product manager’s new BFF.

Continuous Delivery is Transformative to Businesses

The main reason you should care about CD and DevOps is that it is transformative to businesses. Time and time again, organisations you admire, which produce products people love, reveal that they are doing Continuous Delivery and/or Continuous Deployment, and have a DevOps culture. Some good examples of companies that do this would be Etsy, Netflix and Amazon.

But CD and DevOps have not just helped Silicon Valley darlings to get big: CD has helped transform organizations all over the world. The Guardian is a great example of an older business who embraced the benefits CD brings by moving from a bimonthly release cycle to making tens of thousands of automated deployments a year. And the benefit for them?

What has been transformative for us is the massive reduction in the amount of time to get feedback from real users.

Likewise, teams at Expedia embraced CD, and within the first three months of using the new practices, they were able to run more experiments on their site than in the entire previous year. This ability fueled increased conversion rates, and led to significantly improved business performance.

And these examples are not outliers, my friends, oh no. In the 2014 State of DevOps report, Puppet Labs asserts with confidence that:

high IT performance correlates with strong business performance, helping to boost productivity, profitability and market share.

Likewise in the 2015 paper by Jez Humble and Nicole Forsgren, after analyzing data from the thousands of companies surveyed by Puppet Labs, they were able to conclusively show that: 

IT performance positively affects overall organizational performance”.

This means that if you can up your IT and delivery game, you can up the game of your whole organisation.

So there you have it. That’s the big, meaty, “you should totally do it!” justification screaming at you. Share it with your manager and your manager’s manager.

Why Does Continuous Delivery Matter to Product People?

But how will the product manager, the marketing lead and the support gurus out there see the benefit of these practices in their day-to-day work lives? Let’s find out.

It Will Help you Get Feedback Sooner

The main reason I love to deliver continuously is to get product feedback and validation sooner. The moment a new product or feature gets delivered to your customers, you start to get real feedback. Yes, there are a bunch of things you can do to test ideas before this with interviews, mockups, prototypes and user tests. I love these practices too, and I am not advocating “build it and they will come”. Yet there is nothing like the rubber-hits-the-road feedback you get, having pushed a new feature to production, to really learn if it achieves what you hoped it would – or not.

It Increases Responsiveness

When your team can deliver each and every build to production, you get to choose if each and every build goes to production. That means the time-to-market for the feature your customer asked for last week is, theoretically, just the time it takes to build and test it. If an idea is your top priority, why would you want to wait before delivering it? With CD, you don’t have to. No longer do you need to say “It’s built …  and will be released in December”, unless you actually want to. Instead you get to say: “The team pushed that to production while we were meeting. What do you think?

This responsiveness works in a million ways to help you, the product manager. When the next Heartbleed bug comes out, you can get a fix out before lunch. When your startup’s biggest customer needs a change, you can get it done and deployed overnight. Or let’s say your once-great-but-slowly-fading industry giant is being killed by small, lightweight, agile competitors, and you’re in charge of delivering value to customers this quarter: Let CD be your friend. It will help you solve problems quickly, fix issues as they occur and stay on top of customer needs.

It Reduces Waste and Risk, and Saves Money

I would need numerous hands to count the number of times I have seen product managers and clients add scope to a release, horde bugs, or refuse to deliver an MVP because they thought the next release was the only chance they had to complete a feature. Just last week a friend of mine at a well-known healthcare company said:

We missed the May release train, so we go live in December. And that means January because of holidays, so we’re just doing some extra stuff until then.

Seriously, they are just “doing some stuff” for 10 months while they wait for the release train to pull into the station. And I bet they’re not the only ones.

If you’re not following me, here’s another example of what happens when you have to wait to release.

Imagine you have an app store and you want to test out whether a ratings and review system helps users find the best apps on your store. If you are delivering continuously, you could start with a simple “thumbs up” feature – User gets apps they like and so give a “thumbs up”. Does this solve your problem? If yes, sweet – you are done. Next problem please. If no, then let’s see if a five-star system is better. Or reviews. Or scores out of ten.

Continuously Deliver Small Chunks of Value

If you can deliver value incrementally and iteratively, you can deliver less at each stage, get to the right solution faster and get better ROI on your investments. If you weren’t delivering those features regularly, I bet you that you would design, develop and deliver a whole five-point rating systems with user reviews. Then when you were thinking about reviews, you’d realize that you need to run them through a moderator, or remove blacklisted words so the reviews don’t have profanity in them. Suddenly you’re building the world’s best text moderation tool, and all you wanted to do was show users which apps were great and which were terrible.

In this way (and by avoiding traps like those I outlined above), CD reduces waste. It saves your business from building stuff it doesn’t actually need, allowing you to focus on value. It helps you meet customer needs sooner. It helps you to quickly understand how your product strategy is working. It helps you get ahead of your competitor more quickly. It will help you with your “business hat” on, not just your “technical hat”.

It Facilitates the Creation of Higher Quality Products

Quality is everyone’s responsibility. One of the significant benefits of CD is that it gives better visibility to everyone associated with a software project of the state of that project and so anyone can react to something that doesn’t look quite right.”

Dave Farley, co-author of Continuous Delivery

Although this might not be something you think about all the time, service quality is as important a “feature” as the actual code or tangible products you deliver. If your releases never result in a downtime, if your software is always available, if users never find a bug, then your customers’ opinions of your software will be higher, your referral rates will be higher, and you’ll have won your market.

It Leads to Releases That Are Sane and Calm

CD really does make releasing boring. My previous team complained to me that we hadn’t had a release celebration lunch for months. And it wasn’t because we weren’t releasing – we released everyday! It was just that we hadn’t had that adrenaline-fueled 24-hour period of “We will we get the feature out on time!” intensity followed by an evening unwinding in the pub that is often associated with a software release.

When you get into the habit of releasing, it becomes a simple part of how your team works. At 4 p.m. every day, our teams asks each other “what is ready to deliver?”. The product team, marketing lead and support team discuss the implications of what’s ready, and they decide if they want to release or not. It’s that simple. (You’ll remember from the first post that this choice is one of the key differences between continuous delivery and continuous deployment).

If the product manager wants to build a little more feature, they do that. If they want to test it with a few users first, they do that. If the marketer chooses to wait for PR reasons, they can do that instead. And if the support team says they need a particular fix for one high-value customer, it goes out. Calmly.

It Makes For Better Teams

As discussed in the first post, DevOps is about culture. In order to get these practices right, people need to collaborate, meaning work together, break down silos, share goals and act as a team! As you can imagine, there are many side effects of the push to DevOps that make your team function better. As shown in the scenario above, because you are talking about deploying every day, you are likely to be talking about quality every day, as well as delivering value to customers.

The more the team centers around these fundamental qualities of your software, the better the software is likely to be. Likewise, when team members are not siloed, they understand each other, and each other’s work, better. The less they are feeling the individual burden of a deployment or bug-fixing or a release test cycles, the more time they have to participate in team activities, share feedback, and help the whole team reflect and grow. It’s warm and fuzzy, and maybe even sounds idealistic, but it’s true in my experience.

Too Good to Be True

Alright, I’ll stop here. Honestly, there’s actually more reasons that I can think of as to why I want you to embrace CD practices, but I don’t want to sound over-zealous! And I have to say: it won’t be easy. Transitioning to a continuous delivery and DevOps culture is not all sunshine, unicorns and rainbows. It’s hard work on the part of your engineering and operations staff. And you. You product people have got to work hard to get this change done. When you move to this way of working, expectations change, your way of working changes, you have to change. But when you do, the payoff is immense.


Stuff You Should Probably Read

 

Comments 13

Great article Suzie! I read your first article on this topic too. We are in a B2B business where clients much rather to have limited number of changes and be informed well beforehand about upcoming changes. Could you speak a little bit about best practices/guide for PMs who want to make sure stakeholders are informed, and help/training materials are ready before anything goes out to Production but still want to adopt CI/CD? Should we just to CI and CD (continuous delivery) and have the continues deployments to prod (aka release) manual?

I’m confused about how you’re using “release train”. You say some [features] missed the release train, but the website you link to says (roughly): a release train is a team of teams which develops features on a cadence from a prioritized backlog and releases them “any time” the business wants to. It seems like a feature could miss a release cycle or not be prioritized high enough for the train to work on. The website also calls out creating a DevOps culture. Maybe your friend isn’t using the website’s definition of “release train”.

Randy

Great question. In fact when I was writing this and MTP edited it they asked me about the use of that word and whether it was clear what I meant. I added the link to help but maybe it didn’t.

Honestly, I am not a big fan of SAFe which is where that word comes from. Having seen SAFe in action in a number of large organizations I can safely say I have never seen SAFe and “any time” deployments. I have seen teams/projects group work together into large deliverables that often leads to unnecessary dependencies and one team holding up others. I’m sure there are implementations that aren’t like this but that is my experience.

Putting SAFe aside, what my friend referred to, that I think resonates with others, is the idea that a release date is fixed and if you miss that date you have to wait until the next scheduled release to go live. This wait is wasted value, slower time to ROI and frustrated PMs 🙂 I hope that explains where I was coming from.

Cheers
– Suzie

Ah. I know some SAFe organizations who’ve gotten their deployments down to a day. Maybe what you see is a characteristic of SAFe’s target market: Large companies. Seems like it would be hard to get them to buy into WHY, then reimagine and invest to get to CI/CD. Let’s hope your article wakes some of them up.

When it is Product Managers who are leading the transformation to get product development to be agile, it might make better sense to call it as a movement to “Continuous Delivery” as that is really outcome driven. When we try to transform to “Agile”, there is a lot of scope for the stake-holders to hide behind the nuances and not really doing Agile. As you rightly say, “CD is the best friend of a product manager” – it is Nirvana – but takes a lot to achieve. Great article.

Vivek – a very good point. I too have spent a lot of time as a consultant sharing, mentoring and doing “agile”. It can be successful – and it can fail. I feel like the outcome driven, rather than process driven, definitions of Continuous Delivery have helped me personally as well as those I share this with. Thanks for sharing.

Very well written Suzie. Thanks for writing this article. The combination of Continuous Integration, Continuous Testing and Continuous Delivery enables fail early, fail fast and fail often ( test early, test fast & test often ) for a Product Manager’s ideas. As you said the transition is not easy but worth it. Most of the concerns/ objections that come in the way are about change in culture for everyone starting from Product Manager, Development Engineer, Quality Engineer & DevOps Engineer. Product managers have to write user stories such that there are independently deployable. User stories have to be broken into tasks that is not more than one day’s worth of work so that commit builds happen on a daily basis.

Hey Rajagopala Thanks for your comment. I agree the change is hard work and everyone needs to be thoughtful about where they want to be and how to get there. I didn’t discuss the changes a product manager needs to make to facilitate and be part of the change. Small independent requirements are part of that for sure. I think I want to review these product management changes in the next piece and you’ve given me ideas about what else to cover. Thanks!

Thanks again Fahim. I’d love to hear how things have been working out with you. What objections do you hear? It would be great to understand more so I can use that as further inspiration for my next post.

Really enjoyed reading this + wholeheartedly agree with the benefits you’ve clearly outlined. I’d be keen to hear about the common objections people face when they recommend their organisation adopt CI/CD.

Great job Suzie!

Join the community

Sign up for free to share your thoughts

In the first part of this series, I explained what these buzzword-y "Continuous Delivery" (CD) and "DevOps" things are and started to touch on why you should care. But really, why should you care about these practices? Here's why continuous delivery is a product manager's new BFF.

Continuous Delivery is Transformative to Businesses

The main reason you should care about CD and DevOps is that it is transformative to businesses. Time and time again, organisations you admire, which produce products people love, reveal that they are doing Continuous Delivery and/or Continuous Deployment, and have a DevOps culture. Some good examples of companies that do this would be Etsy, Netflix and Amazon. But CD and DevOps have not just helped Silicon Valley darlings to get big: CD has helped transform organizations all over the world. The Guardian is a great example of an older business who embraced the benefits CD brings by moving from a bimonthly release cycle to making tens of thousands of automated deployments a year. And the benefit for them?
What has been transformative for us is the massive reduction in the amount of time to get feedback from real users.
Likewise, teams at Expedia embraced CD, and within the first three months of using the new practices, they were able to run more experiments on their site than in the entire previous year. This ability fueled increased conversion rates, and led to significantly improved business performance. And these examples are not outliers, my friends, oh no. In the 2014 State of DevOps report, Puppet Labs asserts with confidence that:
"high IT performance correlates with strong business performance, helping to boost productivity, profitability and market share.
Likewise in the 2015 paper by Jez Humble and Nicole Forsgren, after analyzing data from the thousands of companies surveyed by Puppet Labs, they were able to conclusively show that: 
IT performance positively affects overall organizational performance”.
This means that if you can up your IT and delivery game, you can up the game of your whole organisation. So there you have it. That’s the big, meaty, "you should totally do it!" justification screaming at you. Share it with your manager and your manager’s manager.

Why Does Continuous Delivery Matter to Product People?

But how will the product manager, the marketing lead and the support gurus out there see the benefit of these practices in their day-to-day work lives? Let’s find out.

It Will Help you Get Feedback Sooner

The main reason I love to deliver continuously is to get product feedback and validation sooner. The moment a new product or feature gets delivered to your customers, you start to get real feedback. Yes, there are a bunch of things you can do to test ideas before this with interviews, mockups, prototypes and user tests. I love these practices too, and I am not advocating “build it and they will come”. Yet there is nothing like the rubber-hits-the-road feedback you get, having pushed a new feature to production, to really learn if it achieves what you hoped it would - or not.

It Increases Responsiveness

When your team can deliver each and every build to production, you get to choose if each and every build goes to production. That means the time-to-market for the feature your customer asked for last week is, theoretically, just the time it takes to build and test it. If an idea is your top priority, why would you want to wait before delivering it? With CD, you don’t have to. No longer do you need to say “It’s built ...  and will be released in December”, unless you actually want to. Instead you get to say: "The team pushed that to production while we were meeting. What do you think? This responsiveness works in a million ways to help you, the product manager. When the next Heartbleed bug comes out, you can get a fix out before lunch. When your startup’s biggest customer needs a change, you can get it done and deployed overnight. Or let's say your once-great-but-slowly-fading industry giant is being killed by small, lightweight, agile competitors, and you’re in charge of delivering value to customers this quarter: Let CD be your friend. It will help you solve problems quickly, fix issues as they occur and stay on top of customer needs.

It Reduces Waste and Risk, and Saves Money

I would need numerous hands to count the number of times I have seen product managers and clients add scope to a release, horde bugs, or refuse to deliver an MVP because they thought the next release was the only chance they had to complete a feature. Just last week a friend of mine at a well-known healthcare company said:
We missed the May release train, so we go live in December. And that means January because of holidays, so we’re just doing some extra stuff until then.
Seriously, they are just “doing some stuff” for 10 months while they wait for the release train to pull into the station. And I bet they're not the only ones. If you’re not following me, here’s another example of what happens when you have to wait to release. Imagine you have an app store and you want to test out whether a ratings and review system helps users find the best apps on your store. If you are delivering continuously, you could start with a simple "thumbs up" feature - User gets apps they like and so give a "thumbs up". Does this solve your problem? If yes, sweet - you are done. Next problem please. If no, then let’s see if a five-star system is better. Or reviews. Or scores out of ten.

Continuously Deliver Small Chunks of Value

If you can deliver value incrementally and iteratively, you can deliver less at each stage, get to the right solution faster and get better ROI on your investments. If you weren’t delivering those features regularly, I bet you that you would design, develop and deliver a whole five-point rating systems with user reviews. Then when you were thinking about reviews, you’d realize that you need to run them through a moderator, or remove blacklisted words so the reviews don’t have profanity in them. Suddenly you’re building the world’s best text moderation tool, and all you wanted to do was show users which apps were great and which were terrible. In this way (and by avoiding traps like those I outlined above), CD reduces waste. It saves your business from building stuff it doesn't actually need, allowing you to focus on value. It helps you meet customer needs sooner. It helps you to quickly understand how your product strategy is working. It helps you get ahead of your competitor more quickly. It will help you with your "business hat" on, not just your "technical hat".

It Facilitates the Creation of Higher Quality Products

"Quality is everyone's responsibility. One of the significant benefits of CD is that it gives better visibility to everyone associated with a software project of the state of that project and so anyone can react to something that doesn't look quite right." - Dave Farley, co-author of Continuous Delivery
Although this might not be something you think about all the time, service quality is as important a “feature” as the actual code or tangible products you deliver. If your releases never result in a downtime, if your software is always available, if users never find a bug, then your customers’ opinions of your software will be higher, your referral rates will be higher, and you'll have won your market.

It Leads to Releases That Are Sane and Calm

CD really does make releasing boring. My previous team complained to me that we hadn’t had a release celebration lunch for months. And it wasn’t because we weren’t releasing - we released everyday! It was just that we hadn’t had that adrenaline-fueled 24-hour period of “We will we get the feature out on time!” intensity followed by an evening unwinding in the pub that is often associated with a software release. When you get into the habit of releasing, it becomes a simple part of how your team works. At 4 p.m. every day, our teams asks each other “what is ready to deliver?”. The product team, marketing lead and support team discuss the implications of what's ready, and they decide if they want to release or not. It’s that simple. (You’ll remember from the first post that this choice is one of the key differences between continuous delivery and continuous deployment). If the product manager wants to build a little more feature, they do that. If they want to test it with a few users first, they do that. If the marketer chooses to wait for PR reasons, they can do that instead. And if the support team says they need a particular fix for one high-value customer, it goes out. Calmly.

It Makes For Better Teams

As discussed in the first post, DevOps is about culture. In order to get these practices right, people need to collaborate, meaning work together, break down silos, share goals and act as a team! As you can imagine, there are many side effects of the push to DevOps that make your team function better. As shown in the scenario above, because you are talking about deploying every day, you are likely to be talking about quality every day, as well as delivering value to customers. The more the team centers around these fundamental qualities of your software, the better the software is likely to be. Likewise, when team members are not siloed, they understand each other, and each other's work, better. The less they are feeling the individual burden of a deployment or bug-fixing or a release test cycles, the more time they have to participate in team activities, share feedback, and help the whole team reflect and grow. It’s warm and fuzzy, and maybe even sounds idealistic, but it’s true in my experience.

Too Good to Be True

Alright, I'll stop here. Honestly, there’s actually more reasons that I can think of as to why I want you to embrace CD practices, but I don’t want to sound over-zealous! And I have to say: it won’t be easy. Transitioning to a continuous delivery and DevOps culture is not all sunshine, unicorns and rainbows. It’s hard work on the part of your engineering and operations staff. And you. You product people have got to work hard to get this change done. When you move to this way of working, expectations change, your way of working changes, you have to change. But when you do, the payoff is immense.

Stuff You Should Probably Read